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
- Re: [Int-area] Review of draft-cheshire-ipv4-acd-… Stuart Cheshire
- Re: [Int-area] Review of draft-cheshire-ipv4-acd-… Bernard Aboba
- Re: [Int-area] Review of draft-cheshire-ipv4-acd-… Mark Townsley
- Re: [Int-area] Review of draft-cheshire-ipv4-acd-… Carlos Pignataro