idnits 2.17.1 draft-ietf-dhc-vpn-option-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 302. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (June 29, 2005) is 6876 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) == Unused Reference: '1' is defined on line 222, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 4 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: December 31, 2005 K. Kinnear 5 M. Stapp 6 Cisco 7 June 29, 2005 9 Virtual Subnet Selection Option 10 draft-ietf-dhc-vpn-option-05.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 December 31, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This memo defines a new DHCP option for passing Virtual Subnet 44 Selection (VSS) information between the DHCP client and the DHCP 45 server. It is intended for use primarily by DHCP proxy clients in 46 situations where VSS information needs to be passed to the DHCP 47 server for proper address allocation to take place. 49 The option number currently in use is 221. This memo documents the 50 current usage of the option in agreement with RFC-3942[7] , which 51 declares that any pre-existing usages of option numbers in the range 52 128 - 223 should be documented and the working group will try to 53 officially assign those numbers to those options. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. VSS Information Definition . . . . . . . . . . . . . . . . . 4 59 3. Security Considerations . . . . . . . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 64 Intellectual Property and Copyright Statements . . . . . . . 10 66 1. Introduction 68 There is a growing use of Virtual Private Network (VPN) 69 configurations. The growth comes from many areas; individual client 70 systems needing to appear to be on the home corporate network even 71 when traveling, ISPs providing extranet connectivity for customer 72 companies, etc. In some of these cases there is a need for the DHCP 73 server to know the VPN (hereafter called a "Virtual Subject Selector" 74 or "VSS") from which an address, and other resources, should be 75 allocated. 77 If the allocation is being done through a DHCP relay, then a relay 78 suboption could be included. In some cases, however an IP address is 79 being sought by a DHCP proxy on behalf of a client (would may be 80 assigned the address via a different protocol). In this case, there 81 is a need to include VSS information relating to the client as a DHCP 82 option. 84 A good example might be a dial-in aggregation device where PPP 85 addresses are acquired via DHCP and then given to the remove customer 86 system via IPCP. In a network where such a device is used to 87 aggregate PPP dial-in from multiple companies, each company may be 88 assigned a unique VSS. 90 This memo defines a new DHCP [2] option, the VSS Information option, 91 which allows the DHCP client to specify the VSS Information needed in 92 order to allocate an address. If the receiving DHCP server 93 understands the VSS Information option, this information may be used 94 in conjunction with other information in determining the subnet on 95 which to select an address as well as other information such as DNS 96 server, default router, etc. 98 2. VSS Information Definition 100 The VSS Information option is a DHCP option [3]. The option contains 101 generalized VSS information in one of two formats: NVT ASCII VPN 102 identifier, or RFC2685 VPN-ID [4]. 104 The format of the option is: 106 Code Len Type VSS Information octets 107 +-----+-----+------+-----+-----+-----+--- 108 | 221 | n | t | v1 | v2 | v3 | ... 109 +-----+-----+------+-----+-----+-----+--- 111 Type: 0 NVT ASCII VPN identifier 112 1 RFC2685 VPN-ID 113 2-255 Not Allowed 115 Figure 1 117 The option minimum length (n) is 2. 119 There are two types of identifiers which can be placed in the VSS 120 Information Option. The first type of identifier which can be placed 121 in the VSS Information Option is an NVT ASCII string. It MUST NOT be 122 terminated with a zero byte. 124 The second type of identifier which can be placed in the VSS 125 Information Option is an RFC2685 VPN-ID [4], which is typically 14 126 hex digits in length (though it can be any length as far as the VSS 127 Information Option is concerned). 129 If the type field is set to zero (0), it indicates that all following 130 bytes of the option contain a NVT ASCII string. This string MUST NOT 131 be terminated with a zero byte. 133 If the type field is set to one (1), it indicates that all following 134 bytes should be interpreted in agreement with [4] as a VPN 135 Identifier, typically 14 hex digits. 137 All other values of the type field are invalid as of this memo and 138 VSS options containing any other value than zero (0) or one (1) 139 SHOULD be ignored. 141 Any VSS information contained in a DHCP Relay Suboption SHOULD 142 override the information contained in this VSS Information option 144 Servers configured to support this option MUST return an identical 145 copy of the option to any client that sends it, regardless of whether 146 or not the client requests the option in a parameter request list. 147 Clients using this option MUST discard DHCPOFFER or DHCPACK packets 148 that do not contain this option. 150 This option provides the DHCP server additional information upon 151 which to make a determination of address to be assigned. The DHCP 152 server, if it is configure to support this option, should use this 153 information in addition to other options included in the DHCPDISCOVER 154 packet in order to assign an IP address for DHCP client. 156 In the event that a VSS Informmation Option and a VSS Information 157 Relay Suboption are both received in a particular DHCP client packet, 158 the information from the VSS Information Suboption MUST be used in 159 preference to the information in the VSS Information Option. 161 Servers that do not understand this option will allocate an address 162 using their normal algorithms and will not return this option in the 163 DHCPOFFER or DHCPACK. In this case the client will discard the 164 DHCPOFFER or DHCPACK. Servers that understand this option but are 165 administratively configured to ignore the option MUST ignore the 166 option, use their normal algorithms to allocate an address, and MUST 167 NOT return this option in the DHCPOFFER or DHCPACK. In this case the 168 client will discard the DHCPOFFER or DHCPACK. In other words, this 169 option MUST NOT appear in a DHCPOFFER from a server unless it was 170 used by the server in making the address allocation requested. 172 This option SHOULD NOT be used without also making use of the DHCP 173 Authentication option [5]. 175 3. Security Considerations 177 Message authentication in DHCP for intradomain use where the out-of- 178 band exchange of a shared secret is feasible is defined in [5]. 179 Potential exposures to attack are discussed in section 7 of the DHCP 180 protocol specification in [2]. 182 The VSS Information option could be used by a client in order to 183 obtain an IP address from a VSS other than the one where it should. 184 DHCP relays MAY choose to remove the option before passing on 185 DHCPDISCOVER packets. Another possible defense would be for the DHCP 186 relay to insert a Relay option containing a VSS Information 187 Suboption, which would override the DHCP VSS Information option. 189 This option would allow a client to perform a more complete address- 190 pool exhaustion attack since the client would no longer be restricted 191 to attacking address-pools on just its local subnet. 193 Servers that implement the VSS Information option MUST by default 194 disable use of the feature; it must specifically be enabled through 195 configuration. Moreover, a server SHOULD provide the ability to 196 selectively enable use of the feature under restricted conditions, 197 e.g., by enabling use of the option only from explicitly configured 198 client-ids, enabling its use only by clients on a particular subnet, 199 or restricting the VSSs from which addresses may be requested. 201 4. IANA Considerations 203 No assignment of values for the type field need be made at this time. 204 New values may only be defined by IETF Consensus, as described in 205 [6]. Basically, this means that they are defined by RFCs approved by 206 the IESG. 208 Moreover, any changes or additions to the type byte codes MUST be 209 made concurrently in the type byte codes of the VSS Information 210 Option. The type bytes and data formats of the VSS Information 211 Option and VSS Information Suboption MUST always be identical. 213 5. Acknowledgements 215 This document is the result of work done within Cisco Systems. 216 Thanks to Kim Kinnear, Mark Stapp, and Jay Kumarasamy for their work 217 on this option definition and the other related work for which this 218 is necessary. 220 6. References 222 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 223 Levels", RFC 2119, BCP 14, March 1997. 225 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 226 March 1997. 228 [3] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 229 Extensions", RFC 2132, March 1997. 231 [4] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", 232 RFC 2685, September 1999. 234 [5] Droms, R., "Authentication for DHCP Messages", RFC 3118, 235 June 2001. 237 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 238 Considerations Section in RFCs", RFC 2434, October 1998. 240 [7] Volz, B., "Reclassifying Dynamic Host Configuration Protocol 241 version 4 (DHCPv4) Options", RFC 3942, November 2004. 243 Authors' Addresses 245 Richard A. Johnson 246 Cisco Systems 247 170 W. Tasman Dr. 248 San Jose, CA 95134 249 US 251 Phone: +1 408 526 4000 252 Email: raj@cisco.com 253 Jay Kumarasamy 254 Cisco Systems 255 170 W. Tasman Dr. 256 San Jose, CA 95134 257 US 259 Phone: +1 408 526 4000 260 Email: jayk@cisco.com 262 Kim Kinnear 263 Cisco Systems 264 250 Apollo Drive 265 Chelmsford, MA 01824 266 US 268 Phone: +1 978 244 8000 269 Email: kkinnar@cisco.com 271 Mark Stapp 272 Cisco Systems 273 250 Apollo Drive 274 Chelmsford, MA 01824 275 US 277 Phone: +1 978 244 8000 278 Email: mjs@cisco.com 280 Intellectual Property Statement 282 The IETF takes no position regarding the validity or scope of any 283 Intellectual Property Rights or other rights that might be claimed to 284 pertain to the implementation or use of the technology described in 285 this document or the extent to which any license under such rights 286 might or might not be available; nor does it represent that it has 287 made any independent effort to identify any such rights. Information 288 on the procedures with respect to rights in RFC documents can be 289 found in BCP 78 and BCP 79. 291 Copies of IPR disclosures made to the IETF Secretariat and any 292 assurances of licenses to be made available, or the result of an 293 attempt made to obtain a general license or permission for the use of 294 such proprietary rights by implementers or users of this 295 specification can be obtained from the IETF on-line IPR repository at 296 http://www.ietf.org/ipr. 298 The IETF invites any interested party to bring to its attention any 299 copyrights, patents or patent applications, or other proprietary 300 rights that may cover technology that may be required to implement 301 this standard. Please address the information to the IETF at 302 ietf-ipr@ietf.org. 304 Disclaimer of Validity 306 This document and the information contained herein are provided on an 307 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 308 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 309 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 310 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 311 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 312 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 314 Copyright Statement 316 Copyright (C) The Internet Society (2005). This document is subject 317 to the rights, licenses and restrictions contained in BCP 78, and 318 except as set forth therein, the authors retain all their rights. 320 Acknowledgment 322 Funding for the RFC Editor function is currently provided by the 323 Internet Society.