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
