idnits 2.17.1 draft-ietf-dhc-agent-vpn-id-03.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 3667, Section 5.1 on line 20. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 365), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 343 has weird spacing: '...imed to perta...' -- 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 (July 2005) is 6854 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) == Missing Reference: 'RFC 951' is mentioned on line 132, but not defined == Missing Reference: 'RFC 1542' is mentioned on line 132, but not defined == Missing Reference: 'RFC2685' is mentioned on line 162, but not defined == Unused Reference: 'RFC 2132' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC 3118' is defined on line 313, but no explicit reference was found in the text Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kim Kinnear 3 INTERNET DRAFT Mark Stapp 4 Richard Johnson 5 Jay Kumarasamy 6 Cisco Systems 8 February 2005 9 Expires July 2005 11 Virtual Subnet Selection Sub-Option 12 for the Relay Agent Information Option 13 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 or will be disclosed, and any of which I become aware will be 20 disclosed, in accordance with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 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 one 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 one 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 informa- 68 tion about the VPN is called the Virtual Subnet Selection informa- 69 tion, or VSS information. This document defines a sub-option for the 70 relay-agent-information option which contains this VSS information, 71 and which allows the relay agent to communicate the VSS information 72 to the DHCP server. 74 When the DHCP server sends its response to the relay agent for for- 75 warding 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 over the relay-agent-information option 107 from the request to the reply packet, it will copy over the virtual- 108 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. 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 an Internet host using DHCP to obtain confi- 126 guration 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 dif- 132 ferent subnets, per [RFC 951] and [RFC 1542]. 134 o "DHCP server" 136 A DHCP server is an Internet host that returns configuration 137 parameters to 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 [RFC2685] to be a sequence of 14 hex 163 digits. 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 186 virtual-subnet-selection sub-option. The first type of identifier 187 which can be placed in the virtual-subnet-selection sub-option is an 188 NVT ASCII 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 typically 14 hex digits in length (though it can be any length as far 193 as the virtual-subnet-selection sub-option is concerned). 195 All other values of the type field are invalid as of this memo and 196 VSS sub-options containing any other value than zero (0) or one (1) 197 SHOULD be ignored. 199 A relay agent which recieves a DHCP request from a DHCP client on a 200 VPN SHOULD include a virtual-subnet-selection sub-option in the 201 relay-agent-information option that it inserts in the DHCP packet 202 prior to forwarding it on to the DHCP server. 204 The value placed in the virtual-subnet-selection sub-option SHOULD be 205 sufficient for the relay agent to properly route any DHCP reply 206 packet returned from the DHCP server to the DHCP client for which it 207 is destined. Servers supporting this sub-option MUST return an 208 instance of this sub-option in the relay-agent-info option to any 209 relay-agent that sends it. Servers SHOULD return the an exact copy 210 of the sub-option unless they desire to change the VPN on which a 211 client was configured, which would typically be a very unusual thing 212 to do. 214 In the event that a virtual-subnet-selection option and a virtual- 215 subnet-selection sub-option are both received in a particular DHCP 216 client packet, the information from the virtual-subnet-selection 217 sub-option MUST be used in preference to the information in the 218 virtual-subnet-selection option. 220 Relay agents which include this sub-option when forwarding DHCP 221 client requests MUST discard DHCPOFFER or DHCPACK packets that do not 222 contain this sub-option in their associated relay-agent-info options. 223 This does not imply any memory of the particular packets forwarded 224 with this sub-option included. Rather, the expectation is that the 225 relay agent will use whatever algorithm that it used on the DHCPDIS- 226 COVER and DHCPREQUEST packets to decide to include this sub-option on 227 the DHCPOFFER and DHCPACK packets to decide if they MUST have this 228 sub-option included in their relay-agent-info options. 230 In some cases, a DHCP server may use the virtual-subnet-selection 231 sub-option to inform a relay agent that a particular DHCP client is 232 associated with a particular VPN. It does this by sending the 233 virtual-subnet-selection sub-option with the appropriate information 234 to the relay agent in the relay-agent-information option. If the 235 relay agent is unable to honor the DHCP server's requirement to place 236 the DHCP client into that VPN it MUST drop the packet and not send it 237 to the DHCP client. 239 This sub-option SHOULD NOT be used without also making use of some 240 form of authentication for relay-agent-information option. 242 4. Security 244 Message authentication in DHCP for intradomain use where the out-of- 245 band exchange of a shared secret is feasible is defined in [RFC 246 3118]. Potential exposures to attack are discussed in section 7 of 247 the DHCP protocol specification in [RFC 2131]. 249 The virtual-subnet-selection sub-option could be used by a client in 250 order to obtain an IP address from a VPN other than the one on which 251 it resides. This attack can be partially prevented by the relay 252 agent not forwarding any DHCP packet which already contains a relay- 253 agent-information option. 255 Any program which unicasts a DHCP packet to the DHCP server with a 256 relay-agent-information option in it with a vpn-id for a different 257 VPN would cause the DHCP server to allocate an address from that dif- 258 ferent VPN, but since the DHCP server cannot (in general) communicate 259 directly back to the program that sent in the malicious DHCP packet, 260 the entire cycle of creating a lease will not be completed. Cer- 261 tainly many leases could be offered, which would result in a tem- 262 poraty form of address-pool exhaustion. 264 Servers that implement the virtual-subnet-selection sub-option MUST 265 by default disable use of the feature; it must specifically be 266 enabled through configuration. Moreover, a server SHOULD provide the 267 ability to selectively enable use of the feature under restricted 268 conditions, e.g., by enabling use of the option only from explicitly 269 configured client-ids, enabling its use only by clients on a particu- 270 lar subnet, or restricting the VPNs from which addresses may be 271 requested. 273 5. IANA Considerations 275 IANA has assigned the value of TBD for the VPN Identifier sub-option 276 from the DHCP Relay Agent Sub-options space [RFC 3046] for the VPN 277 Identifier sub-option defined in Section 3. 279 This document defines a number space for the type byte of the 280 virtual-subnet-selection sub-option. Certain allowable values for 281 this byte are defined in this specification (see Section 3). New 282 values may only be defined by IETF Consensus, as described in [RFC 283 2434]. Basically, this means that they are defined by RFCs approved 284 by the IESG. 286 Moreover, any changes or additions to the type byte codes MUST be 287 made concurrently in the type byte codes of the virtual-subnet- 288 selection option. The type bytes and data formats of the virtual- 289 subnet-selection option and virtual-subnet-selection sub-option MUST 290 always be identical. 292 6. Acknowledgments 294 None. 296 7. Normative References 298 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", RFC 2119, March 1997. 301 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 302 2131, March 1997. 304 [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 305 Extensions", Internet RFC 2132, March 1997. 307 [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks Identif- 308 ier", Internet RFC 2685, September 1999. 310 [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 311 3046, January 2001. 313 [RFC 3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, 314 June 2001. 316 8. Author's information 318 Kim Kinnear 319 Mark Stapp 320 Cisco Systems 321 1414 Massachusetts Ave. 322 Boxborough, Massachusetts 01719 324 Phone: (978) 936-0000 326 EMail: kkinnear@cisco.com 327 mjs@cisco.com 329 Jay Kumarasamy 330 Richard Johnson 331 Cisco Systems 332 170 W. Tasman Dr. 333 San Jose, CA 95134 335 Phone: (408) 526-4000 337 EMail: jayk@cisco.com 338 raj@cisco.com 340 9. Intellectual Property Statement 342 The IETF takes no position regarding the validity or scope of any intel- 343 lectual property or other rights that might be claimed to pertain to 344 the implementation or use of the technology described in this document 345 or the extent to which any license under such rights might or might not 346 be available; neither does it represent that it has made any effort to 347 identify any such rights. Information on the IETF's procedures with 348 respect to rights in standards-track and standards-related documentation 349 can be found in BCP-11. Copies of claims of rights made available for 350 publication and any assurances of licenses to be made available, or the 351 result of an attempt made to obtain a general license or permission for 352 the use of such proprietary rights by implementors or users of this 353 specification can be obtained from the IETF Secretariat. 355 The IETF invites any interested party to bring to its attention any 356 copyrights, patents or patent applications, or other proprietary rights 357 which may cover technology that may be required to practice this 358 standard. Please address the information to the IETF Executive Direc- 359 tor. 361 10. Full Copyright Statement 363 Copyright (C) The Internet Society (2005). This document is subject to 364 the rights, licenses and restrictions contained in BCP 78, and except as 365 set forth therein, the authors retain all their rights. 367 This document and the information contained herein are provided on an 368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 369 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 370 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 371 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 372 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 373 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.