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

Stuart Cheshire <cheshire@apple.com> Wed, 07 February 2007 03:01 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEd3M-0008WG-4f; Tue, 06 Feb 2007 22:01:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEd3K-0008W8-DH for int-area@ietf.org; Tue, 06 Feb 2007 22:00:58 -0500
Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEd3G-0000bs-Nt for int-area@ietf.org; Tue, 06 Feb 2007 22:00:58 -0500
Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l1730rLZ006558; Tue, 6 Feb 2007 19:00:53 -0800 (PST)
Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 3B07729C003; Tue, 6 Feb 2007 19:00:53 -0800 (PST)
X-AuditID: 11807123-a2227bb000000b0e-6b-45c940e4dbd1
Received: from [17.219.208.166] (unknown [17.219.208.166]) by relay5.apple.com (Apple SCV relay) with SMTP id 7E11D30400D; Tue, 6 Feb 2007 19:00:52 -0800 (PST)
Subject: Re: [Int-area] Review of draft-cheshire-ipv4-acd-04.txt
Date: Tue, 06 Feb 2007 19:01:00 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: Bernard Aboba <aboba@internaut.com>, int-area@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20070207030052.7E11D30400D@relay5.apple.com>
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1
Cc:
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Errors-To: int-area-bounces@lists.ietf.org

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 <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area