Re: LL32 Multihoming

Daniel Senie wrote:
> At 11:02 AM 6/25/2003, Erik Guttman wrote:
> 
>> Stuart,
>>
>> This issue reawakens concerns raised by Erik Nordmark which we have
>> already dealt with in the 'issue resolution process.'
>>
>> Stuart Cheshire wrote:
>> > 2(b). Therefore: It is helpful to ensure that no local interface has
>> > an IPv4 address that it identical to *any* peer connected via *any*
>> > interface.
>>
>> We had language like this in the document which was removed because
>> it gives rise to a new and significant vulnerability. (See LL14)
>> A host on one link can disrupt hosts on other links (it is not
>> connected to) if IPv4LL has this property.
>>
>> Example: Imagine a multihomed host H1 is connected to links 1 and 2.
>> An attacker is on link 1 and causes H1 to reconfigure by claiming
>> addresses.  This should only effect link 1, not link 2.  The effects
>> could be wider than the links immediately connected to the attacker's
>> multihomed neighbors.  Following the example:  Host H2 is connected to
>> both link 2 and link 3.  As H1 is forced to reconfigure its address on
>> link 2 to be unique, this forces H2 to reconfigure as well, which has
>> consequences on link 3.
>>
>> LL14 was rejected since LL15 was accepted:  the algorithm being
>> completely separate on each interface meant that the vulnerability no
>> longer arises.  Your 2b above conflicts with the accepted LL15 and if
>> ignored gives rise to the concern in LL14 - which can no longer be 
>> ignored (rejected.)
> 
> 
> Umm, this doesn't follow well from the first message in this discussion 
> thread.
> 
> Stuart talked about a concern regarding IP address collision with one's 
> own interfaces. Since a host CAN validate the source MAC address of the 
> packets that come back it's possible to determine if you're arguing iwth 
> yourself. It's still true someone could spoof your MAC address in an ARP 
> packet to cause damage, but as we know that's a place where ARP has 
> issues, and we can't solve them here.
> 
> Erik, you're talking about reconfiguration based on claims (possibly 
> bogus) of use of IP address. Aside from someone spoofing the MAC address 
> as well, it isn't clear your response aligns with the problem Stuart 
> raised.
> 
> I think what Stuart is talking about both has merit, and relates to 
> operational experience, and deserves to be considered as such. Laptops 
> with multiple interfaces are now the norm (for all new products 
> shipping, since the push to put 802.11a/b/g/x/y/z is near universal).


I am fine with adding text to 3.4 to discuss how to avoid auto immune
problems in this case.   I even drafted up a version of his text to
send out.  That is, I fully support Stuart's effort to add clarifying
text for LL32.

But then I looked closer at the preceding text and saw his point 2b.  We
can't suggest that without reopening LL14 and LL15.  That was the 
concern I brought up.

Erik