Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3315

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Pages: 101
Obsoleted by:  8415
Updated by:  436154946221642266447083722772837550
Part 5 of 5 – Pages 89 to 101
First   Prev   None

ToP   noToC   RFC3315 - Page 89   prevText

23. Security Considerations

The threat to DHCP is inherently an insider threat (assuming a properly configured network where DHCPv6 ports are blocked on the perimeter gateways of the enterprise). Regardless of the gateway configuration, however, the potential attacks by insiders and outsiders are the same. Use of manually configured preshared keys for IPsec between relay agents and servers does not defend against replayed DHCP messages. Replayed messages can represent a DOS attack through exhaustion of processing resources, but not through mis-configuration or exhaustion of other resources such as assignable addresses. One attack specific to a DHCP client is the establishment of a malicious server with the intent of providing incorrect configuration information to the client. The motivation for doing so may be to
ToP   noToC   RFC3315 - Page 90
   mount a "man in the middle" attack that causes the client to
   communicate with a malicious server instead of a valid server for
   some service such as DNS or NTP.  The malicious server may also mount
   a denial of service attack through misconfiguration of the client
   that causes all network communication from the client to fail.

   There is another threat to DHCP clients from mistakenly or
   accidentally configured DHCP servers that answer DHCP client requests
   with unintentionally incorrect configuration parameters.

   A DHCP client may also be subject to attack through the receipt of a
   Reconfigure message from a malicious server that causes the client to
   obtain incorrect configuration information from that server.  Note
   that although a client sends its response (Renew or
   Information-request message) through a relay agent and, therefore,
   that response will only be received by servers to which DHCP messages
   are relayed, a malicious server could send a Reconfigure message to a
   client, followed (after an appropriate delay) by a Reply message that
   would be accepted by the client.  Thus, a malicious server that is
   not on the network path between the client and the server may still
   be able to mount a Reconfigure attack on a client.  The use of
   transaction IDs that are cryptographically sound and cannot easily be
   predicted will also reduce the probability that such an attack will
   be successful.

   The threat specific to a DHCP server is an invalid client
   masquerading as a valid client.  The motivation for this may be for
   theft of service, or to circumvent auditing for any number of
   nefarious purposes.

   The threat common to both the client and the server is the resource
   "denial of service" (DoS) attack.  These attacks typically involve
   the exhaustion of available addresses, or the exhaustion of CPU or
   network bandwidth, and are present anytime there is a shared
   resource.

   In the case where relay agents add additional options to Relay
   Forward messages, the messages exchanged between relay agents and
   servers may be used to mount a "man in the middle" or denial of
   service attack.

   This threat model does not consider the privacy of the contents of
   DHCP messages to be important.  DHCP is not used to exchange
   authentication or configuration information that must be kept secret
   from other networks nodes.
ToP   noToC   RFC3315 - Page 91
   DHCP authentication provides for authentication of the identity of
   DHCP clients and servers, and for the integrity of messages delivered
   between DHCP clients and servers.  DHCP authentication does not
   provide any privacy for the contents of DHCP messages.

   The Delayed Authentication protocol described in section 21.4 uses a
   secret key that is shared between a client and a server.  The use of
   a "DHCP realm" in the shared key allows identification of
   administrative domains so that a client can select the appropriate
   key or keys when roaming between administrative domains.  However,
   the Delayed Authentication protocol does not define any mechanism for
   sharing of keys, so a client may require separate keys for each
   administrative domain it encounters.  The use of shared keys may not
   scale well and does not provide for repudiation of compromised keys.
   This protocol is focused on solving the intradomain problem where the
   out-of-band exchange of a shared key is feasible.

   Because of the opportunity for attack through the Reconfigure
   message, a DHCP client MUST discard any Reconfigure message that does
   not include authentication or that does not pass the validation
   process for the authentication protocol.

   The Reconfigure Key protocol described in section 21.5 provides
   protection against the use of a Reconfigure message by a malicious
   DHCP server to mount a denial of service or man-in-the-middle attack
   on a client.  This protocol can be compromised by an attacker that
   can intercept the initial message in which the DHCP server sends the
   key to the client.

   Communication between a server and a relay agent, and communication
   between relay agents, can be secured through the use of IPSec, as
   described in section 21.1.  The use of manual configuration and
   installation of static keys are acceptable in this instance because
   relay agents and the server will belong to the same administrative
   domain and the relay agents will require other specific configuration
   (for example, configuration of the DHCP server address) as well as
   the IPSec configuration.

