draft-ietf-dhc-dhcpv6-relay-supplied-options-01.txt   draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt 
dhc T. Lemon dhc T. Lemon
Internet-Draft Nominum Internet-Draft Nominum
Intended status: Standards Track Q. Wu Intended status: Standards Track Q. Wu
Expires: March 22, 2011 Huawei Expires: April 2, 2011 Huawei
September 18, 2010 September 29, 2010
Relay-Supplied DHCP Options Relay-Supplied DHCP Options
draft-ietf-dhc-dhcpv6-relay-supplied-options-01 draft-ietf-dhc-dhcpv6-relay-supplied-options-02
Abstract Abstract
This document describes a general mechanism whereby a DHCPv6 relay This document describes a general mechanism whereby a DHCPv6 relay
agent can provide options to a DHCPv6 server that the DHCPv6 server agent can provide options to a DHCPv6 server that the DHCPv6 server
can then provide to the DHCPv6 client. can then provide to the DHCPv6 client.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 22, 2011. This Internet-Draft will expire on April 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 4 4. RSOO-enabled options . . . . . . . . . . . . . . . . . . . . . 4
5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 5. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The DHCPv6 specification [RFC3315] allows DHCP relay agents to The DHCPv6 specification [RFC3315] allows DHCP relay agents to
forward DHCPv6 messages between clients and servers that are not on forward DHCPv6 messages between clients and servers that are not on
the same IPv6 link. In some cases the DHCP relay agent has the same IPv6 link. In some cases the DHCP relay agent has
information the DHCP server does not have that would be useful to information the DHCP server does not have that would be useful to
provide to a DHCP client. For example, the DHCP client may need to provide to a DHCP client. For example, the DHCP client may need to
learn the EAP local domain name [I.D-ietf-hokey-ldn-discovery] for learn the EAP local domain name [I.D-ietf-hokey-ldn-discovery] for
skipping to change at page 4, line 5 skipping to change at page 4, line 5
The DHCP server can then choose to place those options in the The DHCP server can then choose to place those options in the
response it sends to the client. response it sends to the client.
3. Encoding 3. Encoding
In order to supply options for the DHCP server, the relay agent sends In order to supply options for the DHCP server, the relay agent sends
a Relay-Supplied Options option in the Relay-Forward message. This a Relay-Supplied Options option in the Relay-Forward message. This
option encapsulates whatever options the relay agent wishes to option encapsulates whatever options the relay agent wishes to
provide to the DHCPv6 server. provide to the DHCPv6 server.
+----+----+----+----+--------------+ 0 1 2 3
+ TBD | length | suboptions...| 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
+----+----+----+----+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RSOO | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboptions...
+-+-+-+-+-+-+-+-+-+-+-+
TBD Relay-Supplied Options code OPTION_RSOO Relay-Supplied Options code (TBD).
length Length of Relay-Supplied Options option option-length Length of Relay-Supplied Options option.
suboptions One or more DHCPv6 options suboptions One or more DHCPv6 options.
4. DHCP Relay Agent Behavior 4. RSOO-enabled options
Unless specifically called out as an RSOO-enabled option, no DHCP
option should appear in an RSOO. Specifications that describe RSOO-
enabled options MUST reference this specification, and MUST state
that the option they define is RSOO-enabled.
5. DHCP Relay Agent Behavior
Relay agents MAY include a Relay-Supplied Options option in the Relay agents MAY include a Relay-Supplied Options option in the
option payload of a Relay-Forward message. Relay agents MUST NOT option payload of a Relay-Forward message. Relay agents MUST NOT
modify the contents of any message before forwarding it to the DHCP modify the contents of any message before forwarding it to the DHCP
client. client.
5. DHCP Server Behavior 6. DHCP Server Behavior
A DHCP server that implements this spec must have a user-configurable DHCP servers that implement this specification MUST examine each
setting which determines whether or not it accepts a Relay-Supplied option contained in an RSOO to see if it is an RSOO-enabled option.
Options option. If the DHCP server is configured not to accept the DHCP servers MUST silently discard any option contained in an RSOO
RSOO, it MUST discard any such options that it receives. that is not RSOO-enabled. DHCP server implementations SHOULD have a
user-configurable list of RSOO-enabled options, so that new RSOO-
enabled options do not require software to be updated.
DHCP servers normally construct a list of options that are candidates DHCP servers normally construct a list of options that are candidates
to send to the DHCP client, and then constructs the DHCP packet to send to the DHCP client, and then construct the DHCP packet
according to section 17.2.2 of DHCPv6 [RFC3315]. according to section 17.2.2 of DHCPv6 [RFC3315].
If the server receives an RSOO and is configured to accept it, it If the server receives an RSOO and is configured to accept it, it
SHOULD add any options that appear in the RSOO for which it has no SHOULD add any options that appear in the RSOO for which it has no
internal candidate to the list of options that are candidates to send internal candidate to the list of options that are candidates to send
to the DHCP client. The server SHOULD discard any options that to the DHCP client. The server SHOULD discard any options that
appear in the RSOO for which it already has one or more candidates. appear in the RSOO for which it already has one or more candidates.
If the server receives more than one RSOO, it SHOULD not foward
multiple versions of the same option from different RSOOs to the DHCP
client.
Aside from the addition of options from the RSOO, the DHCP server Aside from the addition of options from the RSOO, the DHCP server
should then construct a DHCP packet as it normally would, and should then construct a DHCP packet as it normally would, and
transmit it to the DHCP client as described in DHCPv6 [RFC3315]. transmit it to the DHCP client as described in DHCPv6 [RFC3315].
DHCP Server implementations MAY discard options deemed inappropriate DHCP Server implementations MAY discard options deemed inappropriate
to forward. For example, it would never be appropriate for the DHCP to forward. For example, it would never be appropriate for the DHCP
server to forward an IA option. The list of options that will be server to forward an IA option. The list of options that will be
discarded SHOULD be configurable by the administrator. discarded SHOULD be configurable by the administrator.
6. Security Considerations 7. Security Considerations
This document provides a mechanism whereby a relay agent can inject This document provides a mechanism whereby a relay agent can inject
options into the response the DHCP server sends to the DHCP client. options into the response the DHCP server sends to the DHCP client.
Because the DHCP server prefers its own configured options to those Because the DHCP server prefers its own configured options to those
supplied by the relay agent, this can't be used as a means for supplied by the relay agent, this can't be used as a means for
overriding server-supplied options. However, it is still possible in overriding server-supplied options. However, it is still possible in
some configurations for a rogue DHCP relay agent to supply additional some configurations for a rogue DHCP relay agent to supply additional
options to the DHCP client. options to the DHCP client.
Because the relay agent is supplying options which the DHCP server Because the relay agent is supplying options which the DHCP server
might then sign, this provides a mechanism whereby an attacker could might then sign, this provides a mechanism whereby an attacker could
get the DHCP server to authenticate a message that the attacker could get the DHCP server to authenticate a message that the attacker could
not itself forge to the client. not itself forge to the client.
For this reason, DHCP servers in environments where a rogue relay For this reason, DHCP servers in environments where a rogue relay
could interpose itself into the packet flow SHOULD authenticate the could interpose itself into the packet flow SHOULD authenticate the
relay agent as described in section 21.1 of DHCPv6 [RFC3315]. relay agent as described in section 21.1 of DHCPv6 [RFC3315].
Note, however, that this attack is only useful if the DHCP server is Note, however, that this attack is only useful if the DHCP server is
using the DHCPv6 authentication mechanism; in the absence of DHCPv6 using the DHCPv6 authentication mechanism to authenticate the message
authentication, the relay agent could more easily forge a message to that it sends to the DHCP client. If the message from the server to
the client, rather than using this mechanism to cause the server to the client is not authenticated, the relay agent can simply add
produce a message containing forged information. whatever options it wants to the message for the client, rather than
using this more complicated mechanism to provide the same option by
way of the server.
7. IANA Considerations Furthermore, because DHCP servers will discard non-RSOO-enabled
options provided by relay agents, the risk is limited to options that
are specifically designed to be provided by relay agents, so the set
of options that could be provided in such an attack is very
restricted.
8. IANA Considerations
We request that IANA assign one new option code from the registry of We request that IANA assign one new option code from the registry of
DHCP Option Codes maintained at DHCP Option Codes maintained at
http://www.iana.org/assignments/dhcpv6-parameters. This option code http://www.iana.org/assignments/dhcpv6-parameters. This option code
will be assigned to the Relay-Supplied Options option. will be assigned to the Relay-Supplied Options option.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
8.2. Informative References 9.2. Informative References
[I.D-ietf-hokey-ldn-discovery] [I.D-ietf-hokey-ldn-discovery]
Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name
DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in
progress), September 2010. progress), September 2010.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
authentication Protocol (ERP)", RFC 5296, August 2008. authentication Protocol (ERP)", RFC 5296, August 2008.
Authors' Addresses Authors' Addresses
 End of changes. 19 change blocks. 
33 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/