[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/