Subject: [Int-area] Review of draft-cheshire-ipv4-acd-04.txt

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2006 10:51:14 -0800 (PST)

I have reviewed draft-cheshire-ipv4-acd-04, and recommend that it
be published as a Proposed Standard RFC, with some potential 
clarifications. 

Some comments:

Section 1 talks about the case where two hosts are simultaneously probing.

      (b) the case where two hosts are inadvertently about to begin
      using the same address, and both are simultaneously in the process
      of probing to determine whether the address may safely be used.
      (Section 2.1.)

In the -03 document, there was material in Section 2.1 that addressed this
case.  However in the -04 document, this material is now in Section 2.1.1:

"  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 interface the host is attempting to configure, 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."

Thus during the probing phase, the Target Protocol Address (ar$tpa) is
treated as an assertion rather than a question.  This is somewhat in
conflict with Section 1.2, which states: 

"  As already specified in RFC 826, an ARP Request packet serves two
   functions, an assertion and a question:

   * Assertion:
     The fields "ar$sha" (Sender Hardware Address) and "ar$spa" (Sender
     Protocol Address) together serve as an assertion of a fact, that
     the stated Protocol Address is mapped to the stated Hardware
     Address.

   * Question:
     The fields "ar$tha" (Target Hardware Address, zero) and "ar$tpa"
     (Target Protocol Address) serve as a question, asking, for the
     stated Protocol Address, to which Hardware Address it is mapped."

My recommendation would be to indicate the probe exception within Section 
1.2. Since the proposed behavior changes the interpretation of ar$tpa within
RFC 826 from a question to an assertion during probing, I would question 
the use of "MUST" in Section 2.1.1 above. SHOULD would probably be better.  

The other general issue is the applicability of this document.  Much of
the text appears to focus on host examples, but there is nothing that
says that it doesn't also apply to routers. 

In my examination of router ARP behavior during the development of DNAv4,
I noticed that many existing routers appear to assume that their IP
address assignments are definitive, either using gratuitous ARP as
described in Section 4, or skipping conflict detection on boot entirely. 
As a result, these routers will continue to utilize their configured
addresses regardless of whether a host has also claimed the same address. 

While this existing behavior increases the likelihood of unresolved
conflicts, my understanding is that there is some security rationale
behind it.  For example, were a router installed in an exchange point
to implement the conflict detection mechanisms described in this
document, then addresses on the interface could be disabled via
use of ARP, causing BGP connections to be reset.  Of course, the 
same effect could also be achieved by reconfiguring peer routers 
to utilize a conflicting address, but the attacks enabled by 
implementation of this document would seem harder to trace/detect. 

As a result, I am wondering whether this document should tone down
the language in Section 4,  perhaps limiting the criticism to hosts, 
or addressing the issue of router applicability explicitly in some
other section. 

4. Historical Note

   A widely-known, but ineffective, duplicate address detection
   technique called "Gratuitous ARP" is found in many deployed systems
   [Ste94].  What Stevens describes as Gratuitous ARP is the exact same
   packet that this document refers to by the more descriptive term "ARP
   Announcement".  This traditional Gratuitous ARP implementation sends
   only a single ARP Announcement when an interface is first configured.
   The result is that the victim (the existing address holder) logs
   an error, and the offender continues operation, often without even
   detecting any problem.  Both machines then typically proceed to try
   to use the same IP address, and fail to operate properly because they
   are each constantly resetting the other's TCP connections.  The human
   administrator is expected to notice the log message on the victim
   machine and repair the damage after the fact.  Typically this has to
   be done by physically going to the machines in question, since in
   this state neither is able to keep a TCP connection open for long
   enough to do anything useful over the network.

   The problems caused by this ineffective duplicate address detection
   technique are illustrated by the fact that (as of August 2004)
   the top Google search results for the phrase "Gratuitous ARP" are
   articles describing how to disable it.

   However, implementers of IPv4 Address Conflict Detection should be
   aware that, as of this writing, Gratuitous ARP is still widely
   deployed.  The steps described in Sections 2.1 and 2.4 of this
   document help make a host robust against misconfiguration and address
   conflicts, even when the other host is *not* playing by the same
   rules.

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