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: [email protected]
[mailto:[email protected]] On Behalf Of Alexandru Petrescu Sent:
Dienstag, 5. März 2013 14:40 To: [email protected] 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 <[email protected]>
*To:* [email protected] *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 ([email protected] <mailto:[email protected]>)
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 [email protected]
<mailto:[email protected]> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list [email protected] Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list [email protected] Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
