DHC                                                             R. Droms
Internet-Draft                                       Cisco Systems, Inc.
Expires: May 22, 2004 November 22, 2003 27, 2005                                  May 26, 2005

         Authentication of DHCP Relay Agent Options Using IPsec

Status of this Memo

   This document

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is an Internet-Draft aware
   have been or will be disclosed, and is any of which he or she becomes
   aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 6 of RFC2026. 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-

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 22, 2004. November 27, 2005.

Copyright Notice

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


   The DHCP Relay Agent Information Option (RFC 3046) conveys
   information between a DHCP relay agent and a DHCP server.  This
   specification defines a  mechanism for securing the messages
   exchanged between a relay agent and a server using IPsec (RFC 2401).

1. Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [1].

2.  DHCP Terminology

   This document uses the terms "DHCP server" (or "server") and "DHCP
   client" (or "client") as defined in RFC 2131.  The term "DHCP relay
   agent" refers to a "BOOTP relay agent" as defined in RFC 2131.


2.  Introduction

   DHCP (RFC 2131 [5]) provides IP addresses and configuration
   information for DHCP clients.  It includes a relay agent capability
   (RFC 951 [6], RFC 1542 [7]), in which processes within the network
   infrastructure receive broadcast messages from clients and forward
   them to servers as unicast messages.  In network environments like
   DOCSIS data-over-cable and xDSL, for example, it has proven useful
   for the relay agent to add information to the DHCP message before
   forwarding it, using the relay agent information option, RFC 3046
   [1].  The kind of information that a relay agent adds is often used
   in the server's decision making about the addresses and configuration
   parameters that the client should receive.  The way that the relay
   agent data is used in server decision-making tends to make that data
   very important, and highlights the importance of the trust
   relationship between the relay agent and the server.

   The existing DHCP Authentication specification (RFC 3118) [8] only
   secures communication between the DHCP client and server.  Because
   relay agent information is added after the client has signed its
   message, the DHCP Authentication specification explicitly excludes
   relay agent data from that authentication.

   The goals of this specification is to define a method that a relay
   agent can use to:
      1.  protect the integrity of the data that the relay adds
      2.  provide replay protection for that data
      3.  leverage the existing IPsec mechanism


3.  Deployment of Relay Agents in a DHCP Service

   DHCP relay agents forward messages between DHCP clients and DHCP
   servers, so that the DHCP service can be provided without requiring a
   DHCP service on each network segment.  Usually, there is a DHCP relay
   agent on the same network segment as the client, and the relay agent
   forwards messages directly between the client and DHCP server, as
   illustrated in Figure 1.


                  _____                 /      \
      +------+   /     \   +-------+   /        \   +------+
      | DHCP |--|Network|--| Relay |--| internet |--| DHCP |
      |client|  |Segment|  |Agent A|   \        /   |server|
      +------+   \_____/   +-------+    \______/    +------+
   Deployment of a DHCP relay agent to forward messages between a DHCP
   client and a DHCP server

                                 Figure 1

   In some deployments, there may be more than one relay agent between
   the DHCP client and server.  In Figure 2, relay agent A is configured
   to forward DHCP messages to relay agent B. Relay agent B is
   configured to forward DHCP messages to relay agent C, which is, in
   turn, configured to forward DHCP messages to the DHCP server

   In the case where multiple relay agents are deployed between the DHCP
   client and server, the responses from the server to the client are
   sent directly to the relay agent closest to the DHCP client.  In
   Figure 2, the DHCP server will send its responses to the DHCP client
   directly to relay agent A.


                  _____                 /      \
      +------+   /     \   +-------+   /        \
      | DHCP |--|Network|--| Relay |--| internet |
      |client|  |Segment|  |Agent A|   \        /
      +------+   \_____/   +-------+    \______/
                                        | Relay |
                                        |Agent B|
      .                                     |
                                        /      \
                                       /        \
                                      | internet |
                                       \        /
      .                                     |
                                        | Relay |
                                        |Agent C|
                                        /      \
                                       /        \
                                      | internet |
                                       \        /
      .                                     |
                                        | Relay |
                                        |Agent D|
                                        /      \
                                       /        \   +------+
                                      | internet |--| DHCP |
                                       \        /   |server|
                                        \______/    +------+

   Deployment of multiple relay agents between a DHCP client and server

                                 Figure 2


