Subject: Re: Neighbor Discovery from non-neighbors

From: "MILES DAVID" <[email-masked]>
Date: Mon, 6 Oct 2008 04:46:12 +0800

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) <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Pekka Savola <[email-masked]>; [email-masked] <[email-masked]>; 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
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Oct 2008 20:15:44 -0400

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

________________________________

From: MILES DAVID [mailto:[email-masked]] 
Sent: Sunday, October 05, 2008 4:46 PM
To: Hemant Singh (shemant); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Neighbor Discovery from non-neighbors

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) <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Pekka Savola <[email-masked]>; [email-masked] <[email-masked]>;
MILES DAVID

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Oct 2008 20:17:51 -0400

David,
 
Humbles apologies that I addressed you as Miles.  
 
Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Sunday, October 05, 2008 8:16 PM
To: MILES DAVID; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Neighbor Discovery from non-neighbors

Miles,

Hemant

Hemant,

-David

----- Original Message -----
From: Hemant Singh (shemant) <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Pekka Savola <[email-masked]>; [email-masked] <[email-masked]>;
MILES DAVID

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 6 Oct 2008 11:30:45 -0400

David,
 
We updated the draft based on your recommendations.  See the link below
for the new draft.
 
http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-02
.txt
 
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,

-David

----- Original Message -----
From: Hemant Singh (shemant) <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Pekka Savola <[email-masked]>; [email-masked] <[email-masked]>;
MILES DAVID

Hemant