David, Humbles apologies that I addressed you as Miles. Hemant ________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hemant Singh (shemant) Sent: Sunday, October 05, 2008 8:16 PM To: MILES DAVID; [EMAIL PROTECTED] Cc: [email protected]; [EMAIL PROTECTED] Subject: RE: Neighbor Discovery from non-neighbors 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 PROTECTED] Sent: Sunday, October 05, 2008 4:46 PM To: Hemant Singh (shemant); [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [email protected] 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 PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Cc: Pekka Savola <[EMAIL PROTECTED]>; [email protected] <[email protected]>; 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 protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
