Subject: Neighbor Discovery from non-neighbors

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Oct 2008 10:08:07 +0300 (EEST)

FYI,

http://security.freebsd.org/advisories/FreeBSD-SA-08:10.nd6.asc

"IPv6 routers may allow "on-link" IPv6 nodes to create and update the 
router's neighbor cache and forwarding information.  A malicious IPv6 
node sharing a common router but on a different physical segment from 
another node may be able to spoof Neighbor Discovery messages, 
allowing it to update router information for the victim node."
...

"NOTE WELL: The solution described below causes IPv6 Neighbor 
Discovery Neighbor Solicitation messages from non-neighbors to be 
ignored. This can be re-enabled if required by setting the newly added 
net.inet6.icmp6.nd6_onlink_ns_rfc4861 sysctl to a non-zero value."

+		/*
+		 * According to recent IETF discussions, it is not a good idea
+		 * to accept a NS from an address which would not be deemed
+		 * to be a neighbor otherwise.  This point is expected to be
+		 * clarified in future revisions of the specification.
+		 */

I wonder if off-list discussion qualifies as "IETF discussion".  Or 
has this been raised on a list somewhere?

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/nd6_nbr.c.diff?r1=1.52;r2=1.53

I guess we have a problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 02 Oct 2008 00:22:39 -0700

At Thu, 2 Oct 2008 10:08:07 +0300 (EEST),

> I guess we have a problem.

It was me who suggested the comment, so if the wording surprised you
it was my fault.  I meant by "IETF discussion" a series of e-mail
threads including this one:
http://www.ietf.org/mail-archive/web/ipv6/current/msg09544.html

and although I've not seen a clear consensus my understanding is that
we at least saw a problematic case in the current specification,
specifically, this bullet of the on-link definition (RFC4861)

                    - any Neighbor Discovery message is received from
                      the address.

that's the rational of "it is not a good idea".

But just as I said I've not seen a consensus about how to deal with
this in the specification, so I only indicated an expectation of
future "clarification".

Aside from the possibly inappropriate comment wording, does that
address your concern?

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Oct 2008 10:35:43 +0300 (EEST)

...
> Aside from the possibly inappropriate comment wording, does that

Apologies.  My "I guess we have a problem" could be interpreted to 
apply to a) "the IETF discussion" comment, b) that there is no 
official update going on with this effort, or c) both.  My intent was 
to  use it to b) only.

I think it's a serious problem that we see issues in the specs, we 
discuss them, yet we don't track them and we don't reach closure on 
how to proceed with them.

---

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

For the record, in private email discussions on this issue, Jinmei has
been the only one who has not reached consensus with us who are myself,
Wes Beebee, Erik Nordmark, Thomas Narten, and David Miles.  In fact,
Thomas proposed new text to be added to our IPv6 Subnet Model draft to
address this very problem but Jinmei didn't bother to reply to that new
text since August 20, 2008. It's time to open this discussion to 6man.
We propose the following text be added to the IPv6 Subnet Model draft. I
will forward one email from our private thread to the mailer as well. A
pointer to the IPv6 Subnet Model draft is below.

http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-01
.txt

The following new text was proposed by Thomas to add below bullet 2 of
section 2 of the draft.

[Note that the following items (from RFC 4861):	      

                    - a Neighbor Advertisement message is received for
                      the (target) address, or

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

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pekka Savola
Sent: Thursday, October 02, 2008 3:36 AM
To: JINMEI Tatuya / ????
Cc: [email-masked]
Subject: Re: Neighbor Discovery from non-neighbors

...
> Aside from the possibly inappropriate comment wording, does that 

Apologies.  My "I guess we have a problem" could be interpreted to apply
to a) "the IETF discussion" comment, b) that there is no official update
going on with this effort, or c) both.  My intent was to  use it to b)
only.

I think it's a serious problem that we see issues in the specs, we
discuss them, yet we don't track them and we don't reach closure on how
to proceed with them.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Oct 2008 09:46:06 -0400

Jinmei,

