idnits 2.17.1 draft-ietf-dhc-agent-vpn-id-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 456. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 5978 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 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 3040 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc Working Group Kim Kinnear 3 Internet Draft Mark Stapp 4 Intended Status: Standards Track Richard Johnson 5 Expires: May 16, 2008 Jay Kumarasamy 6 Cisco Systems 7 November 16, 2007 9 Virtual Subnet Selection Sub-Option 10 for the Relay Agent Information Option for DHCPv4 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 16, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 In some environments, a relay agent resides in a network element 45 which also has access to one or more virtual private networks (VPNs). 46 If a DHCP server wishes to offer service to DHCP clients on those 47 different VPNs the DHCP server needs to know information about the 48 VPN on which each client resides. The Virtual Subnet Selection sub- 49 option of the relay-agent-information option is used by the relay 50 agent to tell the DHCP server important information about the VPN 51 (called the Virtual Subnet Selection information, or VSS) for every 52 DHCP request it passes on to the DHCP server, and is also used to 53 properly forward any DHCP reply that the DHCP server sends back to 54 the relay agent. 56 1. Introduction 58 There exist situations where there are multiple VPNs serviced by one 59 or more network elements which also contain relay agents. These 60 VPNs contain DHCP clients, and there is a desire to allow a DHCP 61 server to supply the full range of DHCP services to these DHCP 62 clients. 64 The network element which contains the relay agent typically is also 65 the network element which knows about the VPN association of the DHCP 66 client and could include information about the VPN in the relay- 67 agent-information option in the client's DHCP requests. This 68 information about the VPN is called the Virtual Subnet Selection 69 information, or VSS information. This document defines a sub-option 70 for the relay-agent-information option which contains this VSS 71 information, and which allows the relay agent to communicate the VSS 72 information to the DHCP server. 74 When the DHCP server sends its response to the relay agent for 75 forwarding back to the DHCP client, the relay agent will also need to 76 use the Virtual Subnet Selection sub-option to determine to which VPN 77 to send the DHCP response. 79 This sub-option can also be used by the DHCP server to inform a relay 80 agent that a particular DHCP client is associated with a particular 81 VPN by sending the Virtual Subnet Selection sub-option in the relay- 82 agent-information option back to the relay agent. 84 Consider the following architecture: 86 +--------+ +---------------+ 87 | DHCP | IP x| Relay Agent | IP z 88 | Server |-.......-| and +---+-------+-------+ 89 +--------+ | VPN manager | | | | 90 +---+-----------+ | | | 91 |IP y +-----+ +--+--+ +--+--+ 92 +-+-----+ |Host1| |Host2| |Host3| 93 | | +-----+ +-----+ +-----+ 94 | | 95 +-----+ +--+--+ VPN 2 96 |Host1| |Host2| 97 +-----+ +-----+ 99 VPN 1 101 In this architecture, the relay agent knows the VPN for each of the 102 DHCP clients, and inserts the VSS information about the VPN in the 103 Virtual Subnet Selection sub-option in every DHCP request it forwards 104 on to the DHCP server. 106 When the DHCP server copies the relay-agent-information option from 107 the incoming packet into the server's reply packet, it will copy over 108 the Virtual Subnet Selection sub-option as well. 110 When the relay agent receives a DHCP reply packet from the server 111 with a Virtual Subnet Selection sub-option, it will forward the 112 packet onto the proper VPN based on the VSS information in the 113 Virtual Subnet Selection sub-option. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC 2119]. 121 This document uses the following terms: 123 o "DHCP client" 125 A DHCP client is a host using DHCP to obtain configuration 126 parameters such as a network address. 128 o "DHCP relay agent" 130 A DHCP relay agent is a third-party agent that transfers BOOTP 131 and DHCP messages between clients and servers residing on 132 different subnets, per [RFC 951] and [RFC 1542]. 134 o "DHCP server" 136 A DHCP server is a host that returns configuration parameters to 137 DHCP clients. 139 o "downstream" 141 Downstream is the direction from the access concentrator towards 142 the subscriber. 144 o "upstream" 146 Upstream is the direction from the subscriber towards the access 147 concentrator. 149 o "VSS information" 151 Information about a VPN necessary to allocate an address to a 152 DHCP client on that VPN and necessary to forward a DHCP reply 153 packet to a DHCP client on that VPN. 155 o "VPN" 157 Virtual private network. A network which appears to the client 158 to be a private network. 160 o "VPN Identifier" 162 The VPN-ID is defined by [RFC 2685] to be a sequence of 7 163 octets. 165 3. Virtual Subnet Selection Sub-Option Definition 167 The Virtual Subnet Selection sub-option MAY be used by any DHCP relay 168 agent which desires to specify the VSS information about a VPN from 169 which a DHCP client request was sent. 171 The Virtual Subnet Selection sub-option contains a generalized way to 172 specify the VSS information about a VPN. 174 The format of the option is: 176 SubOpt Len Type VPN identifier 177 +------+------+------+------+------+------+--- 178 | TBD | n | t | id1 | id2 | id3 | ... 179 +------+------+------+------+------+------+--- 181 Type: 0 NVT ASCII VPN identifier 182 1 RFC2685 VPN-ID 183 2-255 Not Allowed 185 There are two types of identifiers which can be placed in the Virtual 186 Subnet Selection sub-option. The first type of identifier which can 187 be placed in the Virtual Subnet Selection sub-option is an NVT ASCII 188 string. It MUST NOT be terminated with a zero byte. 190 The second type of identifier which can be placed in the Virtual 191 Subnet Selection sub-option is an RFC2685 VPN-ID [RFC 2685], which is 192 defined to be 7 octets in length. 194 All other values of the type field are invalid as of this memo and 195 VSS sub-options containing any other value than zero (0) or one (1) 196 SHOULD be ignored. 198 A relay agent which recieves a DHCP request from a DHCP client on a 199 VPN SHOULD include a Virtual Subnet Selection sub-option in the 200 relay-agent-information option that it inserts in the DHCP packet 201 prior to forwarding it on to the DHCP server. 203 The value placed in the Virtual Subnet Selection sub-option SHOULD be 204 sufficient for the relay agent to properly route any DHCP reply 205 packet returned from the DHCP server to the DHCP client for which it 206 is destined. Servers supporting this sub-option MUST return an 207 instance of this sub-option in the relay-agent-info option to any 208 relay-agent that sends it. Servers SHOULD return the an exact copy 209 of the sub-option unless they desire to change the VPN on which a 210 client was configured, which would typically be a very unusual thing 211 to do. 213 In the event that a Virtual Subnet Selection option and a Virtual 214 Subnet Selection sub-option are both received in a particular DHCP 215 client packet, the information from the Virtual Subnet Selection 216 sub-option MUST be used in preference to the information in the 217 Virtual Subnet Selection option. This reasoning behind this approach 218 is that the relay-agent is almost certainly more trusted than the 219 DHCP client, and therefore information in the relay-agent-information 220 option that conflicts with information in the packet generated by the 221 DHCP client is more likely to be correct. 223 Relay agents which include this sub-option when forwarding DHCP 224 client requests should probably discard DHCPOFFER or DHCPACK packets 225 that do not contain this sub-option in their associated relay-agent- 226 info options. This does not imply any memory of the particular 227 packets forwarded with this sub-option included. Rather, the 228 expectation is that the relay agent will use whatever algorithm that 229 it used on the DHCPDISCOVER and DHCPREQUEST packets to decide to 230 include this sub-option on the DHCPOFFER and DHCPACK packets to 231 decide if they should have this sub-option included in their relay- 232 agent-info options. 234 Since this sub-option is placed in the packet in order to change the 235 VPN on which an IP address is allocated for a particular DHCP client, 236 one presumes that an allocation on that VPN is necessary for correct 237 operation. If this presumption is correct, then a relay agent which 238 places this sub-option in a packet and doesn't receive it in the 239 returning packet should drop the packet since the IP address that was 240 allocated will not be in the correct VPN. If an IP address that is 241 on the requested VPN is not required, then the relay agent is free to 242 pass the packet along to the DHCP client with the IP address that is 243 not on the VPN that the relay agent requested. 245 Servers that do not understand this option will allocate an address 246 using their normal algorithms and will not return this option in the 247 DHCPOFFER or DHCPACK. In this case the client should consider 248 discarding the DHCPOFFER or DHCPACK, as mentioned above. Servers 249 that understand this option but are administratively configured to 250 ignore the option MUST ignore the option, use their normal algorithms 251 to allocate an address, and MUST NOT return this option in the 252 DHCPOFFER or DHCPACK such that the client will know that the 253 allocated address is not in the VPN requested and will consider this 254 information in deciding whether or not to accept the DHCPOFFER. In 255 other words, this option MUST NOT appear in a DHCPOFFER or DHCPACK 256 from a server unless it was used by the server in making or updating 257 the address allocation requested. 259 In some cases, a DHCP server may use the Virtual Subnet Selection 260 sub-option to inform a relay agent that a particular DHCP client is 261 associated with a particular VPN. It does this by sending the 262 Virtual Subnet Selection sub-option with the appropriate information 263 to the relay agent in the relay-agent-information option. If the 264 relay agent is unable to honor the DHCP server's requirement to place 265 the DHCP client into that VPN it MUST drop the packet and not send it 266 to the DHCP client. 268 This sub-option SHOULD NOT be used without also making use of some 269 form of authentication for relay-agent-information option. 271 While this sub-option is the way that a relay-agent can insert VPN 272 information into a DHCP client packet that it is forwarding, when a 273 relay-agent needs to submit a DHCP Leasequery packet to the DHCP 274 server in order to recover information about existing DHCP allocated 275 IP addresses on other than the normal, global VPN, it SHOULD NOT use 276 this sub-option. Instead, it SHOULD use the Virtual Subnet Selection 277 option, since in the context of a DHCP Leasequery the relay agent is 278 the client and is not relaying a packet for another DHCP client. 280 4. Security 282 Message authentication in DHCP relay agents as defined in [RFC 3040] 283 should be considered for relay agents employing this sub-option. 284 Potential exposures to attack are discussed in section 7 of the DHCP 285 protocol specification in [RFC 2131]. 287 The Virtual Subnet Selection sub-option could be used by a DHCP 288 client masquerading as a relay agent in order to obtain an IP address 289 from a VPN other than the one on which it resides. The DHCP server 290 processing for this sub-option should be aware of this possibility 291 and use whatever techniques it can devise to prevent such an attack. 292 Information such as the giaddr might be used to detect and prevent 293 this sort of attack, as well as the use of The Authentication 294 Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay 295 Agent Option [RFC 3040]. 297 Any program which unicasts a DHCP packet to the DHCP server with a 298 relay-agent-information option in it with a vpn-id for a different 299 VPN would cause the DHCP server to allocate an address from that 300 different VPN, but since the DHCP server cannot (in general) 301 communicate directly back to the program that sent in the malicious 302 DHCP packet, the entire cycle of creating a lease will not be 303 completed. Certainly many leases could be offered, which would 304 result in a temporary form of address-pool exhaustion. 306 Servers that implement the Virtual Subnet Selection sub-option MUST 307 by default disable use of the feature; it must specifically be 308 enabled through configuration. Moreover, a server SHOULD provide the 309 ability to selectively enable use of the feature under restricted 310 conditions, e.g., by enabling use of the option only from explicitly 311 configured client-ids, enabling its use only by clients on a 312 particular subnet, or restricting the VPNs from which addresses may 313 be requested. 315 5. IANA Considerations 317 IANA is requested to assign sub-option number 151 for this sub-option 318 in the DHCP Relay Agent Sub-options space [RFC 3046], in accordance 319 with the spirit of [RFC 3942]. While [RFC 3942] doesn't explicitly 320 mention the sub-option space for the DHCP Relay Agent Information 321 option, sub-option 151 is already in use by existing implementations 322 of this sub-option and the current draft is essentially compatible 323 with these current implementations. 325 IANA has assigned the value of TBD for the VPN Identifier sub-option 326 from the DHCP Relay Agent Sub-options space [RFC 3046] for the VPN 327 Identifier sub-option defined in Section 3. 329 While the type byte of the Virtual Subnet Selection sub-option 330 defines a number space that could be managed by IANA, expansion of 331 this number space is not anticipated and so creation of a registry of 332 these numbers is not required by this document. In the event that 333 additional values for the type byte are defined in subsequent 334 documents, IANA should at that time create a registry for these type 335 bytes. New values for the type byte may only be defined by IETF 336 Consensus, as described in [RFC 2434]. Basically, this means that 337 they are defined by RFCs approved by the IESG. 339 Moreover, any changes or additions to the type byte codes MUST be 340 made concurrently in the type byte codes of the Virtual Subnet 341 Selection option. The type bytes and data formats of the Virtual 342 Subnet Selection option and Virtual Subnet Selection sub-option MUST 343 always be identical. 345 6. Acknowledgments 347 None. 349 7. Normative References 351 [RFC 951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 352 September 1985. 354 [RFC 1542] Wimer, W., "Clarifications and Extensions for the 355 Bootstrap Protol", RFC 1542, October 1993. 357 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", RFC 2119, March 1997. 360 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 361 2131, March 1997. 363 [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 364 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 365 1998. 367 [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks 368 Identifier", RFC 2685, September 1999. 370 [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 371 3046, January 2001. 373 [RFC 3040] Stapp, M. and T. Lemon, "The Authentication Suboption for 374 the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option" 375 RFC 3040, March 2005. 377 [RFC 3942] Volz, B., "Reclassifying Dynamic Host Configuration 378 Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004. 380 8. Authors' Addresses 382 Kim Kinnear 383 Cisco Systems 384 1414 Massachusetts Ave. 385 Boxborough, Massachusetts 01719 387 Phone: (978) 936-0000 389 EMail: kkinnear@cisco.com 391 Richard Johnson 392 Jay Kumarasamy 393 Cisco Systems 394 170 W. Tasman Dr. 395 San Jose, CA 95134 397 Phone: (408) 526-4000 399 EMail: raj@cisco.com 401 Mark Stapp 402 Cisco Systems 403 1414 Massachusetts Ave. 404 Boxborough, Massachusetts 01719 405 Phone: (978) 936-0000 407 EMail: mjs@cisco.com 409 Jay Kumarasamy 410 Cisco Systems 411 170 W. Tasman Dr. 412 San Jose, CA 95134 414 Phone: (408) 526-4000 416 EMail: jayk@cisco.com 418 9. Full Copyright Statement 420 Copyright (C) The IETF Trust (2007). 422 This document is subject to the rights, licenses and restrictions 423 contained in BCP 78, and except as set forth therein, the authors retain 424 all their rights. 426 This document and the information contained herein are provided on an 427 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 428 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 429 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 430 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 431 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 432 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 434 10. Intellectual Property 436 The IETF takes no position regarding the validity or scope of any 437 Intellectual Property Rights or other rights that might be claimed to 438 pertain to the implementation or use of the technology described in this 439 document or the extent to which any license under such rights might or 440 might not be available; nor does it represent that it has made any 441 independent effort to identify any such rights. Information on the 442 procedures with respect to rights in RFC documents can be found in BCP 443 78 and BCP 79. 445 Copies of IPR disclosures made to the IETF Secretariat and any 446 assurances of licenses to be made available, or the result of an attempt 447 made to obtain a general license or permission for the use of such 448 proprietary rights by implementers or users of this specification can be 449 obtained from the IETF on-line IPR repository at 450 http://www.ietf.org/ipr. 452 The IETF invites any interested party to bring to its attention any 453 copyrights, patents or patent applications, or other proprietary rights 454 that may cover technology that may be required to implement this 455 standard. Please address the information to the IETF at 456 ietf-ipr@ietf.org. 458 11. Acknowledgment 460 Funding for the RFC Editor function is provided by the IETF 461 Administrative Support Activity (IASA).