Subject: [dhcwg] DNA Issue 24: Conflict with ACD Draft

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Jun 2005 17:41:44 -0700 (PDT)

The text of DNA Issue 24 is enclosed below.  The DNA Issues list is
available at:
http://www.drizzle.com/~aboba/DNA/

The crux of this issue concerns whether routers have implemented:
http://www.watersprings.org/pub/id/draft-cheshire-ipv4-acd-03.txt

>From the responses I got to the router survey and initial testing, most
routers do not implement the ACD document.  This is a good thing because
if a router were to implement ACD, it would create a DoS vulnerability.

A more likely case is that a router implements IPv4 Link Local; since
DNAv4 isn't intended for use with IPv4 Link Local addresses, there is no
inherent conflict here, but it makes sense to clarify the spec in this
regard.

Here is the proposed resolution:

Add condition [e] in Section 2.2:

" The host skips the reachability test and proceeds to the IPv4 address
acquisition phase if any of the following conditions are true:
...

[e] If the default gateway address is an IPv4 Link-Local
address. In this case, it is possible that the
reachability test could be misinterpreted as
indication of an address conflict. See [RFC3927]
Section 2.2.1 for details."

Also, change:

"     Note: Some routers may refuse to answer an ARP Probe, in which
      case the reachability test will fail."
To:

" Note: Some routers may refuse to answer an ARP Probe, in which
case the reachability test will fail. A host also may encounter a
router that utilizes ARP Probes for DAD, as described in [ACD].
Such routers will not interpret ARP Probes as an indication of an
address conflict, except where they are themselves doing Duplicate
Address Detection (DAD). To avoid triggering conflict detection
on these routers, a host implementing DNAv4 that receives ARP
Probe from a router SHOULD NOT send ARP Probes to that router as
part of the DNAv4 reachability test."

---------------------------------------------------------------------------
Issue 24: Conflict with ACD Draft
Submitter name: James Carlson
Submitter email address: [email-masked]
Date first submitted: April 28, 2005
Reference:
Document: DNA-11
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

While trying to implement these mechanisms, I think I've found a
conflict between these two documents. I realize that it's pretty late
(you're already in AD review), but could you please look into this?

In the linklocal draft, section 2.2.1 says:

new pseudo-random address and repeat the process. In addition, if
during this period the host receives any ARP probe where the packet's
'target IP address' is the address being probed for, and the packet's
'sender hardware address' is not the hardware address of the
interfaces the host is attempting to configure, then the host MUST
similarly treat this as an address collision and select a new address
as above. This can occur if two (or more) hosts attempt to configure
the same IPv4 Link-Local address at the same time.

This means that if a request (ares_op$REQUEST) packet with ar$spa set
to zero and ar$tpa set to the local address is received (a "probe"),
then we should treat it as a collision and not assign the address.

Unfortunately, the dna draft uses *exactly* these probe packets in its
section 2.2.1 to detect whether the "primary default gateway" is
reachable:

The reachability test is performed by sending an ARP Request. The
ARP Request SHOULD use the host's MAC address as the source, and the
broadcast MAC address as the destination. The host sets the target
protocol address (ar$tpa) to the IPv4 address of the primary default
gateway, and uses its own MAC address in the sender hardware address
field (ar$sha). The host sets the target hardware address field
(ar$tha) to 0.

 If the host has a private address as defined in [RFC1918], then it
SHOULD set the sender protocol address field (ar$spa) to the
unspecified address (0.0.0.0). This is to avoid a potential address
conflict when the host changes its point of attachment from one
private network to another.

The end result of this is that if the router and some arbitrary end
node connect at the same time, the router will see the "reachability
probes" from the end node and *incorrectly* assume that someone else
is claiming his address -- and thus fail to assign the address
properly.

The three possible resolutions I can see are:

- Change the dna draft so that it requires a *regular* ARP
Request message (ar$spa set to the local address), and
requires that the system does any linklayer-draft related
probing before attempting to do reachability.

- Change the linklayer draft to remove that second clause --
so that probes are not seen as conflicts.

- Just live with it, because if routers fail to operate in
practice, that's fine. (Or because I've missed something
really important that prevents the problem, though I don't
see what.)

For what it's worth, I see the first of those three as the most
reasonable. Probing someone else's address with an ar$spa set to zero
doesn't make a lot of sense to me.

-- 
James Carlson, KISS Network <[email-masked]>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

