One document matched: draft-forte-dhc-passive-dad-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 08:58:30 |