Re: 6MAN Agenda for IETF86

[Alexandru Petrescu <[e-mail]>]

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/kauer http://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
> --------------------------------------------------------------------
>
>
>