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

From: Erik Nordmark <[email-masked]>
Date: Mon, 26 Jul 2010 04:22:34 -0700

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

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 27 Jul 2010 02:06:27 -0700

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
> 
> 
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.
> 
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.
> 
use
> a separate ICMP type for these multi-hop DAD messages.
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.
> 
nd-10
> I'd be interested in finding out; either on the mailing list or in person
in
> Maastricht.
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Zach Shelby <[email-masked]>
Date: Tue, 27 Jul 2010 14:39:17 +0200

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

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

---

From: Daniel Gavelle <[email-masked]>
Date: Tue, 27 Jul 2010 18:08:46 +0100

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.

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 27 Jul 2010 23:14:55 -0700

> want to make any controversial changes that would delay the draft

FWIW I don't have a problem deferring this discussion until later so we 
can get out -12.

> stacks can maintain the rule that a ttl of 255 should never be forwarded.

The ttl check is on the receiver. All of RFC 4861 says that a ND message 
(NS, NA, RS, RA, redirect) with ttl != 255 must be discarded by the 
receiver. The multi-hop DAD use of NS/NA in 6lowpan-nd is an exception 
to that.

    Erik

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 28 Jul 2010 20:28:48 +0100

Erik,

> receiver. The multi-hop DAD use of NS/NA in 6lowpan-nd is an exception 

Some stacks have the rule that any message with a TTL of 255 should
never be forwarded on transmit.  Also a TTL of 255 will remain in the
network for a long time if there is a loop.  I think it would be better
if the multi-hop messages were sent with a smaller TTL (e.g. 64) rather
than 255.  The exception on receive you mention would still be required.

Daniel.

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 28 Jul 2010 20:29:26 +0100

Erik,

Daniel.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2010 00:45:08 -0700

On 07/28/10 12:28 PM, Daniel Gavelle wrote:
> Erik,
>
>> The ttl check is on the receiver. All of RFC 4861 says that a ND
>> message (NS, NA, RS, RA, redirect) with ttl != 255 must be discarded
>> by the receiver. The multi-hop DAD use of NS/NA in 6lowpan-nd is an
>> exception to that.
>
> never be forwarded on transmit.

FWIW That doesn't seem to have any basis in an RFC.

In any case, your comments are not about the security issues with the 
ttl check, but about the ttl used to transmit the multihop dad. Those 
are two orthogonal issues.

> Also a TTL of 255 will remain in the

That we could fix by introducing a protocol constant for the multihop 
DAD hoplimit and referring to it in the spec.

Is 64 a reasonable upper limit on the diameter for a 6lowpan?

    Erik

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Jul 2010 10:00:03 +0200

> Is 64 a reasonable upper limit on the diameter for a 6lowpan?

These will be sent by routers which should have a reasonable idea of the network diameter.
No need to fix this in the spec, I believe.

Gruesse, Carsten