Subject: Re: Neighbor Discovery from non-neighbors

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Nov 2008 14:32:14 -0800

I didn't read this thread sufficiently carefully the first time around, 
and looking at draft-ietf-6man-subnet-model-02 there is one change which 
isn't necessary and that makes ND a bit inconsistent.

Thomas Narten wrote:
>> If the original intent of the spec authors was to ignore these
>> additional conditions in the conceptual sending algorithm, I'll more
>> strongly agree that removing the third and fourth bullets is the right
>> way to go.
> 
> At least this original author doesn't recall *intending* that the
> additional bullets be ignored. That is, I don't recall that we
> intentionally put bullets 3 and 4 into the document for a particular
> reason.  Rather, I think this is just a classic case of imprecise text
> not being caught during earlier review cycles. :-(

FWIW I don't remember a good reason either. I might have believed they 
would be useful for "large clouds" i.e., non-broadcast multiple-access 
links were a node might not be aware of all the on-link prefixes used on 
the link. But I've verified that even in for such cases these rules 
wouldn't be necessary.

>> We should also note that invalidating the part of on-link definition
>> affects other parts of RFC4861.  For example, it will invalidate this
>> point:
> 
>>    If the Source Address is not the unspecified
>>    address and, on link layers that have addresses, the solicitation
>>    includes a Source Link-Layer Address option, then the recipient
>>    SHOULD create or update the Neighbor Cache entry for the IP Source
>>    Address of the solicitation.
>> (section 7.2.3)
> 
>> we should also clearly state each affected part is invalidated;
>> otherwise, the reader will be confused about the discrepancy.
> 
> Yes. This makes sense.

That change is what I have a problem with.

This thread has already correctly concluded that the next-hop 
determination in the conceptual sending algorithm is unaffected by the 
content of the neighbor cache. Thus a node can update and create 
Neighbor Cache Entries without any impact on the interface and nexthop 
used to send packets. And since the conceptual neighbor cache is per 
interface there is no security issue with accepting such packets.
Thus the change isn't necessary to solve the problem at hand.

Furthermore, if the effect of this change is anywhere near to the code 
change sugegsted in this FreeBSD comment that was quoted earlier, then 
we can create interoperability problems:

>> +        /*
>> +         * According to recent IETF discussions, it is not a good idea
>> +         * to accept a NS from an address which would not be deemed
>> +         * to be a neighbor otherwise.  This point is expected to be
>> +         * clarified in future revisions of the specification.
>> +         */

If node A and node B are on the same link and the router advertisements 
list prefix P1 as on-link, but node B also is statically configured with 
prefix P2 as on-link, then dropping such an NS can lead to A and B 
failing to communicate. Node B might send a NS with source P2::B looking 
for the target P1::A, and the above text says to drop it.
With this part unmodified the conceptual model in RFC 4861 the effect is 
that A creates a NCE for P2::B and responds to the NS with a NA.
Subsequent to that B would send packets directly to A, and A would send 
the packets via a router (since A doesn't have P2 as an on-link prefix.)

Thus I suggest we just change the minimal thing to remove the security 
concern, which is removing bullet three and four from the on-link 
definition in RFC 4861.

     Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------