RE: 6MAN Agenda for IETF86

["Hosnieh Rafiee" <[e-mail]>]

Dear Nalini,

Yes. That RFC is an old RFC that explained the most probable attacks that
could be used against ND. This is the main reason that ND is not at all
secure and the people who think that just privacy is enough (like what was
just implemented in windows) are making a big mistake.

In our lab we are currently working on devising possible attacks against
IPv6 networks in order to find ways of preventing them. We hope to be able
to provide the necessary tools to provide the security necessary to use
against these many different types of attack. 

Thank you,
Hosnieh

-----Original Message-----
From: Nalini Elkins [mailto:[e-mail]] 
Sent: Dienstag, 5. März 2013 16:25
To: Alexandru Petrescu; Hosnieh Rafiee; Karl Auer
Cc: [e-mail]
Subject: Re: 6MAN Agenda for IETF86

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.
[phone]
www.insidethestack.com



________________________________
From: Alexandru Petrescu <[e-mail]>
To: Hosnieh Rafiee <[e-mail]>
Cc: [e-mail]
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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alexandru Petrescu Sent:
> Dienstag, 5. März 2013 14:40 To: [e-mail] 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. [phone] 
>> www.insidethestack.com
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
>>
--
>>
>>
> *From:* Karl Auer <[e-mail]>
>> *To:* [e-mail] *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 ([e-mail] <mailto:[e-mail]>)
>> 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 [e-mail]
>> <mailto:[e-mail]> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list [e-mail] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>>
>>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------