Network Working Group A. Forte Internet-Draft S. Shin Expires: April 1, 2006 H. Schulzrinne Columbia University September 28, 2005 Passive Duplicate Address Detection for Dynamic Host Configuration Protocol (DHCP) draft-forte-dhc-passive-dad-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In a Layer 3 (L3) handoff procedure, one of the biggest components in terms of delay is introduced by the DHCP address acquisition time required for obtaining a valid IP address for the new subnet. Duplicate Address Detection (DAD) is the most time consuming part of the whole DHCP procedure. In this document we propose a new DAD scheme which has been proven to be effective without introducing any Forte, et al. Expires April 1, 2006 [Page 1] Internet-Draft Passive Duplicate Address Detection September 2005 significant delay. By using such a scheme we can avoid duplicate address and at the same time keep the address acquisition time in the order of a few milliseconds. Using the new procedure will also permit to detect an unauthorized use of a particular IP address even if no duplicate IP has yet occurred. 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 2. Introduction Duplicate Address Detection (DAD) is a key feature in DHCP. DAD is responsible to prevent different clients from acquiring the same IP address and therefore disrupt each other's communication. DAD introduces the largest delay of the whole DHCP procedure. When a L3 handoff occurs, the delay introduced by DAD is responsible for most of the total handoff delay. This last point is particularly significant when we think of mobile nodes (MN) moving in a wireless environment such as IEEE 802.11 networks where handoff delay interferes with active VoIP sessions. In this document, we introduce a novel DAD procedure called Passive DAD (P-DAD) which allows detecting duplicate IP addresses in an efficient manner, without introducing delay. Furthermore, it also allow the DHCP server to find out about illegally used IP addresses that have not caused a duplicate address conflict as yet. This new procedure is transparent to the Mobile Nodes (MN) in the network and permits MNs to perform fast L3 handoffs. 3. Architecture Passive DAD does not require any major modification to the existing DHCP architecture. In particular, we introduce a new agent for each subnet and minimal changes to the DHCP server. The new agent, namely Address Usage Collector (AUC), collects information about the IP addresses in use in its subnet. The only requirement for the new agent is that it MUST be installed in a network element that is traversed by most of the packets from/for that particular subnet, ideally a router. Since the Relay Agent (RA) is commonly installed on a router, the natural choice would be to consider the new agent as part of the RA. This however, is not a requirement. This general architecture is shown in Figure 1. Forte, et al. Expires April 1, 2006 [Page 2] Internet-Draft Passive Duplicate Address Detection September 2005 BROADCAST/ARP ,--------------, AUC PACKET ,-------, TRAFFIC | | <----------------- | AUC | <------------------ | DHCP | '-------' | SERVER | DHCP PACKET ,-----------, | | <----------------| RELAY | DHCP TRAFFIC '--------------' | AGENT | <---------------- '-----------' Figure 1 Passive DAD Architecture 4. Passive DAD (P-DAD) The basic idea behind P-DAD is that we can inform the DHCP server about the IP addresses that are being currently used in a subnet by providing the IP and MAC addresses for each IP address in use. The DHCP server will then check its lease information to be sure that each IP address is being used by the correct client and that client only. If the DHCP server detects an irregular behavior due to the presence of a malicious user, it will perform some actions aimed to fix the situation. We will now describe the P-DAD procedure more in detail. When the AUC boots up, it starts collecting all the IP addresses that are being used in the subnet in which it was installed. In order to collect such information, the AUC monitors all the DHCP and ARP traffic and to improve reliability, it also monitors all the IP and MAC layer broadcast traffic. The AUC will then build a hash table where each entry contains the following information: +------------+-------------+-----------+ | IP address | MAC address | Timestamp | +------------+-------------+-----------+ Figure 2 Entries in the AUC hash table Every time an entry is added to the hash table, a packet with the IP and MAC information is also sent by the AUC agent to the DHCP server. The DHCP server will then compare the {IP, MAC} pair received from the AUC with the one present in its lease file; if the two pairs match then the IP address is being used by the client that previously requested it. If the two pairs do not match, we can have two possible scenarios: 1. A malicious client is using the IP address that was assigned by the DHCP server to a different client which is still using it. This will result in the typical duplicate address situation. Forte, et al. Expires April 1, 2006 [Page 3] Internet-Draft Passive Duplicate Address Detection September 2005 2. A malicious client is using an IP address that was either assigned by the DHCP server to a client that is not using it any longer or that has not been assigned to anyone as yet. In this situation we will not incur a duplicate address, however we will still be able to detect an unauthorized use of an IP address. Furthermore, if the DHCP server is not aware of such unauthorized use, it could assign such an IP address to a new client, thus eventually resulting in a duplicate address assignement. 4.1 Packet Format The format of the packets exchanged between the AUC agent and the DHCP server is shown in Figure 3: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subnet Identifier (4) | +-------------------------------------------------------------+ | MAC Address (6) | +-------------------------------------------------------------+ | IP Address (4) | +-------------------------------------------------------------+ Figure 3 Format of packets exchanged between the AUC agent and the DHCP server The Subnet Identifier (SI) MUST be the IP address of the RA in the case in which the AUC agent is installed on the Relay Agent. The pair {MAC address, IP address} indicates that the AUC detected the IP address "IP" in use by a client with MAC address "MAC". 4.2 Timestamp Field As shown in Figure 2, the third element of an entry of the hash table built by the AUC is the timestamp. The timestamp represents the time of the day at which a particular IP address has been detected as in use. After a configurable amount of time each entry in the hash table will expire and the hash table will have to be repopulated. In doing so, the AUC agent will send again data to the DHCP server. The DHCP server will then check the data received by following the procedure described earlier. This "forced expiration" of the hash table entries is done in order for the DHCP server to periodically check the IP addresses that are being used. If the AUC receives packets for entries already present in the hash table and whose timer has not yet expired, no information will be sent to the DHCP server Forte, et al. Expires April 1, 2006 [Page 4] Internet-Draft Passive Duplicate Address Detection September 2005 regarding such packets. The timer value is calculated as follows: Timer = Timestamp + delta delta: configurable amount of time The timer for each entry SHOULD be set to a value so to prevent the expiration of all the entries at the same time. This would permit to avoid an undesired behavior where a large amount of packets is sent at once from the AUC to the DHCP server every time all the entries in the hash table expire. This can be achieved by adding a random quantity to the delta value in the timer. 4.3 DHCP Server Behavior As we said earlier, every time the AUC adds or refreshes an entry in the hash table, a packet is sent to the DHCP server. These, however, are not the only cases in which the AUC informs the DHCP server about a particular IP address in use. The AUC will send information about a particular IP address to the DHCP server also when it detects that two different MAC addresses are using the same IP address. This could result in a duplicate address. Having the same MAC address associated to more than one IP address MUST NOT trigger the AUC to send data to the DHCP server as such a scenario can be related to the legitimate use of different IP addresses (aliases) on the same interface. When the DHCP server discovers an unauthorized IP address, it places such an address in a "bad" IP list so that it will not be assigned to any client. The amount of time that such an address will spend in the "bad" list is directly related to the hash table timeout of the AUC agent. In particular it is RECOMMENDED to use a timeout value for the IP addresses in the "bad" list that is bigger than the hash table timeout in the AUC agent. By adding this expiration of the entries in the "bad" IP list and the expiration of the entries in the hash table of the AUC, we assure that the "bad" IP list is periodically refreshed. When the DHCP server detects a duplicate address, it MUST put such an address in the "bad" IP list so to avoid future assignments. Furthermore, the DHCP server can try to resolve the duplicate address situation by either waiting for the legitimate client to renew its lease and forcing a transition to the DISCOVER state or by immediately forcing the legitimate user to change its IP address as described in [2]. In either case, the change in IP address would result in a broken TCP connection for the legitimate user. It is important to notice that no action can be taken on the malicious user Forte, et al. Expires April 1, 2006 [Page 5] Internet-Draft Passive Duplicate Address Detection September 2005 at the IP layer, since such a user will not be using the DHCP infrastructure. 5. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001. Authors' Addresses Andrea G. Forte Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: andreaf@cs.columbia.edu Sangho Shin Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: sangho@cs.columbia.edu Henning G. Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: hgs@cs.columbia.edu Forte, et al. Expires April 1, 2006 [Page 6] Internet-Draft Passive Duplicate Address Detection September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Forte, et al. Expires April 1, 2006 [Page 7]