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

From: Stuart Cheshire <[email-masked]>
Date: Tue, 6 Feb 2007 19:01:00 -0800

Thank you Bernard for your comments. Sorry for the delay responding; the 
last couple of months were very busy for me with work on Apple's upcoming 
iPhone and Apple TV products.

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

You've made a very interesting philosophical observation here (that goes 
beyond the current topic of networking and packets). It's not possible to 
have a truly pure question -- any question can't help also conveying some 
hint of the questioner's motives. Why are you asking the question? The 
act of asking can't avoid the suggestion that you may carry out some 
action based on the answer. I've added the following paragraph at the end 
of Section 1.2 to make this explicit:

   It has been observed that it is probably impossible to ask any truly
   pure question; asking any question necessarily invites speculation
   about why the interrogator wants to know the answer. Just as someone
   pointing to an empty seat and asking, "Is anyone sitting here?"
   implies an unspoken "... because if not then I will," the same is
   true here. An ARP Probe with an all-zero 'sender IP address' may
   ostensibly be merely asking an innocent question ("Is anyone using
   this address?"), but an intelligent implementation that knows how
   IPv4 Address Conflict Detection works should be able to recognize
   this question as the precursor to claiming the address. Consequently,
   if that implementation is also at that exact moment in the process of
   asking the very same question, it should recognize that they can't
   both sit in the same seat, so it would be prudent to ask about some
   other seat.

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

Changed.

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

I think it would be more accurate to say they "will continue to
*try* (unsuccessfully) to utilize their configured addresses..."

I've added the following paragraph at the end of Section 1.3 
"Applicability":

   Where this document uses the term "host" it applies equally to
   interfaces on routers or other multi-homed hosts, regardless of
   whether the host/router is currently forwarding packets. In many
   cases a router will be critical network infrastructure with a locally
   well-known IP address (e.g. handed out by the local DHCP server to
   local clients) so handling conflicts by picking a new IP address is
   not an option. In those cases, option (c) in Section 2.4 "Ongoing
   Address Conflict Detection and Address Defense" below applies.
   However, even when a device is manually configured with a fixed
   address, having some other device on the network claiming to have
   the same IP address will pollute peer ARP caches and prevent reliable
   communication, so it is still helpful to inform the operator. If a
   conflict is detected at the time the operator sets the fixed manual
   address then it is helpful to inform the operator immediately;
   if a conflict is detected subsequently it is helpful to inform the
   operator via some appropriate asynchronous communications channel.
   Even though reliable communication via the conflicted address is not
   possible, it may still be possible to inform the operator via some
   other communication channel that is still operating, such as via some
   other interface on the router, via a dynamic IPv4 link-local address,
   via a working IPv6 address, or even via some completely different
   non-IP technology such as a locally-attached screen or serial
   console.

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

I disagree. Informing the operator of the detected conflict allows the 
problem to be identified and solved quickly. Ignoring the conflict can 
lead to the issue being misdiagnosed and unresolved, causing a lot of 
frustration. If you've ever had two non-ACD devices with the same IP 
address, you'll know that the symptoms of random intermittent pauses and 
TCP connection failures can easily be mistaken for a bad cable or 
defective Ethernet hub.

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

I disagree. The technique of sending a single ARP Announcement and not 
paying attention to any responses is extremely ineffective at coping with 
the case of two devices that think they have the same IP address. The 
only case where it does anything useful is the case where the old device 
has been retired from the network in the last minute or two; it's MAC 
address still remains in peer ARP caches, and when the new device is 
attached to the network, it's single ARP Announcement serves to update 
those stale ARP caches. Updating peer ARP caches is important (which is 
why we have ARP Announcements) but that alone does nothing to detect, 
report, or remedy the problems of inadvertent duplicate address 
conflicts. In short, it's a necessary part of a larger solution, but it 
is not a complete solution in itself.

If you agree with my comments and changes, I'll submit an updated 
draft-05 for publication in a few days.

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Feb 2007 10:10:09 -0800 (PST)

>    non-IP technology such as a locally-attached screen or serial

This looks good. 

> Informing the operator of the detected conflict allows the 

I agree that informing the operator is a good idea. 

> is not a complete solution in itself.

I agree that it's a bad idea not to pay attention to responses.  The 
comment was really only about router address changes, which are covered in 
the other updates. 

> draft-05 for publication in a few days.

The changes look good.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 13 Feb 2007 16:19:29 +0100

Thank you Bernard and Stuart. If these are all the comments, I'll issue 
a last call in the next few days. Please folks, weigh in now if you 
intend to.

- Mark

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 27 Feb 2007 14:47:04 -0500

Stuart,

I was reading draft-cheshire-ipv4-acd-04, and I was wondering about the
question that's actually explicitly covered in Section 5: Why "ARP
Announcement" with ARP Request?

Section 5. lists 2 reasons:
1. Historical precedence: [trying to avoid endless debate] there is also
   precedence for the use of ARP Reply, as well as OS implementation
   that use ARP Reply for gratuitous arp. IIRC, Comer describes Grat ARP
   using ARP Reply opcode; googling for it,
  http://www.listproc.bucknell.edu/archives/netbook/200010/msg00000.html
2. Practicality: This argument lists possible implementation bugs of ARP
   reception, but OTOH the document also says:
	"all that is required is that the peers on the same link
	correctly implement the ARP protocol as given in RFC 826."
   and
	"... so any host that correctly implements the Packet Reception
	algorithm specified in RFC 826 will correctly handle ARP
	Replies delivered via link-layer broadcast."

Given that, as already pointed out in draft-cheshire-ipv4-acd-04, the
source IP address (ar$spa) is processed before the opcode (ar$op), and
the opcode is in fact the last field checked in the ARP "Packet
Reception", then it doesn't really matter if using REQUEST or REPLY.
>From RFC 826, the ARP cache is refreshed before parsing the opcode.

Other specifications mention grat ARPs, and some using reply opcode. For
example, RFC2131 says:
	"The client SHOULD broadcast an ARP reply to announce the
	client's new IP address and clear any outdated ARP cache entries
	in hosts on the client's subnet."
And draft-ietf-mobileip-protocol went:
from -14:
	"A Gratuitous ARP is an ARP Reply that is sent without having
	been prompted by the receipt of any ARP Request.  The ARP Reply
	is..."
to -15:
	"A  Gratuitous ARP [24] is an ARP packet sent by a node in order
	to spontaneously cause other nodes to update an entry in their
	ARP cache.  A gratuitous ARP MAY use either an ARP Request or an
	ARP Reply packet."

On the flip side, as an example, RFC3768 uses a Request opcode:
	"Broadcast a gratuitous ARP request..."

I really do not want to generate a debate on which opcode should be used
for grat arp, but cannot help but wonder: why doesn't
draft-cheshire-ipv4-acd-04 allow for the use of either ar$op, since it
really doesn't matter, and for "ARP Announcement", the processing
happens before even getting to the opcode. I understand the desire to
not leave things unspecified, but IMHO there's precedence (in RFCs and
literature) and reasons for using either opcode for grat arps, and maybe
not taking sides with each one (i.e., allowing both) is a more
comprehensive approach.

One additional small question: Why, for "ARP Probes", ar$tha "SHOULD be
set to all zeroes" and not all ones, when RFC826 says:
	"It does not set ar$tha to anything in particular, because it is
	this value that it is trying to determine.  It could set ar$tha
	to the broadcast address for the hardware (all ones in the case
	of the 10Mbit Ethernet)..."

Also, I agree with the comment (and resolution) for the applicability to
routers, specifically in the value of logging (when some IP addresses
should likely not be changed, even if conflict detected).

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems