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
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.
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
- 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 . 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 . The final assignment of DHCP option codes is through Standards Action, as defined in RFC 2434 . 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 . 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
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
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
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.
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  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.  Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.  IANA. Private Enterprise Numbers. http://www.iana.org/assignments/enterprise-numbers.html.  Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.  Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.  Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.  Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
 Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.  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.  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.  Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. 26.2. Informative References  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  R. Droms, Ed. DNS Configuration options for DHCPv6. April 2002. Work in Progress.  A. K. Vijayabhaskar. Time Configuration Options for DHCPv6. May 2002. Work in Progress.  Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
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. * * * *
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: email@example.com
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: firstname.lastname@example.org 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: email@example.com Mike Carney Sun Microsystems, Inc 17 Network Circle Menlo Park, CA 94025 USA Phone: +1-650-786-4171 EMail: firstname.lastname@example.org
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.