Subject: comments on draft-gont-6man-lla-opt-validation-00

From: 神明達哉 <[email-masked]>
Date: Mon, 10 Mar 2014 10:52:52 -0700

I have some comments on the draft:

- Can these attack scenarios be exploited with actual implementations?
  And, were the severity measured?

  As for "mapping own link-layer address", it's certainly not good to
  be exploited that way, but I'm not sure exactly how severe it is.
  If this is sufficiently severe, I guess a similar attack with two
  routers are also pretty severe: inject router-A with router-B's
  link-layer address for another node C, and inject router-B with
  router-A's link-layer address for node C.  And this version of the
  attack cannot be avoided with a simple validation on the received
  link-layer address.  I'm not necessarily saying the check for the
  "own address" case because of this, but given these attacks are only
  possible from an on-link attacker, in which case we should worry
  about more nasty things than relatively mild DoS, I'd first like to
  see some severity assessment.

  As for "mapping to broadcast (or some multicast) link-layer
  address": As far as I know BSD kernels implement the "additional
  mitigation" described in Section 3.2:

   An additional mitigation would be for routers to not forward IPv6
   packets on the same interface if the link-layer destination address
   of the received packet was a broadcast or multicast address.

  (see lines 136-153 of
  https://github.com/freebsd/freebsd/blob/master/sys/netinet6/ip6_forward.c)

  Of course, it may be different for other OSes and commercial router
  vendors (or any yet-to-see implementations), but I wonder whether
  the described scenario is really observable today.

- I suspect it's possible that a target link-layer address option
  of NA is equal to receiver's link-layer address if the receiver
  performs DAD and the link-layer address is actually a duplicate.
  In this case, the receiver shouldn't ignore the NA; rather it must
  correctly recognize the duplicate and behave accordingly.  This is a
  very minor case, but may be important along with my first point: we
  should be careful not to break existing valid scenarios due to the
  added validation checks.  But, while identifying such valid
  scenarios and making exceptions, the rule may become more
  complicated and error prone.  So I think it's important to assess
  the severity and the cost-benefit balance of the newly introduced
  measure.

- A minor point, but the example of Section 3.2 assumes Ethernet
  without noting it:

   In Figure 2, the Attacker sends one crafted ND message to Router A,
   and one crafted ND message to Router B. Each crafted ND message
   contains the Target Addres set to Host C's IPv6 address, and a TLLA
   option set to the Ethernet broadcast address (ff:ff:ff:ff:ff:ff).

  I suggest noting the assumption explicitly, just to avoid confusion
  for readers.

- In Section 5:

   Finally, nodes MUST NOT allow the SLLA option to contain one of the
   receiving node's link-layer addresses.  If the option does not pass

  Does this mean node's link-layer addresses of its all interfaces, or
  of the receiving interface?  For the purpose of this document, the
  latter should be enough (the former may not do harm, but may be
  unnecessarily expensive), but it's not clear to me.

- Editorial nits:
  + In the following paragraph of Section 1, s/a the/the/

   This memo documents two scenarios in which an on-link attacker emits
   a crafted ND packet that poisons its victim's neighbor cache.  In the
   first scenario, the attacker causes a victim to map an IPv6 address
   to a the victim router's own link-layer address.  [...]

 + In the last sentence of Section 5,
   s/MUST discarded/MUST be discarded/.  Same for the last sentence of
   Section 6.  (And there may be others).

--
JINMEI, Tatuya

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 13 Mar 2014 20:36:30 +0000

Tatuya-san,

Thank you for your thoughtful review of this document. I will respond to each of your points, below:

Point 1: Fernando has demonstrated each of these vulnerabilities. Maybe he can report on his testing?

Point 2: You are absolutely correct. The validation rules for TLLA should be restated as follows:

OLD>
The TLLA option MUST NOT not contain a broadcast or multicast
address.  If the option does not pass this check, the Neighbor
Discovery message carrying the option MUST be discarded.  Finally,
nodes MUST NOT allow the source link-layer address to contain one of
the receiving node's link-layer addresses.  If the option does not
pass this check, the Neighbor Discovery message carrying the option
MUST discarded.
<OLD

NEW>
The TLLA option MUST NOT contain a broadcast or multicast
address.  If the option does not pass this check, the Neighbor
Discovery message carrying the option MUST be discarded.  

Finally, the ICMPv6 message that contains the TLLA option also contains a Target Address. If that Target Address is not associated with any interface on the receiving node, the link layer address contained by the TLLA option MUST NOT be associated with any interface on the receiving node. If the option does not pass this check, the Neighbor Discovery message carrying the option MUST be discarded.   
<NEW

Point 3: Again, you are correct. We will make this explicit in the next draft version.

Point 4: Again, you are correct. The validation rules for SLLA should be restated as follows:

OLD>
Additionally, the SLLA option MUST NOT not contain a broadcast or
multicast address.  If the option does not pass this check, the
Neighbor Discovery message carrying the option MUST be discarded.
Finally, nodes MUST NOT allow the SLLA option to contain one of the
receiving node's link-layer addresses.  If the option does not pass
this check, the Neighbor Discovery message carrying the option MUST
discarded.
<OLD

NEW>
Additionally, the SLLA option MUST NOT contain a broadcast or multicast address.  If the option does not pass this check, the Neighbor Discovery message carrying the option MUST be discarded.
   
Finally, the SLLA option MUST NOT contain a link layer address that is associated with any interface on the receiving node. If the option does not pass this check, the Neighbor Discovery message carrying the option MUST discarded.
<NEW

Nits: All good catches. We will fix these in the next draft version.

                                     Ron

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, March 10, 2014 1:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-gont-6man-lla-opt-validation-00

  (see lines 136-153 of

- In Section 5:

- Editorial nits:

--
JINMEI, Tatuya

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: 神明達哉 <[email-masked]>
Date: Mon, 17 Mar 2014 09:43:44 -0700

At Thu, 13 Mar 2014 20:36:30 +0000,

> Finally, the ICMPv6 message that contains the TLLA option also contains a Target Address. If that Target Address is not associated with any interface on the receiving node, the link layer address c…

I'm not sure how I should interpret the first sentence...is that
really what you intended?  But anyway, I see the rest of the "finally"
paragraph tries to address the point.  I'd note, however, the check
for the target address would only have to be performed on the
receiving interface (or to be super accurate, interfaces that attache
to the receiving link).

And, my higher level point still stands: I'd first rather like to know
the severity of this "attack" and discuss whether it's worth trying to
avoid with updating the specification at the risk of introducing such
a regression.

> Finally, the SLLA option MUST NOT contain a link layer address that is associated with any interface on the receiving node. If the option does not pass this check, the Neighbor Discovery message ca…

So the intent was to check all interfaces.  I'm not necessarily
opposed to it, but as I said in my original comment, it should be
sufficient if we perform the check for the receiving interface (like
above, to be more accurate for the interfaces that attache to the
receiving link).  Doing it for all interfaces might be unnecessarily
expensive if the node has many, many interfaces.  Also, what if it
happens as follows?

- A router has two interfaces I1 and I2, whose link-layer addresses
  are LLA1 and LLA2, attaching to different links, L1 and L2
  respectively.
- A host is also attached to link L1 on an interface whose link-layer
  address is LLA2.

This is quite pathological (at least in a world where link-layer
addresses are supposed to be unique), but before the proposed change
they should be able to communicate without any problem.  The
introduction of the proposed check on all interfaces would break this
environment.

--
JINMEI, Tatuya

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Mar 2014 10:25:17 +0000

Tatuya-san,

Regarding the TLLA option, I believe that validation check is correct as stated. If the TLLA contains a broadcast or multicast address, it is dangerous, regardless of whether the target IP address is local to the receiving node. The safest course of action would be for all parties to ignore the ND message.

Regarding the SLLA option, you bring up a corner case that must be addressed. So, the validation should probably be restated as follows:

OLD>
Additionally, the SLLA option MUST NOT not contain a broadcast or multicast address.  If the option does not pass this check, the Neighbor Discovery message carrying the option MUST be discarded.
Finally, nodes MUST NOT allow the SLLA option to contain one of the receiving node's link-layer addresses.  If the option does not pass this check, the Neighbor Discovery message carrying the option MUST discarded.
<OLD

NEW>
   
Finally, the SLLA option MUST NOT contain a link layer address that is associated with the interface upon which the ND message was received. If the option does not pass this check, the Neighbor Discovery message carrying the option MUST discarded.
<NEW

Does this adequately address the issue?

                                                Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, March 17, 2014 5:44 PM
To: Ronald Bonica
Cc: [email-masked]; [email-masked]
Subject: Re: comments on draft-gont-6man-lla-opt-validation-00

At Thu, 13 Mar 2014 20:36:30 +0000,
Ronald Bonica <[email-masked]> wrote:

> The TLLA option MUST NOT not contain a broadcast or multicast address.  
> If the option does not pass this check, the Neighbor Discovery message 
> carrying the option MUST be discarded.  Finally, nodes MUST NOT allow 
> the source link-layer address to contain one of the receiving node's 
> link-layer addresses.  If the option does not pass this check, the 
> Neighbor Discovery message carrying the option MUST discarded.
> <OLD
>
> NEW>
> The TLLA option MUST NOT contain a broadcast or multicast address.  If 
> the option does not pass this check, the Neighbor Discovery message 
> carrying the option MUST be discarded.
>

I'm not sure how I should interpret the first sentence...is that really what you intended?  But anyway, I see the rest of the "finally"
paragraph tries to address the point.  I'd note, however, the check for the target address would only have to be performed on the receiving interface (or to be super accurate, interfaces that attache to the receiving link).

And, my higher level point still stands: I'd first rather like to know the severity of this "attack" and discuss whether it's worth trying to avoid with updating the specification at the risk of introducing such a regression.

> Finally, the SLLA option MUST NOT contain a link layer address that is associated with any interface on the receiving node. If the option does not pass this check, the Neighbor Discovery message ca…

So the intent was to check all interfaces.  I'm not necessarily opposed to it, but as I said in my original comment, it should be sufficient if we perform the check for the receiving interface (like above, to be more accurate for the interfaces that attache to the receiving link).  Doing it for all interfaces might be unnecessarily expensive if the node has many, many interfaces.  Also, what if it happens as follows?

This is quite pathological (at least in a world where link-layer addresses are supposed to be unique), but before the proposed change they should be able to communicate without any problem.  The introduction of the proposed check on all interfaces would break this environment.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 19 Mar 2014 11:32:34 -0700

At Wed, 19 Mar 2014 10:25:17 +0000,

> Does this adequately address the issue?

If you are okay with restricting it to the receiving interface, then
yes, basically.  But if we also care about the very minor case where
multiple interfaces are attached to the same link, you might say:

  Finally, the SLLA option MUST NOT contain a link layer address that
  is associated with an interface attached to the link upon which the
  ND message was received. If the option does not pass this check, the
  Neighbor Discovery message carrying the option MUST discarded.

Also, I guess I was probably not really clear in my previous message
on this one:

> I'm not sure how I should interpret the first sentence...is that really what you intended?

I meant the "Finally, ..." sentence by "the first sentence", and it
was purely an editorial matter.  I simply didn't understand what you
tried to suggest by saying: "Finally, the ICMPv6 message that contains
the TLLA option also contains a Target Address." in this context.  If,
for example, this sentence is changed to: "Any ICMPv6 message that
contains the TLLA option also contains a Target Address field", then
I'd understand it.

Note also that "any interface on the receiving node" can (or maybe
should) also be "the receiving interface" here.  (And, the possible
consideration for multiple interfaces attached to the same link also
applies).

--
JINMEI, Tatuya

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Mar 2014 20:55:28 +0000

Tatuya-san,

Thanks! I think that I get it this time. So, do the following edits work?

OLD>
Additionally, the SLLA option MUST NOT not contain a broadcast or multicast address.  If the option does not pass this check, the Neighbor Discovery message carrying the option MUST be discarded. Finally, nodes MUST NOT allow the SLLA option to contain one of the receiving node's link-layer addresses.  If the option does not pass this check, the Neighbor Discovery message carrying the option MUST discarded.
<OLD

NEW>

Furthermore, the SLLA option MUST NOT contain a link layer address that is associated with a local interface that is attached to the link upon which the ND message was received. If the option does not pass this check, the Neighbor Discovery message carrying the option MUST discarded.
<NEW

OLD>
The TLLA option MUST NOT not contain a broadcast or multicast address. If the option does not pass this check, the Neighbor Discovery message carrying the option MUST be discarded.  Finally, nodes MUST NOT allow the source link-layer address to contain one of the receiving node's link-layer addresses.  If the option does not pass this check, the Neighbor Discovery message carrying the option MUST discarded.
<OLD

NEW>
The TLLA option MUST NOT contain a broadcast or multicast address.  If the option does not pass this check, the Neighbor Discovery message carrying the option MUST be discarded.

Any ICMPv6 message that contains the TLLA option also contains a Target Address. If that Target Address is not associated with a local interface that is attached to the link upon which the message was received, the link layer address contained by the TLLA option MUST NOT be associated with a local interface that is attached to the link upon which the message was received. If the option does not pass this check, the Neighbor Discovery message carrying the option MUST be discarded.
<NEW

                                Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Wednesday, March 19, 2014 2:33 PM
To: Ronald Bonica
Cc: [email-masked]; [email-masked]
Subject: Re: comments on draft-gont-6man-lla-opt-validation-00

> Does this adequately address the issue?

If you are okay with restricting it to the receiving interface, then yes, basically.  But if we also care about the very minor case where multiple interfaces are attached to the same link, you might say:

Also, I guess I was probably not really clear in my previous message on this one:

> > NEW>
> > The TLLA option MUST NOT contain a broadcast or multicast address.  
> > If the option does not pass this check, the Neighbor Discovery 
> > message carrying the option MUST be discarded.
> >

I meant the "Finally, ..." sentence by "the first sentence", and it was purely an editorial matter.  I simply didn't understand what you tried to suggest by saying: "Finally, the ICMPv6 message that contains the TLLA option also contains a Target Address." in this context.  If, for example, this sentence is changed to: "Any ICMPv6 message that contains the TLLA option also contains a Target Address field", then I'd understand it.

Note also that "any interface on the receiving node" can (or maybe
should) also be "the receiving interface" here.  (And, the possible consideration for multiple interfaces attached to the same link also applies).

--
JINMEI, Tatuya

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 21 Mar 2014 18:05:00 -0700 (PDT)

Hi,

>________________________________
> From: Ronald Bonica <[email-masked]>
>To: 神明達哉 <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Saturday, 22 March 2014 7:55 AM
>Subject: RE: comments on draft-gont-6man-lla-opt-validation-00
> 
>
>Tatuya-san,
>
><NEW>

Perhaps, "Furthermore, the SLLA option MUST NOT contain any of the link layer addresses, including virtual link layer addresses,  that are associated with ..." to allow for virtual MAC addresses as well as the interface's burnt in address(es) are available, such as when VRRP is being used?

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 24 Mar 2014 15:02:23 +0000

Agreed....

-----Original Message-----
From: Mark ZZZ Smith [mailto:[email-masked]] 
Sent: Friday, March 21, 2014 9:05 PM
To: Ronald Bonica; 神明達哉
Cc: [email-masked]; [email-masked]
Subject: Re: comments on draft-gont-6man-lla-opt-validation-00

Hi,

>Cc: "[email-masked]" <[email-masked]>; 
>"[email-masked]" 
><[email-masked]>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 24 Mar 2014 08:58:32 -0700

At Fri, 21 Mar 2014 20:55:28 +0000,

> Thanks! I think that I get it this time. So, do the following edits work?

Yes, I think so.  Thank you for your patience:-)

--
JINMEI, Tatuya