Re: LL32 Multihoming

At 05:44 AM 6/26/2003, Philip Nye wrote:
>Section 2.5 states:
>
>"At any time, if a host receives an ARP packet
>(request *or* reply) where the 'sender IP address' is the host's own IP
>address, but the 'sender hardware address' does not match any of the
>host's own interface addresses, then this is a conflicting ARP packet,
>indicating an address collision."
>
>The use of ANY of the host's own interface addresses, seems to conflict with
>the rule of running the algorithm independently on each interface and of
>avoiding address conflict issues propagating across networks.

The case Stuart raised is one where two interfaces are on the SAME network. 
As I previously stated, this is now the common case on new laptops being 
produced, as they have a wireless interface and Ethernet built in. It's 
common to have that wired interface connected to a LAN with the wireless AP 
on the same LAN, so that a user can unplug and walk around the house or 
office. The result is the two interfaces are on the same network, and the 
laptop could wind up arguing with itself about addressing.

I can see no downside to the host being instructed how to not argue with 
itself. This affects ONLY that host. The extra check for this is 
inexpensive and unobtrusive. If it helps some hosts avoid blowing 
themselves up, what's the downside?

>  Is this
>correct? Is it not sufficient to compare the ARP packet with the HW address
>of the interface using the conflicting IP address?

The other suggestion, regarding hosts insisting on uniqueness of OTHER 
hosts' addresses across all attached networks is likely disruptive.

It may make sense to have hosts detect they are multihomed to the same 
link, and do something useful in that case (as I've said before, this is 
analogous to spanning tree, trying to keep bad things from happening with 
cross-connected networks).


>Philip
>
>----- Original Message -----
>From: "Erik Guttman" <[email protected]>
>To: "Daniel Senie" <[email protected]>
>Cc: "Stuart Cheshire" <[email protected]>; <[email protected]>;
><[email protected]>
>Sent: Wednesday, June 25, 2003 5:00 PM
>Subject: 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
> >
> >
> >