Subject: Re: 6MAN WG Adoption Call: draft-gont-6man-nd-opt-validation-01

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Mar 2015 04:37:56 +0100

Hi, 神明達哉,

On 02/26/2015 08:49 PM, 神明達哉 wrote:
> At Thu, 26 Feb 2015 09:50:09 +0100,
> Fernando Gont <[email-masked]> wrote:
> 
>>>>> - Sections 4 and 5
>>>>>
>>>>>    o  an address belonging to the receiving node (see Appendix A for
>>>>>       rationale)
> [...]
>> (thinking out loud) So I guess that, in principle, one could say that a
>> node should:
>>
>> * *not* accept an LLA option that includes the same MAC address as that
>> of the interface on which the packet has been received, and,
>>
>> * should accept an LLA option that includes a MAC address of one of its
>> interfaces only if:
>>    + the MAC address corresponds to an interface different from that on
>>      which the packet has been received, *and*
>>    + the MAC address corresponds to an interface that is in the same
>>      zone [RFC4007] as the interface on which the packet has been
>>      received
> 
> I guess the second '+' bullet should be
> 
>     + the MAC address corresponds to an interface that is NOT in the same
>       link zone [RFC4007] as the link zone of the interface on which
>       the packet has been received

mmm.. if the corresponding interface is NOT on the same link zone, then
there would be no valid reason for receiving such MAC address in the option.
   --- i.e., it looks like the text should be "is in the same link
zone.." rather than "is NOT in the same link zone".

What is redundant is the first "*" bullet. I.e., the rules can be
summarized as:

A node should accept an LLA option that includes a MAC address of one of
its interfaces only if:
    + the MAC address corresponds to an interface different from that on
      which the packet has been received, *and*
    + the MAC address corresponds to an interface that is in the same
      zone [RFC4007] as the interface on which the packet has been
      received

> 
> Note also that if this is what you actually meant, the first '+'
> bullet will be redundant.  Also, combining all of these bullets, we
> could just say:
> 
>   a node should (or MUST) not accept an LLA option that includes a MAC
>   address that corresponds to an interface that is in the same link
>   zone [RFC4007] as the link zone of the interface on which the packet
>   has been received

This would prevent communication between two interfaces of the same node
connected to the same link.... right?  (hence this would be incorrect)

> 
> And, to this end, this is essentially what I originally suggested:
> 
>     (Address MUST NOT be any of the following:)
>     o  an address belonging to any of the interfaces of the receiving
>        node that is attached to the link where the ND message is sent
>        (see Appendix A for rationale). 

Same here?

>>> Right.  And, from a quick look at the latest kernel implementation of
>>> FreeBSD, I guess this is probably good enough (at least for that
>>> particular implementation, and maybe for others if they have a
>>> compatible behavior).  The FreeBSD implementation first determines the
>>> outgoing interface, then resolves the link-layer address for the next
>>> hop, and then loops back the packet if the link-layer address is equal
>>> to that of the outgoing interface. So the loopback attack doesn't
>>> seem to be feasible if the forged link-layer address is different from
>>> the one on the outgoing interface for the next hop (which is the one
>>> attached to "Network 1" in the scenario of appendix A).
>>
>> mm.. not sure I understood.
>>
>> I Appendix A you map the Host C address to the router's own link-layer
>> address. Using a FreeBSD box as a router, you do get the expected
>> behaviour: the packet is forwarded over and over again until the Hop
>> Limit is decremented to zero.
> 
> What I tried to say with the example of setup in Appendix A is:
> 
>   - The attacker sends a crafted ND message containing:
>      o  A Target Address, set the IPv6 address of Host C
>      o  A TLLA Option, set to link-layer address of Router A's
>         left-hand side interface (to the network depicted as
>     '...==', which is different from Network 1)
> then
>   - A packet is sent to Router A with the IPv6 Destination Address of
>     Host C.
> then
>   - Router A will forward the packet to Network 1 with the destination
>     link-layer address being the one told via the crafted
>     TLLA option.  Since this link-layer address is not the one of
>      Router A to Network 1, it won't be looped back, and just will be
>      sent out to the wire.  It's most likely to be just dropped there.

The MAC address in the TLLA option is that of Router A's right-hand-side
interfaece.

> BTW, if the network Network 1 and '...==' belong to the same link, it
> may still be received by Router A (not by loopback but from the
> physical link) and cause the loop.  That's the rarer case of the
> general description above.  If an implementation just performs the
> simple check of comparing told link-layer address with that of the
> receiving interface, and yet allows the
> multiple-interface-on-the-same-link configuration, it will still be
> susceptible to the attack.

Well, based on the rules above, these two interfaces would now be on the
same link-zone, and hence the check would mean that you shouldn't accept
the TLLA option...

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Mar 2015 10:19:20 -0700

Sorry for the delayed response, been busy for a while...

At Mon, 09 Mar 2015 04:37:56 +0100,

> connected to the same link.... right?  (hence this would be incorrect)

Right, but in this case, if the LLA is genuine it's a duplicate, so
the communication wouldn't be very successful anyway.  I thought in
the context of this document the basic assumption was to minimize the
risk of attacks described in Appendix A.  The above rule was what I
would envision based on that assumption, that is, so we can prevent
this type of attack even when multiple interfaces belong to the same
link.

> >        (see Appendix A for rationale).

Yes, based on the same assumption.

> there would be no valid reason for receiving such MAC address in the option.

Why not?  Consider the network setup used in Appendix A.  Assume
there's a "host B" attached to the upper left link (Router A is
connected to it via its left hand side interface).  Host B might
happen to have the same LLA as Router A's LLA of the interface to
Network 1.  In this case Router A could receive a legitimate ND
message containing an LLA option whose address "corresponds to an
interface (= the interface to Network 1) that is NOT in the same link
zone as the link zone of the interface on which the packet has been
received (= left hand side one)".

> zone.." rather than "is NOT in the same link zone".

As noted in the above paragraph, there will be a (albeit possibly
theoretical) problem if we don't allow the "is NOT in the same link
zone" case.  As for whether to allow "is in the same link zone.", see
the discussion beginning in this message.  It looks like we had
different assumptions.

> The MAC address in the TLLA option is that of Router A's right-hand-side

That's the original problem description of Appendix A.  I understand
that, and I understand FreeBSD will suffer in that case.  My point is
that to prevent that particular case it's enough to check against the
LLA of the receiving interface of the ND containing the TLLA option in
question (rather than a system wide check, whether it's against all
interfaces of the router or against all interfaces of the receiving
link).  The above example using the "left hand side" interface tried
to explain the attack won't succeed for FreeBSD as long as it performs
the check against the receiving interface (and unless multiple
interfaces belong to the same link, see below).

> same link-zone, and hence the check would mean that you shouldn't accept

Yes, if the implementation diligently applies the rules, including the
detection of the case where multiple interfaces belong to the same
link.  I almost forgot the original context, but this particular part
of the discussion was in the context that the full rules may be
complicated while there's an "easy to detect" check against the
receiving interface only, and that this may actually be enough in most
cases (i.e., there can be a tradeoff point between perfect safety and
implementation simplicity).

--
JINMEI, Tatuya