[Bernard Aboba]

Thanks very much for these comments. In DNAv4 the probe is used to
confirm reachability of the default router on the MLPA. The default
router address may be a private address, or it may be a globally routable
address, but it should never be a linklocal address in 169.254/16.
Therefore it should not cause a conflict with IPv4 Link Local
address assignment. If it would help, we could explicitly state that a
probe MUST NOT be sent to a default router with an IPv4 Link Local
address.

[James Carlson]

I think that would likely help a bit, but I'm still concerned that,
due to the expired Cheshire duplicate address detection draft that
eerily mirrors the linklocal draft, there are likely to be
implementations that use the probing procedure for _all_ addresses,
not just those described in linklocal.

In other words, if folks are detecting duplicate addresses using
probes (as I strongly suspect they are), then the dna probe will still
cause problems, even if it's never probing a link-local address.

[Bernard Aboba]

The reason why arp$spa is set to zero when the default gateway has a
private address is that it is possible for a host to have changed networks
without changing prefixes. For example, the host could move from one home
network to another home network, both of which have a gateway address of
192.168.1.1. If arp$spa contained the actual address of the host then
this could pollute the ARP table.

[James Carlson] Yes, I realize that.

I think it's reasonable to observe, though, that just a few cases
exist and none of them lead to needing to set ar$spa to zero:

Private address happens to be in the range of the local
network (i.e., risk of pollution):

Address node has isn't currently in use, and thus use
of the address in ar$spa is harmless, even if the
address is 'from' another network and even if it might
"pollute" the local ARP caches. This can be checked
by doing DAD (probe own address) first.

Address node has is in use by another node on the new
network, in which case the node is on a new network or
just has to start over. Can terminate effort (without
probing default gateway) immediately. This can be
checked by doing DAD first.

Private address is not in the range of the local network
(i.e., no risk of pollution because no valid node is using
that address):

DAD will tell node that address is "ok" to use, as
it's not currently in use, but subsequent real
resolution (nonzero ar$spa) of the default router will
show that either it's at a different hardware address
or just doesn't respond.

In other words, I don't see a case in which a probe as defined in
linklocal needs to be used, provided that duplicate address detection
is available. There's nobody to poison.

[Bernard Aboba]

> In other words, if folks are detecting duplicate addresses using
> probes (as I strongly suspect they are), then the dna probe will still
> cause problems, even if it's never probing a link-local address.

Do you know of an example of this? I wouldn't be surprised if hosts send
probes with ar$spa set to zero to detect duplicates (since this
avoids polluting the ARP cache if there is a duplicate out there).

It's assuming that these probes imply a duplicate that seems a bit
unusual.

> In other words, I don't see a case in which a probe as defined in
> linklocal needs to be used, provided that duplicate address detection
> is available. There's nobody to poison.

Unfortunately, the point of using DNAv4 is to avoid DAD. If DAD were
required it would be faster to just send a DHCPREQUEST to verify the
address and forget DNAv4 altogether. We could specify that behavior when
the host has a private address, if it were necessary to avoid setting
ar$spa to zero.

[James Carlson]

> Do you know of an example of this? I wouldn't be surprised if hosts send
> probes with ar$spa set to zero to detect duplicates (since this
> avoids polluting the ARP cache if there is a duplicate out there).

I'll bet that Stuart Cheshire does; that's why I copied him. The
behavior described above is from Apple.

> It's assuming that these probes imply a duplicate that seems a bit
> unusual.

Except that's exactly what the current zeroconf linklocal draft says.
See section 2.2.1 of that draft, where it says this:

new pseudo-random address and repeat the process. In addition, if
during this period the host receives any ARP probe where the packet's
'target IP address' is the address being probed for, and the packet's
'sender hardware address' is not the hardware address of the
interfaces the host is attempting to configure, then the host MUST
similarly treat this as an address collision and select a new address
as above. This can occur if two (or more) hosts attempt to configure
the same IPv4 Link-Local address at the same time.

This is exactly the probe we're talking about.

[Bernard Aboba]

I just reread the following document:
http://www.watersprings.org/pub/id/draft-cheshire-ipv4-acd-03.txt

It includes the following statement:

This document standardizes the widely-used natural interpretation of
an ARP Request where the Target Protocol Address is non-zero but the
Sender Protocol Address is zero, namely that it is a question without
an associated assertion (an "ARP Probe").

