RE: Neighbor Discovery from non-neighbors
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Neighbor Discovery from non-neighbors
Title: Re: Neighbor Discovery from non-neighbors
David,
Humbles apologies that I addressed you as Miles.
Hemant
Miles,
I'll see what we can do towards putting together another
version of the draft with Thomas' suggested text and Jinmei's feedback in next
few days or earlier. As you can see Jinmei doesn't have any objection to
the new text from Thomas but he wants some extra text as in changing our draft
to reflect an important change going into it - of course, we can accommodate
Jinmei on that; we didn't do that yet because we weren't sure if the new
text would be accepted or not. Jinmei also said that section 7.2.3 of
RFC4861 needs some change to be in line with the on-link definition bullets
revisit. Thomas has already suggested text for such a change (in our
private email thread) to this section that goes like "create a ND-cache entry
only if the source address of the NS is on-link per other indications".
Hemant
Hemant,
I think it is important for us to move forward
with the proposed clarification ASAP. Is it possible to get the proposed text
for the IP Subnet Model draft relating to ND in a new revision of the draft and
posted?
As you have said: there is a bug and it needs to be fixed and we
have been asked to assit by adding some clarifying statements. Please direct any
grievances my way, and off-list, with respect to this being a security
vulnerability as I accept responsibility for that direction.
To keep us
on topic, can we get review of the proposed text from members of this working
group?
-David
----- Original Message -----
From: Hemant
Singh (shemant) <shemant at cisco.com>
To: Jinmei_Tatuya at isc.org
<Jinmei_Tatuya at isc.org>
Cc: Pekka Savola <pekkas at netcore.fi>;
ipv6 at ietf.org <ipv6 at ietf.org>; MILES DAVID
Sent: Sun Oct 05 20:37:34
2008
Subject: RE: Neighbor Discovery from non-neighbors
>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
>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
--------------------------------------------------------------------
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.
