Network Working Group A. Forte
Internet-Draft S. Shin
Expires: December 9, 2006 H. Schulzrinne
Columbia University
June 7, 2006
Passive Duplicate Address Detection for the Dynamic Host Configuration
Protocol for IPv4 (DHCPv4)
draft-forte-dhc-passive-dad-02.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 December 9, 2006.
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 December 9, 2006 [Page 1]
Internet-Draft Passive Duplicate Address Detection June 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 . . . . . . . . . . . . . . . . . . . 9
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 December 9, 2006 [Page 2]
Internet-Draft Passive Duplicate Address Detection June 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 December 9, 2006 [Page 3]
Internet-Draft Passive Duplicate Address Detection June 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 December 9, 2006 [Page 4]
Internet-Draft Passive Duplicate Address Detection June 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 December 9, 2006 [Page 5]
Internet-Draft Passive Duplicate Address Detection June 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 December 9, 2006 [Page 6]
Internet-Draft Passive Duplicate Address Detection June 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 December 9, 2006 [Page 7]
Internet-Draft Passive Duplicate Address Detection June 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). In particular, it describes a stateful and stateless
address configuration mechanism. pDAD can be easily extended to
support IPv6 mainly by changing the size of the addressing space so
that it conforms to the IPv6 addressing space. In IPv6 networks,
however, pDAD would be effective for global addresses only since
link-local addresses need to be already configured in order to form a
DHCP packet.
It must also be noted that pDAD in its present form is not intended
for supporting the stateless configuration mechanism of DHCPv6. This
can be a problem since the use of stateful configuration does not
preclude the use, at the same time, of stateless configuration. So,
it is possible to have mixed scenarios where stateful and stateless
address configurations are both used. In particular, the default
configuration for IPv6 address configuration is set to allow co-
existance of Stateless Address Autoconfiguration (SAA) and DHCPv6
stateful configuration. Therefore, a requirement for pDAD to be used
in IPv6 networks is that the Autonomous configuration flag (A) MUST
be unset to force the use of only stateful address configuration for
global addresses.
Forte, et al. Expires December 9, 2006 [Page 8]
Internet-Draft Passive Duplicate Address Detection June 2006
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 [5], however many problems still need to find a
concrete solution [7]. 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
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 [6] 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 and Greg Daley
for their suggestions and critiques.
13. Change History
In this section we summarize the changes applied to
draft-forte-dhc-passive-dad-00.
"-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.
Forte, et al. Expires December 9, 2006 [Page 9]
Internet-Draft Passive Duplicate Address Detection June 2006
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.
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] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[6] Yegin, A., "Bootstrapping RFC3118 Delayed DHCP Authentication
Using EAP-based Network Access Authentication",
draft-yegin-eap-boot-rfc3118-02 (work in progress), March 2006.
[7] 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 December 9, 2006 [Page 10]
Internet-Draft Passive Duplicate Address Detection June 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 December 9, 2006 [Page 11]
Internet-Draft Passive Duplicate Address Detection June 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 December 9, 2006 [Page 12]