4.  Relay Agent Message Threat Model

   DHCP messages are forwarded by DHCP relay agents between DHCP clients
   and DHCP servers.  The messages exchanged between relay agents and
   servers, in addition to carrying the contents of the messages between
   the clients and server, may carry additional information in relay
   agent information options.  The information in the relay agent
   information options may be used by the relay agent, for example to
   track the physical interface to which a DHCP client is attached, and
   by the server, for example to affect the selection of an IP address
   and other configuration information to be assigned to the client.

   Because the information carried in the relay agent information option
   may affect the behavior of relay agents and servers, operation of a
   DHCP service may be disrupted through malicious attacks on DHCP
   messages carrying relay agent information options.

   The attacks available to a malicious attacker through the relay
   information option include inserting new relay information options,
   modifying the contents of existing relay information options or
   deleting relay information options.  There is no attack available
   through examining the contents of relay information options so there
   is no requirement for privacy of the contents of relay information

   A malicious attacker might mount the following denial of service
   attacks against a DHCP client:
   o  Change the contents of the Agent Circuit ID sub-option or the
      Agent Remote ID sub-option [2], [1], causing the relay agent to be
      unable to return DHCP messages from the server to the client
   o  Change the contents of the DOCSIS Device Class sub-option [9],
      causing the DHCP server to provide incorrect configuration
      parameters to a DOCSIS device
   o  Change the contents of the Link Selection sub-option [10], causing
      the DHCP server to assign an IP address from an incorrect subnet
      to the DHCP client

   In some networks, hosts are assigned to different VLANs that provide
   different types of access to the network depending on the identity of
   the host or the user of that host.  For example, a host might be
   assigned to an internal company VLAN or an isolated VLAN that
   provides only external Internet access depending on the identity of
   the host.  A malicious attacker might mount the following attacks
   designed to gain unauthorized network access:
   o  Change the contents of the Link Selection sub-option to cause the
      DHCP client to be assigned an IP address from an inappropriate
   o  Change the contents of the RADIUS Attributes sub-option [11] to
      cause the DHCP client to be authorized to access inappropriate
      network resources
   o  Replay an earlier DHCP message that contained a valid RADIUS
      Attributes sub-option to cause the DHCP client to be authorized to
      access inappropriate network resources


5.  Use of IPsec to secure DHCP messages

   Relay agents and servers can use IPsec mechanisms [3] [2] to exchange
   messages securely as described in this section.  If there is a single
   relay agent between the DHCP client, there MUST be is an IPsec trust
   relationship established between the relay agent and the DHCP server.
   In Figure 1, relay agent A and the DHCP server must have an IPsec
   session through which DHCP messages are exchanged.

   If a client message is relayed through multiple relay agents, there
   must be
   are independent, pairwise IPsec sessions among the relay agents.  In
   a deployment with multiple relay agents, the relay agents are assumed
   to belong to a single administrative domain or otherwise have the
   ability to establish IPsec sessions.  For example, in Figure 2, there
   must be an IPsec session between pairs of relay agents A and B, B and
   C, and C and D. There must also be be a IPsec session between relay
   agent D and the DHCP server.  In addition, there must be an IPsec
   session between the DHCP server and relay agent A, for messages that
   will be returned from the server directly to relay agent A.

   Relay agents and servers that support secure relay agent to server or
   relay agent to relay agent communication use IPsec under the
   following conditions:
   Selectors:  Relay agents are manually configured with the addresses
               of the relay agent or server to which DHCP messages are
               to be forwarded.  Each relay agent and server that will
               be using IPsec for securing DHCP messages must also be
               configured with a list of the relay agents to which
               messages will be returned.  The selectors for the relay
               agents and servers will be the pairs of addresses
               defining relay agents and servers that exchange DHCP
               messages on the DHCP UDP ports 67 and 68.
   Mode:       Relay agents and servers use transport mode and ESP [4]. [3].
               The information in DHCP messages is not generally
               considered confidential, so encryption need not be used
               (i.e., NULL encryption can be used).
   Key management: Because the relay agents and servers are used within
               an organization, public key schemes are not necessary.
               Because the relay agents and servers must be manually
               configured, manually configured key management may
               suffice, but does not provide defense against replayed
               messages.  Accordingly, if replay protection is required,
               IKE [4] with preshared secrets SHOULD must be supported. used.  IKE with
               public keys MAY may be supported. used.
   Security policy: DHCP messages between relay agents and servers
               should only be accepted from DHCP peers as identified in
               the local configuration.
   Authentication: Shared keys, indexed to the source IP address of the
               received DHCP message, are adequate in this application.
   Availability: Appropriate IPsec implementations are likely to be
               available for servers and for relay agents in more
               featureful devices used in enterprise and core ISP
               networks.  IPsec is less likely to be available for relay
               agents in low end devices primarily used in the home or
               small office markets.


