>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 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