We have been waiting since August 20th for a reply to this one.  Could
you please give us an ETA on when will you reply to this one?  I ask you
to only reply Yes or No to adding this paragraph in the IPv6 Subnet
Model draft.  If the answer is No, then please also explain briefly why
not?  

Then we'll see how to proceed on this one.  Anyone else is welcome to
chime in.

Thanks.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, October 02, 2008 7:32 AM
To: Pekka Savola; JINMEI Tatuya / ????
Cc: [email-masked]
Subject: RE: Neighbor Discovery from non-neighbors

Hemant

-----Original Message-----

...

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Oct 2008 19:36:12 -0400

David,

How are you? When you get this email, I hope you had a safe travel back
home.

After, Erik Nordmark, Thomas Narten, myself, and Wes Beebee discussed
the issue you brought to v6ops @ IETF and we summarized that your issue
will not be able to touch the router forwarding tables, why did anyone
post a security warning to FeeeBSD with totally erroneous data?

We never agreed during discussions in IETF that there was a security
problem.  All that happens with the issue you raised is creation of a
bogus entry in the router or node ND-cache. 

I don't consider the following data (shown in square brackets) in the
BSD security posting as valid:

1.

[II.  Problem Description

IPv6 routers may allow "on-link" IPv6 nodes to create and update the
router's neighbor cache and forwarding information.  A malicious IPv6
node
sharing a common router but on a different physical segment from another
node may be able to spoof Neighbor Discovery messages, allowing it to
update
router information for the victim node.]

Router forwarding table will not be updated.

2. Another false analysis is this data:

[III. Impact

An attacker on a different physical network connected to the same IPv6
router as another node could redirect IPv6 traffic intended for that
node.
This could lead to denial of service or improper access to private
network
traffic.]

Traffic will not be redirected.

So the whole premise behind the BSD warning is baseless.

But we still totally appreciate the issue you raised and the five of us
did appreciate that bullets 3-4 of on-link determination in RFC4861 did
deserve a revisit and that is why Thomas proposed the new text to be
added to our draft.  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pekka Savola
Sent: Thursday, October 02, 2008 3:08 AM
To: [email-masked]
Subject: Neighbor Discovery from non-neighbors

FYI,

"IPv6 routers may allow "on-link" IPv6 nodes to create and update the
router's neighbor cache and forwarding information.  A malicious IPv6
node sharing a common router but on a different physical segment from
another node may be able to spoof Neighbor Discovery messages, allowing
it to update router information for the victim node."
...

"NOTE WELL: The solution described below causes IPv6 Neighbor Discovery
Neighbor Solicitation messages from non-neighbors to be ignored. This
can be re-enabled if required by setting the newly added
net.inet6.icmp6.nd6_onlink_ns_rfc4861 sysctl to a non-zero value."

+		/*
+		 * According to recent IETF discussions, it is not a
good idea
+		 * to accept a NS from an address which would not be
deemed
+		 * to be a neighbor otherwise.  This point is expected
to be
+		 * clarified in future revisions of the specification.
+		 */

I wonder if off-list discussion qualifies as "IETF discussion".  Or has
this been raised on a list somewhere?

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/nd6_nbr.c.diff?r1
=1.52;r2=1.53

---

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

At Thu, 2 Oct 2008 07:32:19 -0400,

> pointer to the IPv6 Subnet Model draft is below.

I'm really sorry for not being responsive about the proposed text.  I
didn't mean to be a showstopper in the process, but I was clearly
guilty for the delay.

I also admit that I was in a minority in the relatively small group of
the discussion (i.e. 1 among 6), but I don't think that necessarily
means we, as a wg, reach a clear consensus.

And, for that matter, I don't think I've opposed to revisiting or even
removing the third and fourth bullets of the on-link definition of
RFC4861 per se.  My point was that since this change will make
existing implementations that conform to published specifications
non-compliant, the change should be done based on informed-consent,
rather than a clarification document that just "spells out the most
important (subtle) difference" (quoted from the abstract of the
subnet-model draft).

