Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 4 Aug 2010 10:55:52 +0200

Hi Erik, Samita,

I would prefer to have separate messages as well.

Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Samita Chakrabarti
Sent: mardi, 27. juillet 2010 11:06
To: 'Erik Nordmark'; '6lowpan'
Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check

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-masked] [mailto:[email-masked]] 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-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan