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

[神明達哉 <[e-mail]>]

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

> 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

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.

> 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

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