We might end up regarding no reaction from implementors as a
"consensus", which is fine for me, but I'd at least request an
explicit wg last call with a note that this document will invalidate
existing implementations.

I'm okay with the proposed text from Thomas itself (with some
supplemental comments - see below), but I'd also like the entire
document will be adjusted so that this important change will be
reflected.  For example, the current abstract:

   IPv6 specifies a model of a subnet that is different than the IPv4
   subnet model.  The subtlety of the differences has resulted in
   incorrect implementations that do not interoperate.  This document
   spells out the most important difference; that an IPv6 address isn't
   automatically associated with an IPv6 on-link prefix.

doesn't say anything about the change (understandably, because the
issue was raised after this version of the draft).  This should be
amended like this:

   IPv6 specifies a model of a subnet that is different than the IPv4
   subnet model.  The subtlety of the differences has resulted in
   incorrect implementations that do not interoperate.  This document
   spells out the most important difference; that an IPv6 address isn't
   automatically associated with an IPv6 on-link prefix.  This
   document also invalidates the definition of on-link prefixes
   currently defined in RFC4861 due to security concerns.

We should also note that invalidating the part of on-link definition
affects other parts of RFC4861.  For example, it will invalidate this
point:

   If the Source Address is not the unspecified
   address and, on link layers that have addresses, the solicitation
   includes a Source Link-Layer Address option, then the recipient
   SHOULD create or update the Neighbor Cache entry for the IP Source
   Address of the solicitation.
(section 7.2.3)

we should also clearly state each affected part is invalidated;
otherwise, the reader will be confused about the discrepancy.

Another minor point: I do not actually think the third bullet of the

>                     - a Neighbor Advertisement message is received for

because even if the target address of NA is bogus, it won't
automatically cause creation of a corresponding neighbor cache: the
receiving node will ignore the NA (under a "SHOULD") unless it already
has a neighbor cache entry for that node.  Still, this third bullet
may be a redundant as part of definition, so I don't oppose to
removing it this time.  But doing so in the context of a security
concern may be misleading.

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 03 Oct 2008 21:00:36 -0700

At Fri, 3 Oct 2008 19:36:12 -0400,

> BSD security posting as valid:

You seem to forget the fact that the FreeBSD security advisory
generally talks about that particular implementation.  Anything
written there is true, if you read it in the context of the FreeBSD
implementation (as an extreme example, a PC router that runs an
unmodified FreeBSD kernel).  I believe people normally interpret this
document in the correct context and won't be confused.

You also seem to be trapped in a specific router implementation model
where neighbor cache entries and forwarding tables are clearly
separated and the latter doesn't affect the former.  As far as I
understand it, such a model is not a protocol-level requirement, but
just an implementation choice.  And, in fact, the FreeBSD kernel (or
BSD implementations in general) tightly couples the ARP/ND tables with
the forwarding table, so if a bogus entry is inserted in the former,
it will affect forwarding behavior.  As mentioned in the first
paragraph, a PC router using a vanilla FreeBSD kernel behaves that
way.  I won't surprised even other commercial routers that use a
customized BSD kernel have the same problem.

---
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Oct 2008 08:37:34 -0400

>You seem to forget the fact that the FreeBSD security advisory
generally talks about that particular implementation.  Anything written
there is true, if you read it in the context of the FreeBSD
implementation (as >an extreme example, a PC router that runs an
unmodified FreeBSD kernel).  I believe people normally interpret this
document in the correct context and won't be confused.

>You also seem to be trapped in a specific router implementation model
where neighbor cache entries and forwarding tables are clearly separated
and the latter doesn't affect the former.  As far as I understand it,
>such a model is not a protocol-level requirement, but just an
implementation choice.  And, in fact, the FreeBSD kernel (or BSD
implementations in general) tightly couples the ARP/ND tables with the
forwarding >table, so if a bogus entry is inserted in the former, it
will affect forwarding behavior.  As mentioned in the first paragraph, a
PC router using a vanilla FreeBSD kernel behaves that way.  I won't
surprised even other >commercial routers that use a customized BSD
kernel have the same problem.

