aggregating router, which sets giaddr and then forwards the message
to a DHCP server. When a DHCP relay that implements the
Authentication suboption receives a message, it MAY use the
procedures in section 9 to verify the source of the message before
forwarding it.
10.2. Sending Messages to Servers
When the relay agent receives a broadcast packet from a client, it
determines which DHCP servers (or other relay agents) should receive
copies of the message. If the relay agent is configured to include
the Authentication suboption, it determines which Algorithm and RDM
to use, and then it performs the steps in section 8.
10.3. Receiving Messages from Servers
When the relay agent receives a message, it determines from its
configuration whether it expects the message to contain a relay agent
information option and an Authentication suboption. The relay agent
MAY be configured to drop response messages that do not contain the
Authentication suboption. The relay agent then follows the
procedures in section 9.
11. DHCP Server Behavior
DHCP servers may interact with multiple relay agents. Server
implementations MAY support a configuration that associates the same
algorithm and key with all relay agents. Servers MAY support a
configuration that specifies the algorithm and key to use with each
relay agent individually.
11.1. Receiving Messages from Relay Agents
When a DHCP server that implements the Authentication suboption
receives a message, it performs the steps in section 9.
11.2. Sending Reply Messages to Relay Agents
When the server has prepared a reply message, it uses the incoming
request message and its configuration to determine whether it should
include a relay agent information option and an Authentication
suboption. If the server is configured to include the Authentication
suboption, it determines which Algorithm and RDM to use and then
performs the steps in section 8.
DISCUSSION:
This server behavior represents a slight variance from RFC 3046
[1], section 2.2. The Authentication suboption is not echoed
back from the server to the relay; the server generates its own
suboption.
12. IANA Considerations
Section 4 defines a new suboption for the DHCP relay agent option
called the Authentication Suboption. IANA has allocated a new
suboption code from the relay agent option suboption number space.
This specification introduces two new number spaces for the
Authentication suboption’s ’Algorithm’ and ’Replay Detection Method’
fields. These number spaces have been created and will be maintained
by IANA.
The Algorithm identifier is a one-byte value. The Algorithm value 0
is reserved. The Algorithm value 1 is assigned to the HMAC-SHA1
keyed hash, as defined in section 7.1. Additional algorithm values
will be allocated and assigned through IETF consensus, as defined in
RFC 2434 [5].
The RDM identifier is a four-bit value. The RDM value 0 is reserved.
The RDM value 1 is assigned to the use of a monotonically increasing
counter value, as defined in section 5. Additional RDM values will
be allocated and assigned through IETF consensus, as defined in RFC
2434 [5].
13. Security Considerations
This specification describes a protocol that adds source
authentication and message integrity protection to the messages
between DHCP relay agents and DHCP servers.
The use of this protocol imposes a new computational burden on relay
agents and servers, because they must perform cryptographic hash
calculations when they send and receive messages. This burden may
add latency to DHCP message exchanges. Because relay agents are
involved when clients reboot, periods of very high reboot activity
will result in the largest number of messages that have to be
processed. During a cable MSO head-end reboot event, for example,
the time required for all clients to be served may increase.
13.1. The Key ID Field
The Authentication suboption contains a four-byte Key ID, following
the example of the DHCP Authentication RFC. Other authentication
protocols, such as DNS TSIG [10], use a key name. A key name is more
flexible and potentially more human readable than a key id. DHCP
servers may well be configured to use key names for DNS updates using
TSIG, so it might simplify DHCP server configuration if some of the
key management for both protocols could be shared.
On the other hand, it is crucial to minimize the size expansion
caused by the introduction of the relay agent information option.
Named keys would require more physical space and would entail more
complex suboption encoding and parsing implementations. These
considerations have led us to specify a fixed-length Key ID instead
of a variable-length key name.
13.2. Protocol Vulnerabilities
Because DHCP is a UDP protocol, messages between relays and servers
may be delivered in an order different from that in which they were
generated. The replay-detection mechanism will cause receivers to
drop packets that are delivered ’late’, leading to client retries.
The retry mechanisms that most clients implement should not cause
this to be an enormous issue, but it will cause senders to do
computational work which will be wasted if their messages are
re-ordered.
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 "Authentication of Relay
Agent Options Using IPsec" [11]. As we note in section 11, the
Authentication suboption can be used without pairwise keys between
each relay and each DHCP server. In deployments where IPsec is
readily available and pairwise keys can be managed efficiently, the
use of IPsec as described in that 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 this
document 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.
14. Acknowledgements
The need for this specification was made clear by comments made by
Thomas Narten and John Schnizlein, and the use of the DHCP
Authentication option format was suggested by Josh Littlefield, at
IETF 53.
15. References
15.1. Normative References
[1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[4] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
15.2. Informative References
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[7] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
[8] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993.
[9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[10] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[11] Droms, R., "Authentication of Relay Agent Options Using IPsec",
Work in Progress, February 2004.
Authors’ Addresses
Mark Stapp
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: 978.936.0000
EMail: mjs@cisco.com
Ted Lemon
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: Ted.Lemon@nominum.com
Full 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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.