[ipv6hackers] Ipv6hackers Digest, Vol 3, Issue 7

[Ahmad Sadeh]

Dear All,

few more words about Windows Secure Neighbor Discovery (WinSEND)
implementation. WinSEND is a user-space implementation which works as
service for Windows families with a user interface to set security
parameters for the proper Network Interface Card (NIC).

The CGA part is completely ready. However, we are still working on the
Authorization Delegation Discovery (ADD) mechanism part! hope it will be
ready soon!

Regarding to the question, if it is open source or it is commercial product,
We (Sara and Ahmad) are  PhD students and we are doing research to push IPv6
deployment in a secure manner.

The intellectual properties of this implementation will be for our
institute! However, may it will be offered as an open source later or at
least offered the executable file for download.
Regards,
Ahmad AlSadeh




On Tue, Sep 27, 2011 at 12:00 PM, <ipv6hackers-request at lists.si6networks.com
> wrote:

> Send Ipv6hackers mailing list submissions to
>        ipv6hackers at lists.si6networks.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.si6networks.com/listinfo/ipv6hackers
> or, via email, send a message with subject or body 'help' to
>        ipv6hackers-request at lists.si6networks.com
>
> You can reach the person managing the list at
>        ipv6hackers-owner at lists.si6networks.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ipv6hackers digest..."
>
>
> Today's Topics:
>
>   1. Re: IPv6 security presentation at Hack.lu 2011
>      (Jean-Michel Combes)
>   2. Re: IPv6 security presentation at Hack.lu 2011
>      (Eric Vyncke (evyncke))
>   3. Re: IPv6 security presentation at Hack.lu 2011
>      (Eric Vyncke (evyncke))
>   4. Re: IPv6 security presentation at Hack.lu 2011 (Fernando Gont)
>   5. Re: IPv6 security presentation at Hack.lu 2011 (Jim Small)
>   6. Re: IPv6 security presentation at Hack.lu 2011 (Owen DeLong)
>   7. Re: IPv6 security presentation at Hack.lu 2011 (Jim Small)
>   8. Re: IPv6 security presentation at Hack.lu 2011 (Jim Small)
>   9. Re: IPv6 security presentation at Hack.lu 2011 (Jim Small)
>  10. Re: IPv6 security presentation at Hack.lu 2011 (fred)
>  11. Re: IPv6 security presentation at Hack.lu 2011 (Douglas Otis)
>  12. Re: IPv6 security presentation at Hack.lu 2011 (Jim Small)
>  13. Re: IPv6 security presentation at Hack.lu 2011 (Marc Heuse)
>  14. Re: IPv6 security presentation at Hack.lu 2011 (Enno Rey)
>  15. Re: IPv6 security presentation at Hack.lu 2011 (Owen DeLong)
>  16. Re: IPv6 security presentation at Hack.lu 2011 (Erik Kline)
>  17. Re: IPv6 security presentation at Hack.lu 2011 (fred)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 Sep 2011 13:38:55 +0200
> From: Jean-Michel Combes <jeanmichel.combes at gmail.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <CAA7e52oOm+f0Dt78ug3XJaDT7X1gJo80bE_eV0TW+SmZy6q47A at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Fernando,
>
> 2011/9/25 Fernando Gont <fgont at si6networks.com>:
> > Hi, Geoff,
> >
> > On 09/22/2011 04:45 PM, Geoff Huston wrote:
> >
> >> Actually, as far as I am aware the answer is yes, RPKI can be used to
> >> support EE certs issued to routers, or at least that was the
> >> intention back in 2009 when we were working on the RPKI and SEND
> >> documents in the IETF.
> >
> > Even with this in place, I don't see how this would make SEND deployment
> > easier for an edge network.
> >
> > Are e.g. home/organisational networks expected to receive a certificate
> > from their ISPs such that they can use SEND as a mitigation for ND-based
> > attacks?
>
> <ISP hat on>
> Yes, could be the case.
> Now, IMHO, still missing tools do to this: we have already PD with
> DHCPv6 but we would need something to provide, dynamically too, the
> associated certs (e.g., draft-popoviciu-dhc-certificate-opt).
> <ISP hat off>
>
> Best regards.
>
> JMC.
>
> >
> > Leveraging RPKI might make sense for some carrier/ISP networks, but I
> > can't see how that would ease SEND deployment for the general case.
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: fgont at si6networks.com
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> > _______________________________________________
> > Ipv6hackers mailing list
> > Ipv6hackers at lists.si6networks.com
> > http://lists.si6networks.com/listinfo/ipv6hackers
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Sep 2011 14:48:38 +0200
> From: "Eric Vyncke (evyncke)" <evyncke at cisco.com>
> To: "IPv6 Hackers Mailing List" <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <317616CE96204D49B5A1811098BA8950056CC317 at XMB-AMS-110.cisco.com>
> Content-Type: text/plain;       charset="iso-8859-1"
>
> Sara,
>
> As you kindly asked about Cisco SeND implementation, here are some details:
> - available since probably 2 years now in IOS (this is for the 'regular'
> routers not for the big ones)
> - it obviously includes CGA
> - RA can be protected as well but, of course, router must have a
> certificate (IOS router can be part of a PKI, from sending an enrollment
> request, checking CRL and even acting as poor-man CA) and the receiving
> nodes must have configured the trust anchor
>
> I would be really interested to know more about your implementation because
> SeND in a router is a nice engineering work but as long as no nodes are able
> to process SeND-protected RA, it is also useless :-(
>
> Hope this helps
>
> -?ric
>
>
> > -----Original Message-----
> > From: ipv6hackers-bounces at lists.si6networks.com [mailto:ipv6hackers-
> > bounces at lists.si6networks.com] On Behalf Of Sara
> > Sent: vendredi 23 septembre 2011 09:22
> > To: IPv6 Hackers Mailing List
> > Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> >
> > Hi All,
> > we already implemented SEND for windows however we're working on
> > performance. I'm really interested to know more about CISCO
> implementation
> > and other details if available because we would like to know what CISCO
> did
> > about router certification and so on.
> >
> > Regards,
> > Sara
> >
> >
> >
> > ________________________________
> > From: fred <fred at fredbovy.com>
> > To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>; Karl
> Auer
> > <kauer at biplane.com.au>
> > Sent: Thursday, September 22, 2011 6:15 PM
> > Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> >
> > Hi,
> >
> > A bit more about SEND.
> > I was the CISCO IPv6 engineer who did the dev-test for SEND. I wrote the
> > test plan and all the TCL scripts to test it all and I also developed the
> > template to decode the protocol with the Cisco Internal tool...
> >
> > I would have love to see Microsoft keeps its word and implements it in
> Vista
> > as I heard they will but once we (CISCO) developed it, then Microsoft did
> > not :-(
> >
> > I wrote this post about SEND:
> >
> http://www.fastlaneus.com/blog/2011/08/30/secure-the-ipv6-network-access-wit
> > h-secure-neighbor-discovery-send-rfc3971-and-cga-rfc3972/
> >
> > I believe that there would be no protocol safer than IPv6 if SEND was
> > implemented by Microsoft and Apple... It's a shame they did not!
> >
> > Having PKI is not a big deal. We get a certificates in France in 10
> minutes
> > from the French Tax when we do our tax return online ! And you only need
> to
> > do it sometimes. You don't need a new certificate everyday !
> >
> > You also need strong time synchronization to make it work but this is not
> a
> > big issue neither.
> >
> > The only big problem is that neither Microsoft neither Apple implemented
> it.
> >
> > Fred
> >
> >
> >
> >
> > Le 22/09/2011 17:56, ??Jim Small?? <jim.small at cdw.com> a ?crit?:
> >
> > > Karl,
> > >
> > > To address your questions:
> > > 1) SeND (Secure Neighbor Discovery Protocol) Info including sources:
> > > http://en.wikipedia.org/wiki/Secure_Neighbor_Discovery_Protocol
> > > And a good overview (saw lots of comments on the list):
> > > http://ipv6.com/articles/research/Secure-Neighbor-Discovery.htm
> > >
> > > Ideally I could point you to a Live CD but I couldn't find one.? I'll
> ask
> > > around and post back if I can find one.? I know several people well who
> > have
> > > setup SeND with Linux/IOS so I know it's possible.
> > >
> > >
> > > 2) Official proclamation from Microsoft the SeND is not implemented in
> > > Windows:
> > > http://technet.microsoft.com/en-us/library/bb726956.aspx
> > > Updated this August, from the Authorization for Automatically Assigned
> > > Addresses and Configurations section, "Microsoft does not support SEND
> in
> > any
> > > version of Windows."
> > >
> > > 3) Definitive information on SeND support from Apple for OS X -
> > unfortunately
> > > I couldn't find it.? I'll post back if I can.
> > >
> > > 4) Bonus - How to setup SeND in IOS:
> > > http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-
> > first_hop_sec
> > > urity.html#wp1112987
> > >
> > > --Jim
> > >
> > > _______________________________________________
> > > Ipv6hackers mailing list
> > > Ipv6hackers at lists.si6networks.com
> > > http://lists.si6networks.com/listinfo/ipv6hackers
> >
> > --
> >
> > Fred Bovy
> > fred at fredbovy.com
> > Skype: fredericbovy
> > Mobile: +33676198206
> > Siret: 5221049000017
> > Twitter: http://twitter.com/#!/FredBovy
> > Blog: http://fredbovyipv6.blogspot.com/
> > ccie #3013
> >
> >
> >
> >
> > _______________________________________________
> > Ipv6hackers mailing list
> > Ipv6hackers at lists.si6networks.com
> > http://lists.si6networks.com/listinfo/ipv6hackers
> > _______________________________________________
> > Ipv6hackers mailing list
> > Ipv6hackers at lists.si6networks.com
> > http://lists.si6networks.com/listinfo/ipv6hackers
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 Sep 2011 14:53:22 +0200
> From: "Eric Vyncke (evyncke)" <evyncke at cisco.com>
> To: "IPv6 Hackers Mailing List" <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <317616CE96204D49B5A1811098BA8950056CC321 at XMB-AMS-110.cisco.com>
> Content-Type: text/plain;       charset="iso-8859-1"
>
> Regarding 'happy eyeballs', I heard at the last IETF meeting from Microsoft
> mouth in a public WG that next IE (perhaps even 9.0 -- not sure) will
> implement 'happy eyeballs'
>
> Implementing happy eyeballs in the OS has sense only when applications use
> API based on FQDN and not IP addresses. Mac OS/X applications often do not
> use socket API hence it is efficient for Mac OS/X to implement happy
> eyeballs in the OS, less sure about Windows
>
> -?ric
>
> > -----Original Message-----
> > From: ipv6hackers-bounces at lists.si6networks.com [mailto:ipv6hackers-
> > bounces at lists.si6networks.com] On Behalf Of Leinweber, James
> > Sent: vendredi 23 septembre 2011 06:49
> >
> > Jim Small:
> > > ... RDNSS ... likely ... will be ... in WIndows 8
> >
> > Anyone willing to bet against "happy eyeballs" (race parallel v6 and
> > v4, deliver the winner) also being in windows 8, given that Google
> > Chrome, Firefox, and OS-X 10.7 already have it?  I've been pleasantly
> > surprised by how fast it's deploying.
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 25 Sep 2011 12:04:31 -0300
> From: Fernando Gont <fgont at si6networks.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID: <4E7F42FF.1090509 at si6networks.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 09/25/2011 06:39 AM, Owen DeLong wrote:
> >> If you don't validate RA's, then an attacker would simply spoof RA's,
> >> and would have all packets forwarded to him, thus defeating any
> >> protection that could have been provided with the CGAs.
> >
> > Unless you use RA Guard instead.
>
> Please take a look at our blog:
> <
> http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html
> >
>
> You may also take a look at http://www.thc.org for a publicly available
> tool that implements at least some of the variants described in our blog.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 27 Sep 2011 01:26:23 +0000
> From: Jim Small <jim.small at cdw.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>,
>        Fernando        Gont <fgont at si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <C04EF542D2911B4C88DE42BEA3CC95CF0BF36C at EXMBD5VH.corp.cdw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > Rather than making claims about "improved security", we should raise
> > awareness about IPv6 security challenges, such that they are mitigated,
> > and the security level of the involved networks does not *decrease*.
>
> Sure. I try to convince people in every my presentation that IPv6
> doesn't bring any security benefits (instead of sites like ipv6.com).
> The problem is that IPv6 protagonist do not want to hear such arguments
> and always claims that is not too bad etc. As the result of that we can
> see common IT staff very frustrated with IPv6 (Of course, I mean the
> people who have started doing with IPv6). The sad reality that is just
> impossible to properly secure a IPv6 network today. Even mitigation of
> security problems with IPv6 will cost you fortune and still you will not
> have an equivalent security level as in IPv4 - specially in first hop
> security.
>
> [JRS>] IPv6 brings many benefits and the potential for superior security to
> IPv4.  The biggest challenge I see is that in order to achieve increased
> security all the vendors supporting IPv6 must choose to implement the
> enhanced security components.  SeND is a perfect example.  This would neatly
> solve many if not all of the issues with NDP spoofing.  However, to the best
> of my knowledge it's not even in the mainline Linux/BSD kernels.  Microsoft
> and Apple seem to have no interest in it.  So while a solution is available
> and implemented by some (Cisco) unless all parties choose to implement it
> enhanced security will remain elusive.  The same problem exists for mobility
> (MIPv6), multihoming (SHIM6), and other solutions (Location/Identity
> separation options).  Any ideas on this?
>
> --Jim
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 26 Sep 2011 18:28:41 -0700
> From: Owen DeLong <owend at he.net>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID: <0328DEFE-0F31-4186-89E1-29C9DB6DAC8E at he.net>
> Content-Type: text/plain; charset=us-ascii
>
> I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
> so, I'm not sure how you can say that it is not an equivalent level of
> first
> hop security.
>
> Owen
>
> On Sep 26, 2011, at 6:26 PM, Jim Small wrote:
>
> >> Rather than making claims about "improved security", we should raise
> >> awareness about IPv6 security challenges, such that they are mitigated,
> >> and the security level of the involved networks does not *decrease*.
> >
> > Sure. I try to convince people in every my presentation that IPv6
> > doesn't bring any security benefits (instead of sites like ipv6.com).
> > The problem is that IPv6 protagonist do not want to hear such arguments
> > and always claims that is not too bad etc. As the result of that we can
> > see common IT staff very frustrated with IPv6 (Of course, I mean the
> > people who have started doing with IPv6). The sad reality that is just
> > impossible to properly secure a IPv6 network today. Even mitigation of
> > security problems with IPv6 will cost you fortune and still you will not
> > have an equivalent security level as in IPv4 - specially in first hop
> > security.
> >
> > [JRS>] IPv6 brings many benefits and the potential for superior security
> to IPv4.  The biggest challenge I see is that in order to achieve increased
> security all the vendors supporting IPv6 must choose to implement the
> enhanced security components.  SeND is a perfect example.  This would neatly
> solve many if not all of the issues with NDP spoofing.  However, to the best
> of my knowledge it's not even in the mainline Linux/BSD kernels.  Microsoft
> and Apple seem to have no interest in it.  So while a solution is available
> and implemented by some (Cisco) unless all parties choose to implement it
> enhanced security will remain elusive.  The same problem exists for mobility
> (MIPv6), multihoming (SHIM6), and other solutions (Location/Identity
> separation options).  Any ideas on this?
> >
> > --Jim
> >
> >
> >
> > _______________________________________________
> > Ipv6hackers mailing list
> > Ipv6hackers at lists.si6networks.com
> > http://lists.si6networks.com/listinfo/ipv6hackers
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 27 Sep 2011 01:37:31 +0000
> From: Jim Small <jim.small at cdw.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>,
>        Douglas Otis <dotis at mail-abuse.org>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <C04EF542D2911B4C88DE42BEA3CC95CF0BF399 at EXMBD5VH.corp.cdw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I just wanted to point out on this thread:
>
> > In addition it would be appropriate to assume there WILL be an IPv6
> > firewall when IPv6 is enabled.  Alternatively, it would be wrong to
> > assume any effective IPv6 firewall exists otherwise.  Perhaps you could
> > replace "disable IPv6" with "disable Protocol 41" instead. :^)
>
> "Disable proto 41" sounds good for referring to packets being filtered
> at a firewall. However, other (not mutually exclusive) options are
> avialable, such as disabling v6 suppport at the OS.
>
> [JRS>] -and-
>
> > Exactly.  Any compromised system within a LAN can easily set up IPv6
> > connectivity, specifically because a lax approach was taken where not
> > enabling IPv6 was seen as offering improved security. :^(
>
> If you disable IPv6 in the sense of removing support for it, that attack
> is not possible.
>
>
> [JRS>] Specifically with Windows Vista/7/Server 2008/R2 and later IPv6 is a
> core part of the Operating System.  Many features require IPv6 and will not
> work if you disable it including HyperV, TMG, Exchange, SBS Server,
> DirectAccess, HomeGroups, and Peer-to-Peer Networking.
>
> I think we all agree there is a clear need for IPv6 and IPv4 is reaching
> the limits of its scalability.  I like Fernando's approach of submitting
> drafts with suggestions where issues are discovered.  I believe the focus
> should be on encouraging vendors to adopt existing solutions, maintain or
> achieve parity with IPv4 features, address limitations/vulnerabilities
> discovered, and actively participate in the IETF and other forums to drive
> and improve IPv6.
>
> --Jim
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 27 Sep 2011 01:41:03 +0000
> From: Jim Small <jim.small at cdw.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <C04EF542D2911B4C88DE42BEA3CC95CF0BF3B6 at EXMBD5VH.corp.cdw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Owen,
>
> I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
> so, I'm not sure how you can say that it is not an equivalent level of
> first
> hop security.
> [JRS>] I believe I owe Fernando the credit for this, but my understanding
> of the difference is that you can't fragment ARP but you can fragment NDP.
>  Since NDP is based on IPv6 instead a L2 protocol like ARP which rides on
> Ethernet or the L2 technology, you can fragment it and use this to bypass
> ACLs or RA Guard.  AFAIK you can't do this with ARP.  There are proposals to
> fix this, but as far as I know a solution has not yet been implemented.
>
> --Jim
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 27 Sep 2011 02:30:42 +0000
> From: Jim Small <jim.small at cdw.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <C04EF542D2911B4C88DE42BEA3CC95CF0BF3EF at EXMBD5VH.corp.cdw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Tomas,
>
> 05/2011 IPv6 - Security Issues - IPSec does "solve" everything
> http://europen.cz/Proceedings/38/2011-ipv6-sec-europen.ppt
>
> 09/2011 Deploying IPv6 in University Campus Network
> http://ow.feide.no/_media/geantcampus:ipv6-podermanski.ppt
> (starting slide 26 there are touched some issues that we feel them as
> are very problematic - specially in a security area).
> [JRS>] For problem 1, very nice write up and demonstration of the
> complexities/issues with address auto-configuration.  For problem 2, impact
> on existing IPv4 infrastructure - for the most part this exists today.  You
> can do ARP poisoning/spoofing and you can just as easily enable a rogue
> DHCPv4 server.  The only real difference here is that because you can
> fragment NDP a malicious attacker is much harder to block.  For someone
> accidentally enabling RAs/DHCPv6 this can be blocked with RA Guard/Port
> ACLs.  For problem 3 - as has been discussed and shown there are solutions
> but the question remains will they be adopted/implemented?  I do not agree
> with your conclusion for problem number 4.  There are many benefits to IPv6.
>  IPv4+NAT smothers innovation, especially for communications.  It is ironic
> that the Internet was created for communication and yet IPv4+NAT makes this
> very difficult and requires 3rd party gateways.  IPv6 restores this, at
> least partially by removing the nee
>  d for NAT.  For number 5 it really depends on who.  Actually Cisco and
> Microsoft has excellent IPv6 VPN solutions.  Cisco is closing in on feature
> parity between IPv4 and IPv6.  Microsoft has also done fairly well in this
> regard.  But you are correct in that some solutions/vendors have poor IPv6
> support.  For problem 6, privacy extensions can be disabled although this
> can be an issue for non-managed devices.  I'm not sure what you mean by
> Netflow - v9/IPFIX support IPv6.  DHCPv6 does have issues to work through
> but I think you captured this in problem 1.  NAT is its own topic but where
> you talk about the benefits (and there are some), you should also talk about
> the drawbacks which are just as numerous.  IPv6 tends to result in more
> tunnels too, but this really isn't a new issue - these exist today in IPv4.
>  I will say that on a decent sized network with IPv6 IPAM becomes a
> necessity.  Problem 7 is an issue.  I think it is likely IPv4 will disappear
> off the Internet in less t
>  han 10 years.  However, within our intranets it will likely persist for a
> long time most likely out lasting all of us.  :-)  This is added complexity
> but I think it's unlikely a solution will emerge to eliminate it.  Just like
> with AppleTalk, IPX, SNA, DECnet and other legacy protocols as long as it is
> needed it will persist.  I do not agree with problem 8.  Newer development
> languages abstract addressing.  If you use the right development tools you
> will most likely be oblivious to the addressing system.  This is really only
> an issue for network administrators and people who write device drivers and
> the like.  I like the presentation overall and agree that we need to have
> frank discussions and push vendors to solve existing problems.
>
> --Jim
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 27 Sep 2011 04:33:27 +0200
> From: fred <fred at fredbovy.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID: <CAA70297.57FB%fred at fredbovy.com>
> Content-Type: text/plain;       charset="ISO-8859-1"
>
> I would then say that it is a bit more complicated to fool NDP than ARP
> because of its more sophisticated FSM, NUD, and so on...
>
> So why NDP could be worse than ARP ? Because it can advertise a default
> router with a RA? If the answer is yes maybe there is a way (which I would
> not recommend anyway) to stop the router from sending RA and configure the
> end node from DHCPv6 or manually. Just like IPv4 would do.
>
> Or is there anything else where NDP spoofing is worst than ARP spoofing ? I
> would really think the opposite...
>
>
> Fred
>
>
>
> Le 27/09/2011 03:28, ??Owen DeLong?? <owend at he.net> a ?crit?:
>
> > I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
> > so, I'm not sure how you can say that it is not an equivalent level of
> first
> > hop security.
> >
> > Owen
>
> --
>
> Fred Bovy
> fred at fredbovy.com
> Skype: fredericbovy
> Mobile: +33676198206
> Siret: 5221049000017
> Twitter: http://twitter.com/#!/FredBovy
> Blog: http://fredbovyipv6.blogspot.com/
> ccie #3013
>
>
>
>
>
>
> ------------------------------
>
> Message: 11
> Date: Mon, 26 Sep 2011 19:37:09 -0700
> From: Douglas Otis <dotis at mail-abuse.org>
> To: Fernando Gont <fgont at si6networks.com>
> Cc: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID: <4E8136D5.3030100 at mail-abuse.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 9/25/11 1:03 AM, Fernando Gont wrote:
>
> Hi Fernando,
> > On 09/22/2011 08:55 PM, Douglas Otis wrote:
> >>> On 09/21/2011 04:05 PM, Douglas Otis wrote:
> >>>> The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
> >>>> options.
> >>> Any particular reason for describing those? -- i.e., since it is a
> >>> one-hour presentation, it's mostly a high-level overview, that only
> gets
> >>> into some detail when needing to prove that something is more of a myth
> >>> than a "fact".
> >> Yes.  DHCP is NOT required by IPv6 to support DNS.  This impacts
> >> security that depends upon DHCP snooping and should be mentioned.
> > NOt sure what you mean. In my presentation,  DHCPv6 and SLAAC are mostly
> > described as *alternative* autoconf mechanisms. If I were to desdcribe
> > RDNSS, I'd also have to describe PI option, etc... and the slides don't
> > get into that level of detail.
> Some consideration must be given in how to detect hosts when DHCPv6 is
> not used.  A rouge RA could easily implement Prefix Information and
> RDNSS options where monitoring DHCPv6 would then not detect which hosts
> were involved.  The DUID offered by DHCPv6 will not relate to specific
> hosts or their assigned assigned addresses.  Remote-ID Option 37
> described in RFC4649 might be used to replace DHCPv4 Option 82 to aid
> the port/IP address mapping, but then what when DHCPv6 is not used?
> >> Many expect a transition to IPv6 will not occur soon.  However support
> >> issues related with 6to4 caused a rethink by ISPs.  The less painful
> >> option is Dual-Stack Lite where ISPs deploy native IPv6 with centrally
> >> controlled LSN where customers might share IPv4 addresses.  This
> >> increases a desire for IPv6 connectivity for improved security and
> freedom.
> > Can you point out where this "increased security" comes from?
> NAT mapping rarely offers security.  SSL CBC has proven easily
> exploitable once a MitM situation is established.  NAT use places
> reliance on the LAN to avoid address spoofing and related MitM
> scenarios, much like that found with XSS.   End to End security does not
> require use of IPsec, although IPsec would be one such anti-MitM
> alternative.
> >>>> The statement 'Pushing people to "Enable IPv6" point-and-click style
> is
> >>>> simply insane' is deceptive.
> >>> While I might s/insane/incorrect/ (or the like), I do believe that
> >>> enabling a technology that one doesn't understand is a really bad idea.
> >> Even the assumption IPv6 is not enabled is a flawed concept.
> > Sloppy wording: I should have said "deploy IPv6" rather than "enable
> IPv6".
> Thoughtful deployment is still a better choice.  IPv6 is here now and
> the simpler approach is native support on the LAN.
> >> In
> >> addition it would be appropriate to assume there WILL be an IPv6
> >> firewall when IPv6 is enabled.  Alternatively, it would be wrong to
> >> assume any effective IPv6 firewall exists otherwise.  Perhaps you could
> >> replace "disable IPv6" with "disable Protocol 41" instead. :^)
> > "Disable proto 41" sounds good for referring to packets being filtered
> > at a firewall. However, other (not mutually exclusive) options are
> > avialable, such as disabling v6 suppport at the OS.
> Disabling IPv6 at the host will break services that do not assure
> functionality in this downgraded mode.  Not deploying IPv6 on the LAN
> also invites less secure fallback transitional schemes.  When a host is
> compromised, is it still safe to assume IPv6 is disabled?  Is there
> spoofing protection with ISATAP?
> >>> -- If whoever enabled v6 needed "5-step recipe to enable v6" or the
> >>> like, then they probably should have been trained before enabling v6.
> >> Again, the message should be that IPv6 _already_ exits within their
> >> networks.
> > Agreed. This is is noted in several slides. e.g., the first few ones,
> > and the "IPv6 security implications on IPv4 networks".
> >
> >> Enabling IPv6 on the LAN permits better monitoring and
> >> suppresses more problematic fallback strategies.
> > It also enables pontential vulnerabilities. See the latest (?)
> > remotely-explotaible vulnerability in OpenBSD dated 2008 or so.
> When will these issues be resolved to meet your satisfaction?  FreeBSD
> vendors have already released patches for the issue where perhaps due to
> the BSD license, fixes are driven by affected vendors.  All the more
> reason for the market to insist repairs are made or find alternatives.
> Going back to IPv4 is not an alternative at this time.
> >>> If you don't know "good enough" how your network works, attackers will
> >>> probably do better.
> >> Exactly.  Any compromised system within a LAN can easily set up IPv6
> >> connectivity, specifically because a lax approach was taken where not
> >> enabling IPv6 was seen as offering improved security. :^(
> > If you disable IPv6 in the sense of removing support for it, that attack
> > is not possible.
> As in removing it from the Internet, from the router, from the switch?
> Providing reasonable security for remote systems is easier using of
> end-to-end security methods.  IPv4 refers to translated IP address space
> full of questionable middle boxes.  While indeed IPv6 is not perfect,
> IPv6 provides future growth.
> >>>> It is wrong to suggest _not_ enabling IPv6
> >>>> in a network offers improved protections.
> >>> Well, I'd not say that it "provides improved protection", but rather
> >>> than "does not increase risk".
> >> Disagree.  This view increases risks by offering the false concept that
> >> relative inaction is better.
> > Nobody said that. Please look at the slides. On the contrary, I'd argue
> > that *something* should be done about it.
> Your strongest statements are to disable IPv6 (at the host), as if
> practical, possible, or offering better security.  Securely using IPv6
> is the new cost of doing business, period.
> >> By suggesting a NEED to enable IPv6 within
> >> the LAN raises attention to the fact that IPv6 is already present and
> >> the related risks MUST be mitigated or at least monitored.
> > I wouldn't necessarily suggest "enabling IPv6". If we blindly advise
> > organizations to enable IPv6, and they get hacked as a result of that
> > (see the OpenBSD vulnerability above), then we'd have done a
> > (security-wise) very poor consulting work.
> Should everyone stop using SSL because of the CBC issue?  Many of these
> issues will require improved monitoring over what we have today.  Those
> that start now will be ready when IPv6 really takes off, as it is about
> to do.
> > First of all comes an assessment of what the organization would gain
> > from enabling IPv6 (along with considering possible alternatives).
> > Then comes the security analysis.
> > Then the questions "are the benefits worth the risk"?
> >
> > In many cases, the answer may be "yes". IN other it may be "no". There's
> > no "one size fits all".
> More systems will remain vulnerable longer as malefactors take advantage
> of "IPv6 broken" networks as they leak data over unseen transitional
> protocols. :^(
> >>> IPv6 (as any technology that you'd enable in addition to what you're
> >>> already using), will add more pieces to the puzzle, increase
> complexity,
> >>> and increase the number of potential vulnerabilities that could be
> >>> exploited.
> >> Complexity could be reduced by RAs announcing routes and RDNSS where any
> >> AAAA records in DNS are filtered and any other IPv6 traffic is
> >> black-holed.
> > That is increased complexity itself.
> Exactly.  This was tongue in cheek.  I even said it would not prevent
> any exploits.
> >>> If I don't know how to handle a gun, I'd probably wouldn't have one in
> >>> the first place. But if I *was* handled one, then I'd probably leave it
> >>> as quite as possible, rather than start loading bullets and playing
> with
> >>> the trigger, as if I knew what I was doing....
> >> Internet connectivity IS a loaded gun.  Inaction after "disabling IPv6"
> >> is like leaving the safety off in the presence of children.  Disabling
> >> IPv6 on the LAN offers NO protection nor does it make maintaining
> >> security easier.
> > How could you perform an ND-based attack if IPv6 is disabled at the
> > kernel level?
> There are many exploits that will always remain possible.  Whether by
> spoofing ARP broadcasts, spanning tree protocols, VLANs, etc.  Progress
> is made by achieving an environment able to offer end-to-end security.
> While not everything needs to operate in this way, it is vitally
> important more networks make progress in this direction where data is
> secured by direct communication.  More work needs to be done on DNSSEC,
> SeND, DANE, etc.  SeND can work within mixed environments and not be
> supported by all hosts.  Security can step over less secure hosts for
> now and be limited to Cisco and Juniper routers and switches where
> security is important.
> > And no, I'm not arguing that you shouldn't monitor v6 just because
> > you've disabled it.
> Additional monitoring will be fairly unlikely when they think no one is
> using IPv6.
> >> Please overcome misconceptions regarding NATs and IPv6.  Whether IPv6 or
> >> IPv4 is used, a LAN is vulnerable without SeND.
> > A network is always vulnerable. What changes is what it is vulnerable
> > to. And I personally don't belive in this sort of "silver bullet"...
> > particularly when a solution is hard to deploy, and it's associated
> > complexity is well above 0.
> > Such complexity, by itself, is prone to introduce vulnerabilities in the
> > corresponding implementations.
> That is what they said about SSL.  :^)  One might hope DANE and dynamic
> DNSSEC becomes available, where support for SeND then becomes eas to
> deploy.
> >> Middle Boxes such as
> >> NATs remove many protections otherwise possible.  The LAN is vulnerable
> >> whether through ARP spoofing,
> > ARP traffic is *way* easier to monitor and police than ND traffic is.
> There is no universal defense against ARP or ND spoofing.  And it is
> common for interfaces to utilize many IP addresses.  Using static MAC
> tables might help, but often that is not practical.  While neither ARP
> nor ND traffic can be completely enforced, that was the goal behind
> SeND.  Do we need to wait for the value of security and cost of the
> hardware to become comparable?  It is foolish to think either ND or ARP
> are secure.
> >> spanning tree or NAT table corruption,
> >> etc.  With RFC793 simultaneous-open handshakes, a Sneak Ack Attack can
> >> reverse the logical direction of connection setups.
> > TCP simultaneous opens are not supported by all OSes. If that was the
> > case, we'd probably not need syn cookies or syn caches. Pleasee see the
> > corresponding discussion about "SYN flood attacks" in:
> > http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf
> Dropping packets that combine SYN and RST flags seems logical as well,
> but even that is not a complete solution.
> >> Often applications don't notice when an SSL certificate fails to match
> >> against a domain.  Even with SSL, Middle Boxes offer easy MitM
> >> exploits.  It is absurd to describe NATs as offering improved
> >> protection.
> > Nobody argued that. But it's true that when deploying a NAT you get a
> > "only allow return traffic" stateful firewall as a side effect.
> When done with IPv6, the states are simpler.  Far fewer keep-alives and
> no dynamic reassignment of the destination address.  When a subsequent
> middle box is not present, there are fewer opportunities where traffic
> can injected within the LAN.  There are two types of LAN.  Those that
> have been compromised, and those that compromise has not yet been
> discovered.
> >> Practices that depend on NAT "security" invite prone
> >> systems that do more harm.  IMHO, it is easier to firewall IPv6 than
> >> deal with IPv4 related nonsense such as keep-alives,
> > huh? You'll have keep-alives in v6 if you do stateful firewalling...
> Any duration in regard to IPv6 can have much longer periods without any
> risk of running out of port resources.
> >> dynamic
> >> translations, port mapping, etc.
> >>> Whether the pros outweigh (security-wise) the cons (or not) depends,
> >>> among other factors, where in the network the NAT box is. -- e.g.,
> >>> glearly a CGN has many more negative implications that a NAT at a home
> >>> router.
> >> There are many compromised CPE routers.  An ISP's LSN are not likely to
> >> be any worse.
> > A hacked CPE router only affects that customer. A hacked LSN affects all
> > customers that depend on that system. -- that's the difference.
> Do we agree NATs offer poor security?  To a user, they'll suffer the
> same attack.  For the attacker, one would hope the LSN has improved
> monitoring over what is found in CPE, which is as good a none.
> >>> The bottom-line is that you should make sure that your "assumptions"
> are
> >>> correct. -- e.g., if you're argument for not applying specific v6
> >>> technologies is that "my network is v4-only", you better make sure
> >>> that's the case.
> >> Assuring an assumption of "IPv4 Only" requires a sizable effort that
> >> will prevent improved security from then being employed. :^(
> > Can you explicitly point out what you mean by "improved security"?
> The ability to establish a paradigm of end-to-end security.
> >>>> Any NAT device within a network provides an easily exploited
> opportunity
> >>>> for undetected MITM attacks.  Only End-to-End security offers
> protection
> >>>> from exploits related with ARP or ND+MLD where End-to-End security is
> >>>> likely only possible with IPv6.  This does not need to be IPsec.
> >>> I cannot see why you argue that end-to-end security is only possible
> >>> with IPv6.
> >> It is possible to deploy SeND at Switches and routers without support of
> >> the hosts.  In this fashion, a far greater portion of the path can be
> >> controlled where common LAN exploits can be avoided or detected.
> > Do you argue that this is "deployable" in a tyipical organizational or
> > home network??
> It is deployable when security holds enough value for the organization.
> >>> When it comes to "filtering" as a mitigation for DoS, my take is that
> an
> >>> IPv6 /64 corresponds to what we currently do with a single IPv4
> address.
> >>> Put another way, where in IPv4 you might be filtering a single IPv4
> >>> address or a small prefix, in IPv6 you'd be filtering at least a /64.
> >>>
> >>> It would be worth adding, I agree.
> >> The table size needed for such a strategy will likely increase in by a
> >> factor of about 340,000 over what is used for IPv4 when only IPv6
> >> prefixes are captured.  Of course, this short-cut will disable entire
> >> networks whenever someone forgets their password and tries too many
> >> times.
> > There's no such a thing as a "free lunch".
> Or a practical solution that depends on massive IP address lists.  IMHO,
> this needs to move to crypto validation and interim tables ASAP, a la DANE.
> >>>> Just this prefix space is already more than 56,000 times
> >>>> that of the entire IPv6 address space.  Certificate based access
> should
> >>>> be employed whenever possible might also be good advice.
> >>> Ip address-based authentication is already well-broken with IPv4.
> (e.g.,
> >>> I had mentioned that already when working on a sec assessment of v4
> >>> <http://www.gont.com.ar/papers/InternetProtocol.pdf>). So I'm not sure
> >>> anything changes in this respect when it comes to v6.
> >> Some now hope in a new repute WG to base reputation on IP address
> >> authorizations and message signatures that exclude who sent the message
> >> and its intended recipient!
> > I wasn't aware about this ongoing work. Could you please provide some
> > pointers?
> http://tools.ietf.org/agenda/81/repute.html
>
> Their charter refers to protocols that can not fairly support negative
> reputation assessments.  I am working on a paper to describe details of
> the concerns.
>
> -Doug
>
>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 27 Sep 2011 03:04:47 +0000
> From: Jim Small <jim.small at cdw.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <C04EF542D2911B4C88DE42BEA3CC95CF0BF48E at EXMBD5VH.corp.cdw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Fred,
>
> So why NDP could be worse than ARP ?
> [JRS>] Better and worse.  Better in the sense that it has more features and
> flexibility.  Worse in the sense that since it uses IPv6 it can use (abuse)
> extension headers to bypass current security mechanisms like ACLs and RA
> Guard.
>
> Because it can advertise a default router with a RA? If the answer is yes
> maybe there is a way (which I would
> not recommend anyway) to stop the router from sending RA and configure the
> end node from DHCPv6 or manually. Just like IPv4 would do.
> [JRS>] Currently DHCPv6 is not capable of provisioning a default gateway,
> it relies on SLAAC for this.  So currently disabling SLAAC would prevent
> DHCPv6 from working.
>
> Or is there anything else where NDP spoofing is worst than ARP spoofing ? I
> would really think the opposite...
> [JRS>] I think it will end up being superior, but first the issues with
> extension header abuse and getting mainstream vendors like Microsoft and
> Apple to implement SeND must be addressed.
>
> --Jim
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Tue, 27 Sep 2011 10:06:52 +0200
> From: Marc Heuse <mh at mh-sec.de>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID: <4E81841C.6010704 at mh-sec.de>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Am 27.09.2011 03:28, schrieb Owen DeLong:
> > I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
> > so, I'm not sure how you can say that it is not an equivalent level of
> first
> > hop security.
>
> comparing ARP with NA/NS - you are right.
> But the RA are makeing the difference.
>
> in IPv4 the router is configured by hand or comes from DHCP.
> in IPv6 they can be configured by hand, but otherwise *must* come by RA,
> as there is still no DHCP option for routes/routers.
> You could argue that you can do DHCP spoofing too, yes, but only when a
> device is asking for a new address or if you achieve the a little bit
> more difficult part of sabotaging the renewing of a lease.
> But with RA, an attacker can do that to all times to all systems.
> And if autoconfiguration is active, you can configure DNS servers and
> new routes at anytime to anybody too.
>
> And that changes the threat level. As NDP consists of NS/NA and RS/RA,
> the security is not equivalent. It would only be if you configure routes
> manually on both IPv4 and IPV6.
>
> Greets,
> Marc
>
> --
> Marc Heuse
> Mobil: +49 177 9611560
> Fax: +49 30 37309726
> www.mh-sec.de
>
> Marc Heuse - IT-Security Consulting
> Winsstr. 68
> 10405 Berlin
>
> Ust.-Ident.-Nr.: DE244222388
> PGP: FEDD 5B50 C087 F8DF 5CB9  876F 7FDD E533 BF4F 891A
>
>
> ------------------------------
>
> Message: 14
> Date: Tue, 27 Sep 2011 10:31:49 +0200
> From: Enno Rey <erey at ernw.de>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID: <20110927083149.GA5927 at ernw.de>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> On Tue, Sep 27, 2011 at 04:33:27AM +0200, fred wrote:
> > I would then say that it is a bit more complicated to fool NDP than ARP
> > because of its more sophisticated FSM, NUD, and so on...
> >
> > So why NDP could be worse than ARP ? Because it can advertise a default
> > router with a RA? If the answer is yes maybe there is a way (which I
> would
> > not recommend anyway) to stop the router from sending RA and configure
> the
> > end node from DHCPv6 or manually. Just like IPv4 would do.
>
> nope. as DHCPv6 does (currently, and the respective IETF draft was
> discarded after v01) _not_ allow the distribution of a default router.
> so a node just configured by means of DHCPv6 only will not be able to
> communicate outside its local-link space. [which can be a desired state,
> security-wise, but will probably seldom be desirable functionality-wise ;-)]
>
> as for manual config, not sure if anybody here regards this as a viable way
> in the IPv6 world...
>
> thanks
>
> Enno
>
>
>
>
>
> >
> > Or is there anything else where NDP spoofing is worst than ARP spoofing ?
> I
> > would really think the opposite...
> >
> >
> > Fred
> >
> >
> >
> > Le 27/09/2011 03:28, ??Owen DeLong?? <owend at he.net> a ?crit?:
> >
> > > I will point out that NDP spoofing is no worse than ARP spoofing in
> IPv4,
> > > so, I'm not sure how you can say that it is not an equivalent level of
> first
> > > hop security.
> > >
> > > Owen
> >
> > --
> >
> > Fred Bovy
> > fred at fredbovy.com
> > Skype: fredericbovy
> > Mobile: +33676198206
> > Siret: 5221049000017
> > Twitter: http://twitter.com/#!/FredBovy
> > Blog: http://fredbovyipv6.blogspot.com/
> > ccie #3013
> >
> >
> >
> >
> > _______________________________________________
> > Ipv6hackers mailing list
> > Ipv6hackers at lists.si6networks.com
> > http://lists.si6networks.com/listinfo/ipv6hackers
>
> --
> Enno Rey
>
> ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de
> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474
> PGP FP 055F B3F3 FE9D 71DD C0D5  444E C611 033E 3296 1CC1
>
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Enno Rey
>
> =======================================================
> Blog: www.insinuator.net || Conference: www.troopers.de
> =======================================================
>
>
> ------------------------------
>
> Message: 15
> Date: Tue, 27 Sep 2011 01:44:21 -0700
> From: Owen DeLong <owend at he.net>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID: <F369B99F-ABDA-40CF-8C3D-18F004A5983D at he.net>
> Content-Type: text/plain;       charset=windows-1252
>
>
> On Sep 27, 2011, at 1:31 AM, Enno Rey wrote:
> >
> > as for manual config, not sure if anybody here regards this as a viable
> way in the IPv6 world?
> >
>
> I generally manually configure all servers and use RA/SLAAC for most client
> hosts. I think that manual configuration is not only viable in IPv6, but,
> is the
> preferred method for configuring hosts which provide named services in most
> cases.
>
> Owen
>
>
>
> ------------------------------
>
> Message: 16
> Date: Tue, 27 Sep 2011 18:25:15 +0900
> From: Erik Kline <ek at google.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID:
>        <CAAedzxo4S0Jk__zfX0Lhz=VQCrtTOdu6vy9EMq6AJZnAQOxRug at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> >
> > >Many expect a transition to IPv6 will not occur soon.
> > [JRS>] This is not exactly security related but I have done much research
> > and speaking on this topic.  In fact the largest broadband provider in
> the
> > US (Comcast) will have *completed* their IPv6 rollout sometime next year.
> >  The 2nd largest cable company (Time Warner) is close behind.  There is
> > similar activity in Europe.  Most of the major cellular carriers are
> rolling
> > out IPv6 next year.  Those who think that IPv6 is years away and in for a
> > rude awakening shortly.
> >
>
> Indeed.  From sometime at the end of Q2 next year, prepare for AAAAs for
> everything.  See related presentations from APNIC32 (especially Lorenzo's
> lightning talk).
>
> Seeking ISPs who can rise to the challenge of significant, publicly
> measured
> IPv6 deployment all the way to the user.  Yes, CPEs will also need to be
> ready to take IPv6 across the final gap into the home.  It's going to have
> to be a "whole ecosystem" kind of event.
>
>
> ------------------------------
>
> Message: 17
> Date: Tue, 27 Sep 2011 11:52:23 +0200
> From: fred <fred at fredbovy.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
> Message-ID: <CAA76977.582C%fred at fredbovy.com>
> Content-Type: text/plain;       charset="ISO-8859-1"
>
> Thanks Jim,
>
>
> I think I heard that DHCPv? could not provision a default gateway but it
> sounds so crazy that I immediately forgot this! Thanks...
>
> I don't see any application where NDP would need extension headers...
>
> Strictly NDP, not protocols running on ICMPv6 like MLD where you may need
> the hop-by-hop extension with router alert bit. But NDP... I don't see...
>
> Is there any NDP PDU which requires some Extension Header to work ?
>
> If not may be we should start filtering out such packet, this should not be
> a difficult rule to set in an ACL, and may be just not allow it in the
> future... It there is no other application than hacking...
>
> Or if there is an exception of an Extension header which may be useful,
> just
> permit this one.
>
> And I am 2000% with you than SEND MUST be implemented by Windows and MAC OS
> X. It would make of IPv6 the safest protocol in the world...
>
> Fred
>
>
>
>
> Le 27/09/2011 05:04, ??Jim Small?? <jim.small at cdw.com> a ?crit?:
>
> > Fred,
> >
> > So why NDP could be worse than ARP ?
> > [JRS>] Better and worse.  Better in the sense that it has more features
> and
> > flexibility.  Worse in the sense that since it uses IPv6 it can use
> (abuse)
> > extension headers to bypass current security mechanisms like ACLs and RA
> > Guard.
> >
> > Because it can advertise a default router with a RA? If the answer is yes
> > maybe there is a way (which I would
> > not recommend anyway) to stop the router from sending RA and configure
> the
> > end node from DHCPv6 or manually. Just like IPv4 would do.
> > [JRS>] Currently DHCPv6 is not capable of provisioning a default gateway,
> it
> > relies on SLAAC for this.  So currently disabling SLAAC would prevent
> DHCPv6
> > from working.
> >
> > Or is there anything else where NDP spoofing is worst than ARP spoofing ?
> I
> > would really think the opposite...
> > [JRS>] I think it will end up being superior, but first the issues with
> > extension header abuse and getting mainstream vendors like Microsoft and
> Apple
> > to implement SeND must be addressed.
> >
> > --Jim
> >
> >
> > _______________________________________________
> > Ipv6hackers mailing list
> > Ipv6hackers at lists.si6networks.com
> > http://lists.si6networks.com/listinfo/ipv6hackers
>
> --
>
> Fred Bovy
> fred at fredbovy.com
> Skype: fredericbovy
> Mobile: +33676198206
> Siret: 5221049000017
> Twitter: http://twitter.com/#!/FredBovy
> Blog: http://fredbovyipv6.blogspot.com/
> ccie #3013
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
>
>
> End of Ipv6hackers Digest, Vol 3, Issue 7
> *****************************************
>