Subject: Re: LL32 Multihoming

From: Stuart Cheshire <[email-masked]>
Date: Tue, 24 Jun 2003 19:28:07 -0700

I wrote:
>The fix is that when receiving an apparently conflicting ARP packet, it 
>should check *all* of its MAC addresses, to make sure the packet didn't 
>come from itself.

Robert Elz wrote
>It is fine to do that...

That's all I was asking for.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Erik Guttman <[email-masked]>
Date: Wed, 25 Jun 2003 17:02:15 +0200

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

Erik

---

From: Daniel Senie <[email-masked]>
Date: Wed, 25 Jun 2003 11:18:14 -0400

At 11:02 AM 6/25/2003, Erik Guttman wrote:
>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).

Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Jun 2003 17:23:26 +0700

Date:        Tue, 24 Jun 2003 19:28:07 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | Robert Elz wrote
  | >It is fine to do that...
  | That's all I was asking for.

Except "it is fine to do that" means "you can do that if you want to"
it doesn't mean "everyone must do that".

I wouldn't object to text that notes that this may be a useful thing to
do sometimes, but I would object to anything that mandated this.  And
object much more to anything that even pretended that "defend all my LL
addresses on all my interfaces" was even a rational approach.

kre

---

From: Erik Guttman <[email-masked]>
Date: Wed, 25 Jun 2003 18:00:45 +0200

Daniel Senie wrote:
> 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.
> 
> 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

---

From: Daniel Senie <[email-masked]>
Date: Wed, 25 Jun 2003 12:27:13 -0400

At 12:00 PM 6/25/2003, Erik Guttman wrote:
>>as well, it isn't clear your response aligns with the problem Stuart raised.
>>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).
>
>

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

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Jun 2003 09:38:32 +0200 (CEST)

> it isn't clear your response aligns with the problem Stuart raised.

Stuart raised multiple points and I'm not sure which one you are concerned
with.

One of them was that it might be helpful for an implementation to checks
its *own* v4ll addresses assigned to its interfaces to avoid assigning
itself the same v4ll address on multiple interfaces. This issue is
local to the implementation and might make a lot of sense for instance
if there are APIs (e.g. IP_MULTICAST_IF) that identify an interface
using an IPv4 address.

Another one was the 2(b) that was quoted, which is to ensure that no remote
v4ll address on any interface conflicts with any v4ll address assigned
to any interface.
This one I think is a bad idea for two reasons:
1. It isn't necessary. A node using v4ll addresses on multiple interfaces
   must have API and application support for always specifying the interface
   to qualify remote v4ll addresses, because even if its local addresses
   don't conflict with any remote address it needs to be able to deal
   with conflicting remote addresses across interfaces.
2. It allows an attacker (or non-malicious brokeness) on one interface to
   disable v4ll on all interfaces on the multihomed node.

   Erik

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 26 Jun 2003 10:44:35 +0100

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-masked]>
To: "Daniel Senie" <[email-masked]>
Cc: "Stuart Cheshire" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, June 25, 2003 5:00 PM
Subject: Re: LL32 Multihoming

---

From: Daniel Senie <[email-masked]>
Date: Thu, 26 Jun 2003 08:53:06 -0400

At 05:44 AM 6/26/2003, Philip Nye wrote:
>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

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