The idea that the probe is a statement without an assertion is backed up
by the text in Section 2.4:

Address conflict detection should not be limited to only the time of
initial interface configuration, when a host is sending ARP probes.
Address conflict detection is an ongoing process that is in effect
for as long as a host is using an address. At any time, if a host
receives an ARP packet (request *or* reply) where the 'sender IP
address' is (one of) the host's own IP address(es), but the 'sender
hardware address' does not match any of the host's own interface
addresses, then this is a conflicting ARP packet, indicating some
other host also thinks it is validly using this address. To resolve
the address conflict, a host must respond to a conflicting ARP packet
as described in either (a), (b) or (c) below:

I read this as implying that a probe with ar$spa set to zero is not
interpreted as a conflict.

[Stuart Cheshire]

>I think that would likely help a bit, but I'm still concerned that,
>due to the expired Cheshire duplicate address detection draft that
>eerily mirrors the linklocal draft, there are likely to be
>implementations that use the probing procedure for _all_ addresses,
>not just those described in linklocal.

James is right. This behavior is common today -- my draft just documents
it.

>I read this as implying that a probe with ar$spa set to zero is not
>interpreted as a conflict.

Except when two hosts are probing simultaneously. Then each treats the
other's probe as a conflict. This is necessary to avoid the simultaneous
probing race condition.

[James Carlson]

> Unfortunately, the point of using DNAv4 is to avoid DAD. If DAD were
> required it would be faster to just send a DHCPREQUEST to verify the
> address and forget DNAv4 altogether. We could specify that behavior when
> the host has a private address, if it were necessary to avoid setting
> ar$spa to zero.

That'd solve the problem completely.

(I think it'd also be conceptually cleaner, as basing the detailed
behavior of ARP on address ranges seems a bit suspect to me.)

Bernard Aboba writes:
> The idea that the probe is a statement without an assertion is backed up
> by the text in Section 2.4:

Yep.

> I read this as implying that a probe with ar$spa set to zero is not
> interpreted as a conflict.

Read on -- that draft and the zeroconf draft both say that when you
get a probe where the target is the address you're trying to verify,
you assume there's a conflict. They allow for two cases: the usual
ar$spa update that causes DAD failure *and* a probe of ar$tpa that
causes failure.

[BA]  I think the discussion has narrowed the scenarios in which a problem
could occur:

1) When the default gateway has a linklocal address.

Since DNA wasn't meant to be used in this case, it can be
explicitly prohibited by adding condition e) to Section 2.2:

"e) If the default gateway address is an IPv4 Link-Local address."

2) When the host and gateway are sending ARP probes simultaneously.

The specific text in ACD-03 is as follows:

"In addition, if during this period the host receives any ARP probe where
the packet's 'target IP address' is the address being probed for, and
the packet's 'sender hardware address' is not the hardware address of
any of the host's interfaces, then the host MUST similarly treat this
as an address conflict and signal an error to the configuring agent
as above. This can occur if two (or more) hosts have, for whatever
reason, been inadvertently configured with the same address, and both
are simultaneously in the process of probing that address to see if
it can safely be used."

However, a router would be unwise to behave this way, because:

a. A router typically has no "configuring agent" (human operator,
DHCP server, etc.), and would become unreachable if it were to
abandon its address, taking network connectivity down with it.

b. A router with a statically configured IP address would be unwise
to stop usage of its address based on receipt of an ARP probe, since that
would make it vulnerable to a denial of service attack. Instead, the
router
should only interpret an ARP reply as a true conflict, and should respond
to an ARP probe if it has verified its own address. This would ensure that
a router would win an address conflict battle, imposing the least cost on
the network as a whole.

Note that for a problem to occur, a default gateway would need
to use ARP probes to verify its address, would need to interpret
receipt of a probe while probing as an actual (not potential) address
conflict, and would need to stop use of its address as a result
of a conflict detected via receipt of a probe.

I will do some tests on common routers (Cisco, Linksys, Apple Airport,
etc.) to see how they behave
and will also send out an implementation survey.

NB: I would also argue that any host with a static address would be unwise
to behave as advocated in ACD-03, since such a host could not easily
obtain
another address to use instead and would therefore become disabled.

[Bernard Aboba] Here's what the initial tests seem to show:

Proteon and related code bases: ARP announcement
Cisco IOS: Broadcast ARP Reply
Linksys: No DAD prior to use of an address (no ARP announcement or Probe)

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg