Network Working Group A. Forte Internet-Draft S. Shin Expires: April 14, 2007 H. Schulzrinne Columbia University October 11, 2006 Passive Duplicate Address Detection for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) draft-forte-dhc-passive-dad-03.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 14, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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 14, 2007 [Page 1] Internet-Draft Passive Duplicate Address Detection October 2006 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. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Passive DAD (pDAD) . . . . . . . . . . . . . . . . . . . . . . 4 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Timestamp Field . . . . . . . . . . . . . . . . . . . . . . . 6 7. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 7 8. Other types of devices . . . . . . . . . . . . . . . . . . . . 8 9. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 13. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Forte, et al. Expires April 14, 2007 [Page 2] Internet-Draft Passive Duplicate Address Detection October 2006 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. It prevents different clients from acquiring the same IP address and disrupting each others' 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 (pDAD) which allows detecting duplicate IP addresses in an efficient manner, without introducing delay. Furthermore, it also allows 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 MNs 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 14, 2007 [Page 3] Internet-Draft Passive Duplicate Address Detection October 2006 BROADCAST/ARP/DHCP ,--------------, AUC PACKET ,-------, TRAFFIC | | <----------------- | AUC | <------------------ | DHCP | '-------' | SERVER | DHCP PACKET ,-----------, | | <----------------| RELAY | DHCP TRAFFIC '--------------' | AGENT | <---------------- '-----------' Figure 1 Passive DAD Architecture 4. Passive DAD (pDAD) The basic idea behind pDAD is that we can inform the DHCP server about the IP addresses that are currently being used in a subnet by providing IP address and Client Identifier [3] 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 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 pDAD procedure in more detail. At startup the AUC starts collecting all the IP addresses that are being used in the subnet in which it was installed. In particular, 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 uses the collected information to build two different hash tables. One table is built using information collected by monitoring all non-DHCP traffic. For this table, each entry contains the following information: +------------+-------------+-----------+ | IP address | MAC address | Timestamp | +------------+-------------+-----------+ Figure 2 Entries in the first AUC table The second table is built using the information collected by monitoring DHCP traffic only. In particular, it COULD be built by only monitoring DHCP_REQUEST packets. Each entry in this second table contains the following information: Forte, et al. Expires April 14, 2007 [Page 4] Internet-Draft Passive Duplicate Address Detection October 2006 +------+-------------+ | DUID | MAC address | +------+-------------+ Figure 3 Entries in the second AUC table The two tables are independent. The first one tells the AUC which IPs are being used for which MAC, while the second one shows the correspondence between MAC and client ID. In particular, we consider the DHCP Unique Identifier (DUID) as defined in [4]. In the following we refer to the first table as ipTable and to the second table as idTable. When a new IP address is detected by the AUC, the pair {IP, MAC} is added to the ipTable. The AUC also checks the idTable for the corresponding {DUID, MAC} entry. If it finds the particular DUID for that MAC address it means that the IP address had been requested via DHCP, but the AUC does not know if the DHCP server has granted that IP address or not. This is particularly true if the idTable has been built using DHCP_REQUEST packets only. Regardless, once the AUC knows the particular DUID for that MAC address, it sends a packet to the DHCP server containing information on the IP address found to be in use. If the AUC cannot find a valid entry in the idTable for the specified IP address, it means that no DHCP traffic was detected for that IP address. The AUC then assumes that either a client has statically assigned such an IP address or that such IP address has been used without proper authorization from the DHCP server. It sends a packet to the DHCP server containing the IP and MAC information to inform the server that the IP address is currently in use. When the DHCP server receives a packet from the AUC containing DUID information, the server checks its lease file to be sure that the received association {DUID, IP} is legitimate. If it is, no further action is taken. If it is not legitimate, 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. 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 assignment. Forte, et al. Expires April 14, 2007 [Page 5] Internet-Draft Passive Duplicate Address Detection October 2006 When the DHCP server receives a packet from the AUC that does not contain any DUID information but it only contains MAC and IP information, it checks if such IP has been configured as static. If it has, no further action is taken by the server. If it has not been configured as static, the server marks such an IP address as in use. 5. Packet Format The format of the packets exchanged between the AUC and the DHCP server is shown in Figure 4: 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) | +-------------------------------------------------------------+ | IP Address (4) | +-------------------------------------------------------------+ | | | Client Identifier (6) +---------------+-------------+ | | Flag (1) | Padding (1) | +-------------------------------------------------------------+ Figure 4 Format of packets exchanged between the AUC and the DHCP server The Subnet Identifier is used by the DHCP server to identify the subnet that the AUC is monitoring. If the AUC is installed on the Relay Agent, the Subnet Identifier MUST be the IP address of the RA. The Client Identifier field contains either the DHCP Unique Identifier (DUID) as defined in [4] or the MAC address of a client. The pair {Client Identifier, IP address} indicates that the AUC has detected the IP address "IP" in use by a client with that Client identifier. The most significative bit of the Flag field indicates whether or not he Client-ID option is being used. If it is not being used, the client is identified by its MAC address which is why the Client Identifier field is 6 bytes long. 6. Timestamp Field As shown in Figure 2, the third element of an entry of the ipTable built by the AUC is the timestamp. The timestamp represents the time of day at which a particular IP address was detected in use. After a configurable amount of time each entry in the ipTable expires and the table is repopulated. In doing so, the AUC again sends data to the DHCP server. The DHCP server then checks the data received by Forte, et al. Expires April 14, 2007 [Page 6] Internet-Draft Passive Duplicate Address Detection October 2006 following the procedure described earlier. This "forced expiration" of the ipTable 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 an entry already present in the ipTable whose timer has not yet expired, it does not send any information to the DHCP server. The timer value is calculated as follows: Timer = Timestamp + delta delta: configurable amount of time The timers for the entries SHOULD be set to values that prevent the expiration of all the entries in the ipTable at the same time. This avoids a large amount of packets being sent at once by the AUC to the DHCP server every time all the entries in the ipTable expire. A random quantity may be added to the delta value in the timer. Generally, a timestamp field needs not be present in the idTable as these entries do not change over time. In particular, a pair {DUID, MAC} is valid for as long as no hardware changes occur. In order to take into consideration such non common cases, a timestamp field with a long expiration time MAY be added to each entry in the idTable. 7. DHCP Server Behavior As we said earlier, every time the AUC adds or refreshes an entry in the ipTable, 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 the same IP address for two different DUIDs. This could result in a duplicate address. Having the same DUID 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 and/or to the use of different IP addresses on different interfaces of the same client. 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 spends in the "bad" list is directly related to the AUC's ipTable timeout. In particular, it is RECOMMENDED to use a timeout value for the IP addresses in the "bad" list that is bigger than the ipTable timeout in the AUC. By adding this expiration of the entries in the "bad" IP list and the expiration of the entries in the ipTable, we assure that the "bad" IP list is periodically refreshed. Forte, et al. Expires April 14, 2007 [Page 7] Internet-Draft Passive Duplicate Address Detection October 2006 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 note that no action can be taken on the malicious user at the IP layer, since such a user will not be using the DHCP infrastructure. 8. Other types of devices Network devices are becoming more and more heterogeneous. Many network devices are USB and FireWire devices which are not 802-like. From a network perspective this means that these kind of devices do not have a MAC address as 802-like devices do. Instead, they have some kind of unique identifier that can be used in place of the MAC address. pDAD can support these devices without any significant change since their unique identifier can be used in place of their MAC address. 9. IPv6 RFC 3315 [4] describes the DHCP infrastructure in conjunction with IPv6 (DHCPv6) and a stateful configuration mechanism for IPv6 addresses. The uniqueness of an IPv6 address configured via RFC 3315 is tested by the common Duplicate Address Detection procedure described in RFC 2462 [5], and a separate mechanism called optimistic DAD [6] is defined to avoid the delay in the DAD process. This document thus excludes DAD for IPv6 from its scope. 10. Security Considerations Security in the DHCP infrastructure is a very critical problem. Some work has been done in the past to try to secure the DHCP infrastructure [7], however many problems still need to find a concrete solution [9]. In this section we propose a few enhancements to the architecture previously described in order to improve security at the AUC level. All other security concerns about the DHCP infrastructure are out of the scope of this draft and will not be addressed here. In general, we RECOMMEND using a TCP session between hosts that are Forte, et al. Expires April 14, 2007 [Page 8] Internet-Draft Passive Duplicate Address Detection October 2006 generators and consumers of DAD information. In this particular context, a TCP session should be established between the AUC and the DHCP server. Different kinds of authentication such as EAP-based authentication [8] secure connections such as TLS MAY also be used. This can help in preventing bogus AUCs from sending invalid data to the DHCP server and perhaps performing a DoS attack. 11. IANA Considerations This document has no actions for IANA. 12. Acknowledgments The authors would like to acknowledge many of the people in the DHCP working group that have contributed to the discussion of the present draft. We would also like to thank Richard Barr Hibbs, Greg Daley and Jinmei Tatuya for their suggestions and critiques. 13. Change History In this section we summarize the changes applied to draft-forte-dhc-passive-dad-00. "-03" Draft o The IPv6 section has been modified as proposed by Jinmei Tatuya on the dhc mailing list. "-02" Draft o Added more details and limitations to the use of pDAD in IPv6 networks. "-01" Draft Significant changes were made to the draft in revision -01. o Added support for client identifiers as defined in [3]. This required the AUC to build a second table by monitoring DHCP traffic. The AUC behavior towards the DHCP server has also been modified in order to reflect such changes. o Some security considerations have been added. In particular, TCP sessions should be established between AUC and DHCP server. Forte, et al. Expires April 14, 2007 [Page 9] Internet-Draft Passive Duplicate Address Detection October 2006 o Added general considerations on IPv6 support. o Added acknowledgments and new references. 14. 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. [3] Sommerfeld, B. and T. Lemon, "Node-Specific Client Identifiers for DHCPv4", draft-ietf-dhc-3315id-for-v4-05 (work in progress), June 2005. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [6] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006. [7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [8] Yegin, A., "Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication", draft-yegin-eap-boot-rfc3118-02 (work in progress), March 2006. [9] Hibbs, R., Smith, C., Volz, B., and M. Zohar, "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis, IETF Internet Draft (Work in Progress)", February 2006. Forte, et al. Expires April 14, 2007 [Page 10] Internet-Draft Passive Duplicate Address Detection October 2006 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 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 14, 2007 [Page 11] Internet-Draft Passive Duplicate Address Detection October 2006 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 (2006). 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 14, 2007 [Page 12]