24. IANA Considerations

This document defines several new name spaces associated with DHCPv6 and DHCPv6 options: - Message types - Status codes - DUID
ToP   noToC   RFC3315 - Page 92
      -  Option codes

   IANA has established a registry of values for each of these name
   spaces, which are described in the remainder of this section.  These
   name spaces will be managed by the IANA and all will be managed
   separately from the name spaces defined for DHCPv4.

   New multicast addresses, message types, status codes, and DUID types
   are assigned via Standards Action [11].

   New DHCP option codes are tentatively assigned after the
   specification for the associated option, published as an Internet
   Draft, has received expert review by a designated expert [11].  The
   final assignment of DHCP option codes is through Standards Action, as
   defined in RFC 2434 [11].

   This document also references three name spaces in section 21 that
   are associated with the Authentication Option (section 22.11).  These
   name spaces are defined by the authentication mechanism for DHCPv4 in
   RFC 3118 [4].

   The authentication name spaces currently registered by IANA will
   apply to both DHCPv6 and DHCPv4.  In the future, specifications that
   define new Protocol, Algorithm and RDM mechanisms will explicitly
   define whether the new mechanisms are used with DHCPv4, DHCPv6 or
   both.

24.1. Multicast Addresses

Section 5.1 defines the following multicast addresses, which have been assigned by IANA for use by DHCPv6: All_DHCP_Relay_Agents_and_Servers address: FF02::1:2 All_DHCP_Servers address: FF05::1:3
ToP   noToC   RFC3315 - Page 93

24.2. DHCP Message Types

IANA has recorded the following message types (defined in section 5.3). IANA will maintain the registry of DHCP message types. SOLICIT 1 ADVERTISE 2 REQUEST 3 CONFIRM 4 RENEW 5 REBIND 6 REPLY 7 RELEASE 8 DECLINE 9 RECONFIGURE 10 INFORMATION-REQUEST 11 RELAY-FORW 12 RELAY-REPL 13
ToP   noToC   RFC3315 - Page 94

24.3. DHCP Options

IANA has recorded the following option-codes (as defined in section 22). IANA will maintain the registry of DHCP option codes. OPTION_CLIENTID 1 OPTION_SERVERID 2 OPTION_IA_NA 3 OPTION_IA_TA 4 OPTION_IAADDR 5 OPTION_ORO 6 OPTION_PREFERENCE 7 OPTION_ELAPSED_TIME 8 OPTION_RELAY_MSG 9 OPTION_AUTH 11 OPTION_UNICAST 12 OPTION_STATUS_CODE 13 OPTION_RAPID_COMMIT 14 OPTION_USER_CLASS 15 OPTION_VENDOR_CLASS 16 OPTION_VENDOR_OPTS 17 OPTION_INTERFACE_ID 18 OPTION_RECONF_MSG 19 OPTION_RECONF_ACCEPT 20
ToP   noToC   RFC3315 - Page 95

24.4. Status Codes

IANA has recorded the status codes defined in the following table. IANA will manage the definition of additional status codes in the future. Name Code Description ---------- ---- ----------- Success 0 Success. UnspecFail 1 Failure, reason unspecified; this status code is sent by either a client or a server to indicate a failure not explicitly specified in this document. NoAddrsAvail 2 Server has no addresses available to assign to the IA(s). NoBinding 3 Client record (binding) unavailable. NotOnLink 4 The prefix for the address is not appropriate for the link to which the client is attached. UseMulticast 5 Sent by a server to a client to force the client to send messages to the server. using the All_DHCP_Relay_Agents_and_Servers address.

24.5. DUID

IANA has recorded the following DUID types (as defined in section 9.1). IANA will manage the definition of additional DUID types in the future. DUID-LLT 1 DUID-EN 2 DUID-LL 3

