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/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 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
--------------------------------------------------------------------
