idnits 2.17.1 draft-ietf-dhc-vpn-option-07.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 325 has weird spacing: '... Option for D...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 6000 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 (ref. '7') (Obsoleted by RFC 5226) == Outdated reference: A later version (-06) exists of draft-ietf-dhc-agent-vpn-id-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Johnson 3 Internet-Draft J. Kumarasamy 4 Expires: May 19, 2008 K. Kinnear 5 M. Stapp 6 Cisco 7 November 16, 2007 9 Virtual Subnet Selection Option 10 draft-ietf-dhc-vpn-option-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This memo defines existing usage for the Virtual Subnet Selection 44 (VSS) information option. It is intended for use primarily by DHCP 45 proxy clients in situations where VSS information needs to be passed 46 to the DHCP server for proper address allocation to take place. 48 The option number currently in use is 221. This memo documents the 49 current usage of the option in agreement with [8], which declares 50 that any pre-existing usages of option numbers in the range 128 - 223 51 should be documented and the working group will try to officially 52 assign those numbers to those options. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. VSS Information Definition . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 66 Intellectual Property and Copyright Statements . . . . . . . . . . 12 68 1. Introduction 70 There is a growing use of Virtual Private Network (VPN) 71 configurations. The growth comes from many areas; individual client 72 systems needing to appear to be on the home corporate network even 73 when traveling, ISPs providing extranet connectivity for customer 74 companies, etc. In some of these cases there is a need for the DHCP 75 server to know the VPN (hereafter called a "Virtual Subnet Selector" 76 or "VSS") from which an address, and other resources, should be 77 allocated. 79 If the allocation is being done through a DHCP relay, then a relay 80 sub-option could be included. In some cases, however an IP address 81 is being sought by a DHCP proxy on behalf of a client (which may be 82 assigned the address via a different protocol). In this case, there 83 is a need to include VSS information relating to the client as a DHCP 84 option. 86 A good example might be a dial-in aggregation device where PPP [10] 87 addresses are acquired via DHCP and then given to the remote customer 88 system via IPCP [9]. In a network where such a device is used to 89 aggregate PPP dial-in from multiple companies, each company may be 90 assigned a unique VSS. 92 This memo defines a new DHCP [4] option, the VSS Information option, 93 which allows the DHCP client to specify the VSS Information needed in 94 order to allocate an address. If the receiving DHCP server 95 understands the VSS Information option, this information may be used 96 in conjunction with other information in determining the subnet on 97 which to select an address as well as other information such as DNS 98 server, default router, etc. 100 2. Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 104 document are to be interpreted as described in [3]. 106 This document also uses the following terms: 108 DHCP Client 109 DHCP Client or "Client" is an Internet host using DHCP to obtain 110 configuration parameters such as a network address. 112 DHCP Server 113 A DHCP Server or "Server" is an Internet host that returns 114 configuration parameters to DHCP Clients. 116 DHCP relay agent 117 A DHCP relay agent is a third-party agent that transfers BOOTP and 118 DHCP messages between clients and servers residing on different 119 subnets, per [1] and [2]. 121 downstream 122 Downstream is the direction from the access concentrator towards 123 the subscriber. 125 upstream 126 Upstream is the direction from the subscriber towards the access 127 concentrator. 129 VSS information 130 Information about a VPN necessary to allocate an address to a DHCP 131 client on that VPN and necessary to forward a DHCP reply packet to 132 a DHCP client on that VPN. 134 VPN 135 Virtual private network. A network which appears to the client to 136 be a private network. 138 VPN Identifier 139 The VPN-ID is defined by [6] to be a sequence of 7 octets. 141 3. VSS Information Definition 143 The VSS Information option is a DHCP option [5]. The option contains 144 generalized VSS information in one of two formats: NVT ASCII VPN 145 identifier, or RFC2685 VPN-ID [6]. 147 The format of the option is: 149 Code Len Type VSS Information octets 150 +-----+-----+------+-----+-----+-----+--- 151 | 221 | n | t | v1 | v2 | v3 | ... 152 +-----+-----+------+-----+-----+-----+--- 154 Type: 0 NVT ASCII VPN identifier 155 1 RFC2685 VPN-ID 156 2-255 Not Allowed 158 Figure 1 160 The option minimum length (n) is 2. 162 There are two types of identifiers which can be placed in the VSS 163 Information Option. The first type of identifier which can be placed 164 in the VSS Information Option is an NVT ASCII string. It MUST NOT be 165 terminated with a zero byte. 167 The second type of identifier which can be placed in the VSS 168 Information Option is an RFC2685 VPN-ID [6], which is typically 7 169 octets (3 of VPN OUI followed by 4 of VPN index) in length (though it 170 can be any length as far as the VSS Information Option is concerned). 172 If the type field is set to zero (0), it indicates that all following 173 bytes of the option contain a NVT ASCII string. This string MUST NOT 174 be terminated with a zero byte. 176 If the type field is set to one (1), it indicates that all following 177 bytes should be interpreted in agreement with RFC2685 as a VPN 178 Identifier, typically 7 octets. 180 All other values of the type field are invalid as of this memo and 181 VSS options containing any other value than zero (0) or one (1) 182 SHOULD be ignored. 184 Since this option is placed in the packet in order to change the VPN 185 on which an IP address is allocated for a particular DHCP client, one 186 presumes that an allocation on that VPN is necessary for correct 187 operation. If this presumption is correct, then a client which 188 places this option in a packet and doesn't receive it in the 189 returning packet should drop the packet since the IP address that was 190 allocated will not be in the correct VPN. If an IP address that is 191 not on the requested VPN is not required, then the client is free to 192 accept the IP address that is not on the VPN that the was requested. 194 Servers configured to support this option MUST return an identical 195 copy of the option to any client that sends it, regardless of whether 196 or not the client requests the option in a parameter request list. 198 This option provides the DHCP server additional information upon 199 which to make a determination of address to be assigned. The DHCP 200 server, if it is configured to support this option, should use this 201 information in addition to other options included in the DHCPDISCOVER 202 packet in order to assign an IP address for DHCP client. 204 In the event that a Virtual Subnet Selection option and a Virtual 205 Subnet Selection sub-option [12] are both received in a particular 206 DHCP client packet, the information from the Virtual Subnet Selection 207 sub-option MUST be used in preference to the information in the 208 Virtual Subnet Selection option. This reasoning behind this approach 209 is that the relay-agent is almost certainly more trusted than the 210 DHCP client, and therefore information in the relay-agent-information 211 option that conflicts with information in the packet generated by the 212 DHCP client is more likely to be correct. 214 Servers that do not understand this option will allocate an address 215 using their normal algorithms and will not return this option in the 216 DHCPOFFER or DHCPACK. In this case the client should consider 217 discarding the DHCPOFFER or DHCPACK, as mentioned above. Servers 218 that understand this option but are administratively configured to 219 ignore the option MUST ignore the option, use their normal algorithms 220 to allocate an address, and MUST NOT return this option in the 221 DHCPOFFER or DHCPACK such that the client will know that the 222 allocated address is not in the VPN requested and will consider this 223 information in deciding whether or not to accept the DHCPOFFER. In 224 other words, this option MUST NOT appear in a DHCPOFFER or DHCPACK 225 from a server unless it was used by the server in making or updating 226 the address allocation requested. 228 4. Security Considerations 230 Message authentication in DHCP for intradomain use where the out-of- 231 band exchange of a shared secret is feasible is defined in [11]. 232 Potential exposures to attack are discussed in section 7 of the DHCP 233 protocol specification in [4]. 235 The VSS Information option could be used by a client in order to 236 obtain an IP address from a VPN other than the one where it should. 237 Another possible defense would be for the DHCP relay to insert a 238 Relay option containing a VSS Information Relay Sub-option, which 239 would override the DHCP VSS Information option. 241 This option would allow a client to perform a more complete address- 242 pool exhaustion attack since the client would no longer be restricted 243 to attacking address-pools on just its local subnet. 245 Servers that implement the VSS Information option MUST by default 246 disable use of the feature; it must specifically be enabled through 247 configuration. Moreover, a server SHOULD provide the ability to 248 selectively enable use of the feature under restricted conditions, 249 e.g., by enabling use of the option only from explicitly configured 250 client-ids, enabling its use only by clients on a particular subnet, 251 or restricting the VSSs from which addresses may be requested. 253 Implementations should consider using the DHCP Authentication option 254 [11] in order to provide a higher level of security if it is deemed 255 necessary in their environment. 257 5. IANA Considerations 259 IANA is requested to assign DHCP option number 221 for this option, 260 in accordance with [8]. 262 While the type byte of the Virtual Subnet Selection option defines a 263 number space that could be managed by IANA, expansion of this number 264 space is not anticipated and so creation of a registry of these 265 numbers is not required by this document. In the event that 266 additional values for the type byte are defined in subsequent 267 documents, IANA should at that time create a registry for these type 268 bytes. New values for the type byte may only be defined by IETF 269 Consensus, as described in [7]. Basically, this means that they are 270 defined by RFCs approved by the IESG. 272 Moreover, any changes or additions to the type byte codes MUST be 273 made concurrently in the type byte codes of the VSS Information 274 Option. The type bytes and data formats of the VSS Information 275 Option and VSS Information Relay Sub-option MUST always be identical. 277 6. Acknowledgements 279 This document is the result of work done within Cisco Systems. 280 Thanks to Kim Kinnear, Mark Stapp, and Jay Kumarasamy for their work 281 on this option definition and the other related work for which this 282 is necessary. 284 7. References 286 7.1. Normative References 288 [1] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", 289 RFC 951, September 1985. 291 [2] Wimer, W., "Clarifications and Extensions for the Bootstrap 292 Protocol", RFC 1542, October 1993. 294 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 295 Levels", BCP 14, RFC 2119, March 1997. 297 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 298 March 1997. 300 [5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 301 Extensions", RFC 2132, March 1997. 303 [6] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", 304 RFC 2685, September 1999. 306 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 307 Considerations Section in RFCs", BCP 26, RFC 2434, 308 October 1998. 310 [8] Volz, B., "Reclassifying Dynamic Host Configuration Protocol 311 version 4 (DHCPv4) Options", RFC 3942, November 2004. 313 7.2. Informative References 315 [9] McGregor, G., "The PPP Internet Protocol Control Protocol 316 (IPCP)", RFC 1332, May 1992. 318 [10] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 319 RFC 1661, July 1994. 321 [11] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 322 RFC 3118, June 2001. 324 [12] Kinnear, K., "Virtual Subnet Selection Sub-Option for the Relay 325 Agent Information Option for DHCPv4", 326 draft-ietf-dhc-agent-vpn-id-05 (work in progress), 327 November 2007. 329 Authors' Addresses 331 Richard A. Johnson 332 Cisco Systems 333 170 W. Tasman Dr. 334 San Jose, CA 95134 335 US 337 Phone: +1 408 526 4000 338 Email: raj@cisco.com 340 Jay Kumarasamy 341 Cisco Systems 342 170 W. Tasman Dr. 343 San Jose, CA 95134 344 US 346 Phone: +1 408 526 4000 347 Email: jayk@cisco.com 349 Kim Kinnear 350 Cisco Systems 351 250 Apollo Drive 352 Chelmsford, MA 01824 353 US 355 Phone: +1 978 244 8000 356 Email: kkinnar@cisco.com 358 Mark Stapp 359 Cisco Systems 360 250 Apollo Drive 361 Chelmsford, MA 01824 362 US 364 Phone: +1 978 244 8000 365 Email: mjs@cisco.com 367 Full Copyright Statement 369 Copyright (C) The IETF Trust (2007). 371 This document is subject to the rights, licenses and restrictions 372 contained in BCP 78, and except as set forth therein, the authors 373 retain all their rights. 375 This document and the information contained herein are provided on an 376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 378 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 379 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 380 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 Intellectual Property 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed to 387 pertain to the implementation or use of the technology described in 388 this document or the extent to which any license under such rights 389 might or might not be available; nor does it represent that it has 390 made any independent effort to identify any such rights. Information 391 on the procedures with respect to rights in RFC documents can be 392 found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use of 397 such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository at 399 http://www.ietf.org/ipr. 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 this standard. Please address the information to the IETF at 405 ietf-ipr@ietf.org. 407 Acknowledgment 409 Funding for the RFC Editor function is provided by the IETF 410 Administrative Support Activity (IASA).