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,
We updated the draft based on your recommendations.
See the link below for the new draft.
We appreciated the urgency of your security concern because
BSD is vulnerable and this new version should fix any specification
problem.
Hemant, Wes, and Erik
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.
