Subject: Re: LL32 Multihoming

From: Erik Guttman <[email-masked]>
Date: Fri, 01 Aug 2003 11:42:54 +0200

WG chair hat on

We have rough consensus on this point already.  It would be nice if
the document was as clear as possible.  We should not get derailed
by again considering whether the algorithm can be run without
independence maintained between instances (interfaces) where it is
applied.  This has been ruled out.

WG chair hat off

Philip Nye wrote:
>>From: "Stuart Cheshire" <[email-masked]>
>>
>>I wrote that I thought this text was overly simplistic. What precisely
>>does "independently" mean? If the algorithm is run independently on each
>>interface, does that mean it needs to be aware of the other interfaces,
>>or not?

independent (adj) free from the influence, control or determination of
   another or others [Webster's]

If an algorithm is run independently, then it is not aware of others
running the same algorithm.  Since the algorithm prevents assignment
of the same address to two different interfaces, a host running the
algorithm independently on two interfaces would end up with two
distinct addresses.

> The only difference between two interfaces on the same host and two
> interfaces on different hosts is that in the former case communication MAY
> take place internally rather than taking network bandwidth. The algorithm
> need only be aware of other interfaces insofar as it may make life difficult
> for a host if it has the same LL address on multiple interfaces. 

This is a situation which is useful to avoid, as Erik Nordmark pointed
out.  If a host intentionally attempts to configure the same LL address
on more than one interface, the host will be vulnerable to an attack
whereby a conflict on one attached link will result in a reconfiguration
of multiple interfaces.  An attacker would prevent link-local
configuration not only on the link it is attached to, but also on all
links the host was attached to.  Example.

     good====i1 HOST i2======evil

The host attempts to configure address A on interfaces i1 and i2.  Evil
prevents this by responding it owns A.  The host must cycle through
more and more addresses.  The host cannot communicate with good until
it can find an address that is not claimed by evil, which will never
happen.

We did not have to deal with this situation in our security 
considerations section precisely because we stated that hosts
run the address selection algorithm *independently* on each
interface.

 > In this
> case, it is probably a good idea to avoid picking an address which is
> already selected for another interface.
> 
> If the two interfaces happen to be on the same network then the algorithm
> MUST ensure that they get different addresses.
> 
> How about adding the following two paragraphs at the end of section 3.4.
> 
> "In particular ARP packets which appear to claim an address which is
> assigned to a specific interface, indicate conflict only if they are
> received on that interface and their hardware address is of some other
> interface."
> 
> "If a host has two interfaces on the same network, then claiming and
> defending on those interfaces must ensure that they end up with different
> addresses just as if they were on different hosts."

I am OK with this text, but I believe this goes without saying.

Erik

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 1 Aug 2003 12:33:16 +0100

> From: "Erik Guttman" <[email-masked]>
>
> out.

If the algorithm is truly run independently then there is a possibility that
quite by chance, two interfaces will pick the same IP and unless they are on
the same link, they might both successfully claim it. Whether or not this is
a problem depends on implementation issues (routing, interface
identification etc.) rather than on our spec.

I don't know whether this needs a mention or not.

If the host intentionally links the IP address on two interfaces (the
problem you mention) then the algorithm is certainly not being run
independently.

> I am OK with this text, but I believe this goes without saying.

I also believe this goes without saying. However, Stuart seemed to find
"independent" too vague and I hoped this might clarify. Particularly as
there had been a suggestion on this list that consideration of the hardware
addresses of other interfaces might somehow came into the algorithm - which
I would say contravenes independence.

It is best left out unless others here think there is vagueness or ambiguity
which needs clarifying.

Philip

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Aug 2003 19:43:20 +0700

Date:        Fri, 1 Aug 2003 12:33:16 +0100
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <006601c35820$b38d1030$131010ac@aldebaran>

  | Particularly as
  | there had been a suggestion on this list that consideration of the hardware
  | addresses of other interfaces might somehow came into the algorithm - which
  | I would say contravenes independence.

Whether or not that suggestion is adopted, no, it doesn't.

You're also being confused about an independent execution of the algorithm
for each interface, and the interfaces being independent.   Those do not
mean the same thing.

To make this clear, consider two brothers applying to enter some club
(or college or something).

If the entrance admission algorithm is run independently for each
brother, then each of them stands an equal chance (depending upon
whatever other issues there are) of being admitted.   That does not
in any way prevent the criteria for admission containing "has no
brothers" or "has no twin brother" or "has no brother who is married"
(in the latter case, it is possible that one of the two may be eligible
for entry, and the other not be, but those are still based upon
independent executions of the algorithm).

On the other hand, if the algorithm isn't run independently for each,
then there can be rules like "brothers cannot be admitted together, the
tallest of multiple applicants is to be selected".  To test for things
like that, you have to know that the two are both applying at the same
time, andthe characteristics of each application, one application can't
be evaluated without knowing whether or not the other exists, what it
contains, and what its result is (in that admitting one of the two,
would automatically result in the other being excluded, and which is
which depends upon what is in the applications).   In that case, the
algorithm isn't being run independently on each brother.

Note, that the similar rule "no admission if a brother (or any relative)
is already a member" is OK - that doesn't result in any kind of
cross-dependence in the algorithm, as each application is tested, the
membership list is simply consulted to see who already exists.   That
may result in the 2nd of the two being rejected, but that is still
based upon independent algorithm execution.

In none of these cases are the brothers independent of each other
(necessarily anyway) - you can assume they are highly co-dependent.
That has nothing whatever to do with the independence of the
algorithm used to make a decision about them.

For LL addresses, and their assignment algorithm, all this means that
the algorithm to select an address on an interface works, according to
its rules, on one interface without caring what another instance of
the algorithm happens to be doing on a different interface.   That means
there cannot be rules like "if you get a conflict with the address
being tested, then go back and redo the address assignment on the other
interface" - that wouldn't be independent.  On the other hand, you can
have rules which say things like "look at the mac addresses for all
interfaces in the system", as that affects nothing.   You can also "look
at all LL addresses assigned to the system [and don't duplicate one, or
whatever]" that is also OK for independent execution.

kre