Guys, I am going to go back and review "IPv6 Neighbor Discovery (ND) Trust Models and Threats: RFC 3756"
http://datatracker.ietf.org/doc/rfc3756/ For all who think that ND and RA in particular does not have problems, here is a UTube video of a hacker at work using RA. http://www.youtube.com/watch?v=TfsfNWHCKK0 Next, there is an interesting web site: http://www.thc.org/thc-ipv6/ You can see the "interesting" tools available: dnssecwalk - performs NSEC walking including Iv6+IPv4 resolving firewall6 - various TCP/UDP ACL bypass test cases fake_pim6 - send fake hello and join/prune pim messages ndpexhaust26 - very performant ndp exhauster based on ICMP error toobig messages but can send many types of packets alive6: ranges are now supported in the input file too parasite6: enhancements to make it way more effective fake_router26: added overlap RA guard evasion type (-E o, -E O) dos-new-ip6: fix that only DAD replies are sent, not full NDP spoofing flood_router26: Added local LAN privacy extension prevention attack randicmp6: - added function which dumps icmp answers received - added funtionality to send a specific type (and also code) dnsdict6: added SRV result address resolving and others. I will review all drafts with the above in mind. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: Alexandru Petrescu <alexandru.petre...@gmail.com> To: Hosnieh Rafiee <i...@rozanak.com> Cc: ipv6@ietf.org Sent: Tuesday, March 5, 2013 6:41 AM Subject: Re: 6MAN Agenda for IETF86 Hosnieh, I would have to read the draft and feed back about SSAS. Some of the drafts I mentioned (ND-PD) were presented to 6MAN meeting in Atlanta, and discussed on the email list. One of the drafts (draft-jhlee-mext-mnpp-00) is considered at ISO, but I dont know its status. Another draft which generates IID from VIN (Vehicular Identification Number) we discussed recently in the 6MAN email list is: draft-imadali-its-vinipv6-viid-00.txt We don't have a WG about vehicular communications but we have an email list ITS for Intelligent Transportation Systems (ietf.org/mailman/listinfo/its). We discuss a Charter proposal there. Alex Le 05/03/2013 14:55, Hosnieh Rafiee a écrit : > In the latest version of my draft RFC,SSAS, l have provided > information about using SSAS for mobile nodes and I have specified > the sections of the RFCs that can use this mechanism. So maybe this > can prove useful for vehicular communication too. Are the drafts > that you mentioned discussed in 6man? I have not seen any > discussions about them. Maybe I missed it. If it is in another WG, > would you please tell me which one? > > Thanks, Hosnieh > > > > -----Original Message----- From: ipv6-boun...@ietf.org > [mailto:ipv6-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Dienstag, 5. März 2013 14:40 To: ipv6@ietf.org Subject: Re: 6MAN > Agenda for IETF86 > > ND security is an important topic. > > Let me explain why. > > We consider the use of ND over 802.11p links for vehicular > communications. These links dont have ESSID nor link-layer security. > (it is not clear whether it is legal to run IP straight over > 80211p, being "safety apps") but once it becomes clear the security > question comes up. > > (ND drafts for vehicular communications: > draft-petrescu-autoconf-ra-based-routing draft-kaiser-nd-pd-01 > draft-jhlee-mext-mnpp-00) > > The security of ND on these links needs to be fast and easy to set > up. > > Alex > > Le 05/03/2013 14:33, Nalini Elkins a écrit : >> Karl, >> >> I definitely agree that ND needs to be secured. Also agree that >> neither IPSec nor SEND are viable solutions. >> >> I do not know if I am missing something but I have not seen a >> comprehensive document with these problems detailed. I certainly >> don't have a solution but I have been trying to at least catalog >> such problems. If there is such a document, would appreciate >> anyone letting me know. >> >> If there isn't, if you would like, we can collaborate on such a >> document and create a draft for the IETF meeting in Berlin. Maybe >> v6Ops is a place to discuss this topic. Once many at IETF agree >> that indeed there is a problem, then we can discuss a potential >> solution. Thanks, >> >> Nalini Elkins Inside Products, Inc. (831) 659-8360 >> www.insidethestack.com >> >> ---------------------------------------------------------------------- >> >> >> -- >> >> > *From:* Karl Auer <ka...@biplane.com.au> >> *To:* ipv6@ietf.org *Sent:* Tuesday, March 5, 2013 1:37 AM >> *Subject:* Re: 6MAN Agenda for IETF86 >> >> On Mon, 2013-03-04 at 16:02 -0800, Bob Hinden wrote: >>> A Simple Secure Addressing Generation Scheme for IPv6 >>> AutoConfiguration draft-rafiee-6man-ssas-01.txt [...] >>> DHCPv6/SLAAC Address Configuration Interaction Problem Statement >>> draft-liu-bonica-dhcpv6-slaac-problem-01.txt >>> >>> We did not think there had been enough discussion or interest on >>> the w.g. list to guarantee a speaking slot. We allocated short >>> slots at the end of the session if there is time before the >>> meeting ends. If anyone (other than the authors) think one of >>> these should be given more time, please speak up. >> >> For what it's worth it seems to me that there is a gaping hole >> around securing ND. IPSec is obviously ridiculous, SEND is only >> marginally less ridiculous. Maybe SSAS is a way forward? Or maybe >> noone else thinks ND needs to be secured? Maybe the meeting could >> attempt to gauge whether this is actually a real problem. I think >> it is, and I urge others to speak up if they too think this should >> be pursued. >> >> If there is a priority to these things, then sorting out the >> perceived and actual discrepancies\ and ambiguities in the meaning >> of the RA M and O flags would seem pretty important. Otherwise >> they will end up cemented into even more implementations than they >> are now. The way Windows handles them is just plain broken, and if >> the RFCs support that way of handling them, then the RFCs are >> broken. At very least this topic needs some impetus. >> >> Regards, K. >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> ~ >> >> > Karl Auer (ka...@biplane.com.au <mailto:ka...@biplane.com.au>) >> http://www.biplane.com.au/kauerhttp://www.biplane.com.au/blog >> >> GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A >> Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 >> >> >> -------------------------------------------------------------------- >> >> >> IETF IPv6 working group mailing list ipv6@ietf.org >> <mailto:ipv6@ietf.org> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > >> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