>Internet Systems Consortium, Inc.

BSD has a bug that it needs to fix.  Further, it's debatable that
separation of ND-cache and data forwarding table for a node are not a
protocol-level requirement.  RFC4861 clearly describes a Conceptual
Sending Algorithm in section 5.2 - both a host and host portion of an
IPv6 router follow this section.  Internally, a node may implement its
s/w architecture and code any way the implementation wants to.  But
conceptually, the data forwarding from this section has to be applied.
The section clearly says the following:

  [When sending a packet to a destination, a node uses a combination of
   the Destination Cache, the Prefix List, and the Default Router List
   to determine the IP address of the appropriate next hop, an operation
   known as "next-hop determination".]  

Where does one see ND-cache being used in a data forwarding decision or
what is called as next-hop determination? 

Further, in the discussion of the David Miles issue, none of us from
IETF in myself, Erik, Thomas, and Wes agreed there is a security issue
with the problem David Miles reported. 

Hemant

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 06 Oct 2008 11:14:53 -0700

At Sun, 5 Oct 2008 08:37:34 -0400,

> what is called as next-hop determination? 

Hmm...good point.  I've not realized for 10+ years that the conceptual
sending algorithm doesn't really use the full definition of "on-link"
(as defined in Section 2.1 of RFC2461/4861) to "determine whether the
packet's destination is on- or off-link."  That is, while the
definition "on-link" per section 2.1 is as follows:

1. it is covered by one of the link's prefixes (e.g., as indicated by
   the on-link flag in the Prefix Information option), or
2. a neighboring router specifies the address as the target of a
   Redirect message, or
3. a Neighbor Advertisement message is received for the (target)
   address, or
4. any Neighbor Discovery message is received from the address.

the conceptual sending algorithm doesn't mention bullets 3 or 4 at
all.

If the original intent of the spec authors was to ignore these
additional conditions in the conceptual sending algorithm, I'll more
strongly agree that removing the third and fourth bullets is the right
way to go.

---
JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Oct 2008 15:38:28 -0400

> the conceptual sending algorithm doesn't mention bullets 3 or 4 at

Correct. 

> strongly agree that removing the third and fourth bullets is the right

At least this original author doesn't recall *intending* that the
additional bullets be ignored. That is, I don't recall that we
intentionally put bullets 3 and 4 into the document for a particular
reason.  Rather, I think this is just a classic case of imprecise text
not being caught during earlier review cycles. :-(

Going back to an earlier message:

> means we, as a wg, reach a clear consensus.

The WG clearly has to agree and sign off on any private discussions
that we (or others) have held. The private discussions that I've been
involved with were only intended to try and get a subset of us on the
same page before going back to the WG, in order to spare the WG too
much mail. :-)

> important (subtle) difference" (quoted from the abstract of the

Agreed.

> existing implementations.

Invalidate is a strong word. I think we all agree that the issue that
has been raised can lead to to a security issue. I would assume that
implementations that suffer from this "feature" will want to fix their
code. I don't think we should be too worried about whether a spec
change to acheive this invalidates existing implementations! (But the
WG will decide that.)

>    currently defined in RFC4861 due to security concerns.

IMO, "invalidates" is too strong. I think "clarifies" or "updates" is
just fine. Invalidates suggests that we are making a change from
something that was originally done a certain way intentionally. I
don't think the current definition was done intentionally. It clearly
has a bug in it that we should have caught earlier.

> otherwise, the reader will be confused about the discrepancy.

Yes. This makes sense.

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 17 Oct 2008 17:13:32 -0700

At Fri, 10 Oct 2008 15:38:28 -0400,

> change to acheive this invalidates existing implementations! (But the

[snip]

> has a bug in it that we should have caught earlier.

I don't see what's wrong with 'invalidate', but I don't insist on a
specific wording.  I'm fine as long as the new document clearly warns
that a RFC4861-compliant implementation may need to be modified due to
that document.

---
JINMEI, Tatuya