idnits 2.17.1 draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 internal candidate to the list of options that are candidates to send to the DHCP client. The server SHOULD discard any options that 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. -- The document date (September 29, 2010) is 4958 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc T. Lemon 3 Internet-Draft Nominum 4 Intended status: Standards Track Q. Wu 5 Expires: April 2, 2011 Huawei 6 September 29, 2010 8 Relay-Supplied DHCP Options 9 draft-ietf-dhc-dhcpv6-relay-supplied-options-02 11 Abstract 13 This document describes a general mechanism whereby a DHCPv6 relay 14 agent can provide options to a DHCPv6 server that the DHCPv6 server 15 can then provide to the DHCPv6 client. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 2, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. RSOO-enabled options . . . . . . . . . . . . . . . . . . . . . 4 57 5. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 4 58 6. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The DHCPv6 specification [RFC3315] allows DHCP relay agents to 69 forward DHCPv6 messages between clients and servers that are not on 70 the same IPv6 link. In some cases the DHCP relay agent has 71 information the DHCP server does not have that would be useful to 72 provide to a DHCP client. For example, the DHCP client may need to 73 learn the EAP local domain name [I.D-ietf-hokey-ldn-discovery] for 74 use in EAP re-authentication [RFC5296], which is known to the relay 75 agent but not the server. The DHCPv6 protocol specification does not 76 provide a mechanism whereby the relay agent can provide options to 77 the client. This document extends DHCP with a mechanism that allows 78 DHCP relay agents to propose options for the server to send to DHCP 79 clients. 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 1.2. Terminology 89 The following terms and acronyms are used in this document: 91 DHCP - Dynamic Host Configuration Protocol Version 6 [RFC3315] 93 RSOO - Relay-Supplied Options option 95 2. Protocol Summary 97 DHCP clients do not support a mechanism for receiving options from 98 relay agents--the function of the relay agent is simply to deliver 99 the payload from the server. Consequently, in order for the DHCP 100 relay agent to provide options to the client, it sends those options 101 to the DHCP server, encapsulated in a Relay-Supplied Options option. 102 The DHCP server can then choose to place those options in the 103 response it sends to the client. 105 3. Encoding 107 In order to supply options for the DHCP server, the relay agent sends 108 a Relay-Supplied Options option in the Relay-Forward message. This 109 option encapsulates whatever options the relay agent wishes to 110 provide to the DHCPv6 server. 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | OPTION_RSOO | option-length | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | suboptions... 118 +-+-+-+-+-+-+-+-+-+-+-+ 120 OPTION_RSOO Relay-Supplied Options code (TBD). 122 option-length Length of Relay-Supplied Options option. 124 suboptions One or more DHCPv6 options. 126 4. RSOO-enabled options 128 Unless specifically called out as an RSOO-enabled option, no DHCP 129 option should appear in an RSOO. Specifications that describe RSOO- 130 enabled options MUST reference this specification, and MUST state 131 that the option they define is RSOO-enabled. 133 5. DHCP Relay Agent Behavior 135 Relay agents MAY include a Relay-Supplied Options option in the 136 option payload of a Relay-Forward message. Relay agents MUST NOT 137 modify the contents of any message before forwarding it to the DHCP 138 client. 140 6. DHCP Server Behavior 142 DHCP servers that implement this specification MUST examine each 143 option contained in an RSOO to see if it is an RSOO-enabled option. 144 DHCP servers MUST silently discard any option contained in an RSOO 145 that is not RSOO-enabled. DHCP server implementations SHOULD have a 146 user-configurable list of RSOO-enabled options, so that new RSOO- 147 enabled options do not require software to be updated. 149 DHCP servers normally construct a list of options that are candidates 150 to send to the DHCP client, and then construct the DHCP packet 151 according to section 17.2.2 of DHCPv6 [RFC3315]. 153 If the server receives an RSOO and is configured to accept it, it 154 SHOULD add any options that appear in the RSOO for which it has no 155 internal candidate to the list of options that are candidates to send 156 to the DHCP client. The server SHOULD discard any options that 157 appear in the RSOO for which it already has one or more candidates. 158 If the server receives more than one RSOO, it SHOULD not foward 159 multiple versions of the same option from different RSOOs to the DHCP 160 client. 162 Aside from the addition of options from the RSOO, the DHCP server 163 should then construct a DHCP packet as it normally would, and 164 transmit it to the DHCP client as described in DHCPv6 [RFC3315]. 166 DHCP Server implementations MAY discard options deemed inappropriate 167 to forward. For example, it would never be appropriate for the DHCP 168 server to forward an IA option. The list of options that will be 169 discarded SHOULD be configurable by the administrator. 171 7. Security Considerations 173 This document provides a mechanism whereby a relay agent can inject 174 options into the response the DHCP server sends to the DHCP client. 175 Because the DHCP server prefers its own configured options to those 176 supplied by the relay agent, this can't be used as a means for 177 overriding server-supplied options. However, it is still possible in 178 some configurations for a rogue DHCP relay agent to supply additional 179 options to the DHCP client. 181 Because the relay agent is supplying options which the DHCP server 182 might then sign, this provides a mechanism whereby an attacker could 183 get the DHCP server to authenticate a message that the attacker could 184 not itself forge to the client. 186 For this reason, DHCP servers in environments where a rogue relay 187 could interpose itself into the packet flow SHOULD authenticate the 188 relay agent as described in section 21.1 of DHCPv6 [RFC3315]. 190 Note, however, that this attack is only useful if the DHCP server is 191 using the DHCPv6 authentication mechanism to authenticate the message 192 that it sends to the DHCP client. If the message from the server to 193 the client is not authenticated, the relay agent can simply add 194 whatever options it wants to the message for the client, rather than 195 using this more complicated mechanism to provide the same option by 196 way of the server. 198 Furthermore, because DHCP servers will discard non-RSOO-enabled 199 options provided by relay agents, the risk is limited to options that 200 are specifically designed to be provided by relay agents, so the set 201 of options that could be provided in such an attack is very 202 restricted. 204 8. IANA Considerations 206 We request that IANA assign one new option code from the registry of 207 DHCP Option Codes maintained at 208 http://www.iana.org/assignments/dhcpv6-parameters. This option code 209 will be assigned to the Relay-Supplied Options option. 211 9. References 213 9.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 219 and M. Carney, "Dynamic Host Configuration Protocol for 220 IPv6 (DHCPv6)", RFC 3315, July 2003. 222 9.2. Informative References 224 [I.D-ietf-hokey-ldn-discovery] 225 Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name 226 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in 227 progress), September 2010. 229 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 230 authentication Protocol (ERP)", RFC 5296, August 2008. 232 Authors' Addresses 234 Ted Lemon 235 Nominum 236 2000 Seaport Blvd 237 Redwood City, CA 94063 238 USA 240 Phone: +1 650 381 6000 241 Email: mellon@nominum.com 242 Qin Wu 243 Huawei Technologies Co., Ltd. 244 101 Software Avenue, Yuhua District 245 Nanjing, Jiangsu 210012 246 China 248 Email: sunseawq@huawei.com