Subject: FW: IPv6 Subnet Model

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 2 Oct 2008 07:33:20 -0400

FYI

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
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-masked]> 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-masked]> 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-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 03 Oct 2008 20:42:50 -0700

> FYI

Again, I'm sorry for my overly delayed response.  Now that it's open
(and I don't think there's no secret in the discussion), I'm going to
respond to some other points in the referred message:

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

Frankly, I personally don't expect a pushback either.  But in my past
experience in the 2462bis work, even a most trivial (and reasonable to
me) change could get unexpected pushback once it turns out to require
modification of some existing implementation.  That's why I wanted to
see an explicit support from implementors (as I said in a separate
message, I understand we may still end up regarding no-response as a
"consensus").

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

First of all, now that cert advisories have been issued, I have no
objection to handling this specific point only.

But, I don't agree with your observation above.  This is not because
an implementation don't scope ND messages.  Even if the node only has
a single interface (so no scoping is possible in the first place),
when it receives an NS whose source
- isn't link-local,
- doesn't match any on-link prefix advertised via RA, or
- hasn't been told as on-link via a Redirect,
the node could consider the NS source address as on-link if it
literally applies the definition of on-link as defined in RFC4861,
because it's an address from which a "Neighbor Discovery message is
received".

In fact, *BSDs correctly "scope" ND messages per-link, and it doesn't
confuse the same link-local addresses received on different links wrt
ND processing.  It still believes an unknown address as on-link if it
receives an ND message from that address, based on the literal RFC
definition of on-link.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------