Re: LL32 Multihoming

At 12:00 PM 6/25/2003, Erik Guttman wrote:
>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.

Good. Thinking about this auto immune thing, the the issue of seeing 
yourself is reminiscent of spanning tree. Same general set of issues.


>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.

Ah. OK. Just reread his text on this and agree this could be problematic, 
and possibly excessive to boot. I'm not convinced a change to require 
uniqueness in this way is a good idea. In fact, it could be an 
exceptionally bad idea... given a segment with 3 machines, each of which is 
multihomed to a second segment. Now assume those other segments are also 
interconnected by other multihomed hosts. The result is very similar to the 
bridging storms that required STP to solve. In other words, hosts would 
claim and defend, insist on uniqueness on all interfaces, and potentially 
set up a vibration that'd not stop as changes were required from one 
segment to the next in a ripple effect. Due to the size of the address 
space, the likelihood of such a storm is low. This could be perturbed by 
faulty random number generators, though, or other coding errors. In 
environments with large numbers of hosts, the problem would be more likely 
to occur, with a potential for self-inflicted denial of service.

Bad idea. Keep the link info separate.