Re: LL32 Multihoming

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. Is this
correct? Is it not sufficient to compare the ARP packet with the HW address
of the interface using the conflicting IP address?

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