FYI
-----Original Message-----
From: Thomas Narten [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 9:52 AM
To: JINMEI Tatuya / ????
Cc: Wes Beebee (wbeebee); MILES DAVID; Hemant Singh (shemant); Erik
Nordmark
Subject: Re: IPv6 Subnet Model
JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]> writes:
> Some meta-level comments first:
> I'd rather like the 'ipv6-subnet-model' draft to concentrate on
> clarifying points in the existing ND specification that have been
> misunderstood by some implementations. If we want to update this part
> of the spec now, I'd rather make a separate draft "The last two
> bullets of on-link definition considered harmful" (which should
> actually be a better title).
As it is, the reason we have a separate draft for the subnet model is
that we don't want to reissue ND at this time. The actual clarification
belongs in the ND spec, IMO. The actual content of the document is
almost too small to even warrant its own document as it is. The
document is also going out as a PS and is listed as updating 4861. So, I
don't really see why we shouldn't have the revised on-link text included
in it. Having it in yet another 1/2 page document seems silly to me.
> If we incorporate this issue into the 'ipv6-subnet-model' draft, I'd
> like to see a clear consensus on this in the working group since it
> will significantly change the role of this document and affect much
> more existing implementors. We should probably even change its title.
> (I'd not necessarily object to this approach once the wg can reach
> consensus on this point).
Sure. But I don't expect any real pushback from the WG. The on-link
definition needs to be fixed somewhere. Who is going to argue against
that? And this (the subnet model) document really needs to be able to
state or point to the correct definition of on-link.
> Specific comments on the proposed text follow:
> At Tue, 19 Aug 2008 13:03:59 -0400,
> Thomas Narten <[EMAIL PROTECTED]> wrote:
> > Note that the following items (from RFC 4861):
> >
> > - a Neighbor Advertisement message is received
for
> > the (target) address, or
> >
> > - any Neighbor Discovery message is received
from
> > the address.
> >
> > are not sufficient to consider an address to be on-link and
> > will be removed in a future update of RFC 4861. A literal
> > reading of the two tests would allow a neighboring intruder to
> > generate ND or NA messages that would result in a spoofed
> > address being improperly considered on-link. Only addresses
> > that are covered by the above on-link definition-link should
> > be treated as on-link from a sending or forwarding
> > perspective.
> I think we should describe the issue better. While the above concern
> itself is not incorrect, the basic sense of this type of concern is
> already well-known and (at least partially) described in RFC3756.
So should the above text simply refer to 3756 then? I have no issue with
that.
> For example, an attacking node can easily exploit forged redirect
> messages for the same purpose (but only for hosts as the victim).
> So, if we specifically want to change these particular points at this
> timing while leaving other general issues, I believe we should give
> sufficient explanation for that. In my understand, the main point is:
> - this can be used as a route injection attack from a malicious host
> to a router (not to another host)
Observation: the reason this attack works is because some
implementations don't scope ND messages properly. That is, they allow an
ND/NA received on one interface to impact data structures that are
global rather than per-interface. Logically, ND/NA traffic should only
apply to the interface/link on which it was received on. E.g, consider
what happens with IPv6 LL addresses, especially if the same address
(with a different MAC addr) is used on different links.
So, maybe we should state this more clearly as:
are not sufficient to consider an address to be on-link and
will be removed in a future update of RFC 4861. A literal
reading of the two tests would allow a neighboring intruder to
generate bogus ND or NA messages that result in a spoofed
address being improperly treated as on-link. This
vulnerability is a specific instance of the broad set of
attacks that are possible by an on-link neighbor [RFC3756].
The threat is particularly problematic in the case of routers,
if they allow such a spoofed message to update their
forwarding tables. Only addresses that are covered by the
above on-link definition-link should be treated as on-link
from a sending or forwarding perspective, and it should be
noted that routers should generally obtain on-link information
from sources other than RAs and redirects.
Is this closer to what you think is needed?
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
