Zach,
I also don't have any problems with the current multi-hop DAD and don't
want to make any controversial changes that would delay the draft
further than necessary.
I noticed in the title of the message" multi-hop DAD ttl=255 check". I
do think we could send the multi-hop messages with a smaller ttl so
stacks can maintain the rule that a ttl of 255 should never be forwarded.
Daniel.
Zach Shelby wrote:
From my experience with implementations, I don't find the current NS/NA based multihop DAD solution to be a problem. Personally, I have no problem with a separate message type for multihop DAD (we tried that solution for a couple years already). However, I don't recommend that we take this path as a WG - it is too late to start making such a change. Especially considering ZigBee IP, we should only be making minimal changes required to finish ND.
Other thoughts?
Zach
On Jul 27, 2010, at 11:06 AM, Samita Chakrabarti wrote:
Having a separate message type for multihop DAD sounds like a very good idea
to me. It solves many problems from security-hole to filter-setting as
mentioned below and it'd be also easier for possible extensions in the
future for multi-hop DAD related activities.
Thanks,
-Samita
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Erik Nordmark
Sent: Monday, July 26, 2010 4:23 AM
To: 6lowpan
Subject: [6lowpan] Security issues around multi-hop DAD ttl=255 check
In nd-10 and nd-11 the multi-hop DAD functionality uses special forms of
NS/NA, and those special forms must not cause normal ND processing since
it
is not subject to the ttl=255 verification (hence off-link senders can
inject spoofed multi-hop DAD messages.) Basically those messages only
interact with the DAD table in the 6LBR.
This means that it would be useful to be able to specify firewall rules
that
can block the multi-hop DAD messages. However, the awkward way we ended up
specifying these messages makes this very hard. Basically a multi-hop DAD
message is defined as a NS or NA which contains an ARO option of length=4,
requiring to parse the options to see whether the message has normal NS/NA
semantics or the special multi-hop DAD semantics.
It would be a lot easier for a firewall to filter them out if we instead
use
a separate ICMP type for these multi-hop DAD messages.
I think an implementation would be simpler in that case too, since it
allows
the implementation to uniformly do the TTL check for all NS/ND and doesn't
need to track the "special" ones throughout the code.
If folks have specific implementation feedback on the multi-hop DAD in
nd-10
I'd be interested in finding out; either on the mailing list or in person
in
Maastricht.
*If* we want to change this I think the changes are quite minor:
- We need a new ICMP type for the multi-hop DAD message.
- We can use the ICMP code field to specify request (code=0) and reply
(code=1) *or* have a separate ICMP type for the request and reply
- We no longer need the Registered Address field in the ARO option
since we instead can use the target address in the multi-hop DAD
message. This makes the multi-hop DAD messages 16 bytes smaller.
- Since the name of the address is now "target address" it probably
makes sense to use TLLAO instead of SLLAO i.e., a change in the
option type number we use with the multi-hop DAD messages.
---
Thus a multi-hop DAD message would look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD4 | Code = 0/1 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Followed by an ARO option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| EUI-64 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... and a TLLA option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---
Comments?
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
