RE: Neighbor Discovery from non-neighbors
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Neighbor Discovery from non-neighbors



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

                    - 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 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: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of
Pekka Savola
Sent: Thursday, October 02, 2008 3:36 AM
To: JINMEI Tatuya / ????
Cc: ipv6 at ietf.org
Subject: Re: Neighbor Discovery from non-neighbors

On Thu, 2 Oct 2008, JINMEI Tatuya / ???? wrote:
>> 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.
>
> 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
...
> Aside from the possibly inappropriate comment wording, does that 
> address your concern?

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.

-- 
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
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.