25. Acknowledgments

Thanks to the DHC Working Group and the members of the IETF for their time and input into the specification. In particular, thanks also for the consistent input, ideas, and review by (in alphabetical order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, Richard Hussong, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue Thomson, Tatuya Jinmei and Phil Wells.
ToP   noToC   RFC3315 - Page 96
   Thanks to Steve Deering and Bob Hinden, who have consistently taken
   the time to discuss the more complex parts of the IPv6
   specifications.

   And, thanks to Steve Deering for pointing out at IETF 51 in London
   that the DHCPv6 specification has the highest revision number of any
   Internet Draft.

26. References

26.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [4] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001. [5] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [6] IANA. Private Enterprise Numbers. http://www.iana.org/assignments/enterprise-numbers.html. [7] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [8] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [9] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [10] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987. [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
ToP   noToC   RFC3315 - Page 97
   [13] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.

   [14] Plummer, D.C., "Ethernet Address Resolution Protocol:  Or
        converting network protocol addresses to 48.bit Ethernet address
        for transmission on Ethernet hardware", STD 37, RFC 826,
        November 1982.

   [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
        1980.

   [16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
        1992.

   [17] Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

26.2. Informative References

[18] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [19] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [20] R. Droms, Ed. DNS Configuration options for DHCPv6. April 2002. Work in Progress. [21] A. K. Vijayabhaskar. Time Configuration Options for DHCPv6. May 2002. Work in Progress. [22] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
ToP   noToC   RFC3315 - Page 98

A. Appearance of Options in Message Types

The following table indicates with a "*" the options are allowed in each DHCP message type: Client Server IA_NA Option Pref Time Relay Auth. Server ID ID IA_TA Request Msg. Unica. Solicit * * * * * Advert. * * * * * Request * * * * * * Confirm * * * * * Renew * * * * * * Rebind * * * * * Decline * * * * * * Release * * * * * * Reply * * * * * * Reconf. * * * * Inform. * (see note) * * * R-forw. * * R-repl. * * NOTE: Only included in Information-Request messages that are sent in response to a Reconfigure (see section 19.4.3). Status Rap. User Vendor Vendor Inter. Recon. Recon. Code Comm. Class Class Spec. ID Msg. Accept Solicit * * * * * Advert. * * * * * Request * * * * Confirm * * * Renew * * * * Rebind * * * * Decline * * * Release * * * Reply * * * * * * Reconf. * Inform. * * * * R-forw. * * * * R-repl. * * * *
ToP   noToC   RFC3315 - Page 99

B. Appearance of Options in the Options Field of DHCP Options

The following table indicates with a "*" where options can appear in the options field of other options: Option IA_NA/ IAADDR Relay Relay Field IA_TA Forw. Reply Client ID * Server ID * IA_NA/IA_TA * IAADDR * ORO * Preference * Elapsed Time * Relay Message * * Authentic. * Server Uni. * Status Code * * * Rapid Comm. * User Class * Vendor Class * Vendor Info. * Interf. ID * * Reconf. MSG. * Reconf. Accept * Note: "Relay Forw" / "Relay Reply" options appear in the options field of the message but may only appear in these messages.

Chair's Address

The working group can be contacted via the current chair: Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 Phone: (978) 936-1674 EMail: rdroms@cisco.com
ToP   noToC   RFC3315 - Page 100

Authors' Addresses

Jim Bound Hewlett Packard Corporation ZK3-3/W20 110 Spit Brook Road Nashua, NH 03062-2698 USA Phone: +1 603 884 0062 EMail: Jim.Bound@hp.com Bernie Volz 116 Hawkins Pond Road Center Harbor, NH 03226-3103 USA Phone: +1-508-259-3734 EMail: volz@metrocast.net Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 USA EMail: Ted.Lemon@nominum.com Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charles.perkins@nokia.com Mike Carney Sun Microsystems, Inc 17 Network Circle Menlo Park, CA 94025 USA Phone: +1-650-786-4171 EMail: michael.carney@sun.com
ToP   noToC   RFC3315 - Page 101
Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.