6.  IANA Considerations

   There are no IANA considerations for the authentication mechanisms
   described in this document.


7.  Security Considerations

   The threat model for messages exchanged between DHCP relay agents and
   DHCP servers is described in Section 5. 4.  In Section 6, 5, this
   specification describes a mechanism that can be used to provide
   authentication and message integrity protection to the messages
   between DHCP relay agents and DHCP servers.

   The use of IPsec for securing relay agent options in DHCP messages
   o  the existence of an IPsec implementation available to the relay
      agents and DHCP servers
   o  that the DHCP relay agents and servers be under appropriate
      administrative control so that IPsec sessions can be established
      among the relay agents and servers
   o  manual configuration of the participants, including manual
      distribution of key


   The dhc WG has developed two documents describing authentication of
   DHCP relay agent options to accommodate the requirements of different
   deployment scenarios: this document and "The Authentication Suboption
   for the DHCP Relay Agent Option" [12].  In deployments where IPsec is
   readily available and pairwise keys can be managed efficiently, the
   use of IPsec as described in this document may be appropriate.  If
   IPsec is not available or there are multiple relay agents for which
   multiple keys must be managed, the protocol described in "The
   Authentication Suboption for the DHCP Relay Agent Option" may be
   appropriate.  As is the case whenever two alternatives are available,
   local network administration can choose whichever is more
   appropriate.  Because the relay agents and the DHCP server are all in
   the same administrative domain, the appropriate mechanism can be
   configured on all interoperating DHCP server elements.

8.  Acknowledgments

   The need for this specification was made clear by comments made by
   Thomas Narten and John Schnizlein at IETF 53.

9.  References

9.1  Normative references

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
        January 2001.


   [2]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.


   [3]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
        (ESP)", RFC 2406, November 1998.

   [4]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
        RFC 2409, November 1998.

9.2  Informative References

   [5]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.

   [6]   Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
         September 1985.

   [7]   Wimer, W., "Clarifications and Extensions for the Bootstrap
         Protocol", RFC 1542, October 1993.

   [8]   Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
         RFC 3118, June 2001.

   [9]   Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable Service
         Interface Specifications) Device Class DHCP (Dynamic Host
         Configuration Protocol) Relay Agent Information Sub-option",
         RFC 3256, April 2002.

   [10]  Kinnear, K., Stapp, M., Johnson, R. R., and J. Kumarasamy, "Link
         Selection sub-option for the Relay Agent Information Option for
         DHCPv4", RFC 3527, April 2003.

   [11]  Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option for
         the DHCP Relay Agent Information Option",
         draft-ietf-dhc-agentopt-radius-08 (work in progress), November
         September 2004.

   [12]  Stapp, M. and T. Lemon, "The Authentication Suboption for the
         DHCP Relay Agent Option", draft-ietf-dhc-auth-suboption-05
         (work in progress), August 2004.

Author's Address

   Ralph Droms
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719

   Phone: +1 978.936.1674
   Email: rdroms@cisco.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive

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 at

Disclaimer 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

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

   This document and the information contained herein is are provided on an

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.


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