idnits 2.17.1 draft-ietf-dhc-agent-vpn-id-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 380. 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 (August 2007) is 6098 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 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 Intended Status: Standards Track Richard Johnson 5 Jay Kumarasamy 6 Cisco Systems 8 February 2007 9 Expires August 2007 11 Virtual Subnet Selection Sub-Option 12 for the Relay Agent Information Option for DHCPv4 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 28, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 In some environments, a relay agent resides in a network element 47 which also has access to one or more virtual private networks (VPNs). 48 If one DHCP server wishes to offer service to DHCP clients on those 49 different VPNs the DHCP server needs to know information about the 50 VPN on which each client resides. The virtual-subnet-selection sub- 51 option of the relay-agent-information option is used by the relay 52 agent to tell the DHCP server important information about the VPN 53 (called the Virtual Subnet Selection information, or VSS) for every 54 DHCP request it passes on to the DHCP server, and is also used to 55 properly forward any DHCP reply that the DHCP server sends back to 56 the relay agent. 58 1. Introduction 60 There exist situations where there are multiple VPNs serviced by one 61 or more network elements which also contain relay agents. These 62 VPNs contain DHCP clients, and there is a desire to allow one DHCP 63 server to supply the full range of DHCP services to these DHCP 64 clients. 66 The network element which contains the relay agent typically is also 67 the network element which knows about the VPN association of the DHCP 68 client and could include information about the VPN in the relay- 69 agent-information option in the client's DHCP requests. This 70 information about the VPN is called the Virtual Subnet Selection 71 information, or VSS information. This document defines a sub-option 72 for the relay-agent-information option which contains this VSS 73 information, and which allows the relay agent to communicate the VSS 74 information to the DHCP server. 76 When the DHCP server sends its response to the relay agent for 77 forwarding back to the DHCP client, the relay agent will also need to 78 use the virtual-subnet-selection sub-option to determine to which VPN 79 to send the DHCP response. 81 This sub-option can also be used by the DHCP server to inform a relay 82 agent that a particular DHCP client is associated with a particular 83 VPN by sending the virtual-subnet-selection sub-option in the relay- 84 agent-information option back to the relay agent. 86 Consider the following architecture: 88 +--------+ +---------------+ 89 | DHCP | IP x| Relay Agent | IP z 90 | Server |-.......-| and +---+-------+-------+ 91 +--------+ | VPN manager | | | | 92 +---+-----------+ | | | 93 |IP y +-----+ +--+--+ +--+--+ 94 +-+-----+ |Host1| |Host2| |Host3| 95 | | +-----+ +-----+ +-----+ 96 | | 97 +-----+ +--+--+ VPN 2 98 |Host1| |Host2| 99 +-----+ +-----+ 101 VPN 1 103 In this architecture, the relay agent knows the VPN for each of the 104 DHCP clients, and inserts the VSS information about the VPN in the 105 virtual-subnet-selection sub-option in every DHCP request it forwards 106 on to the DHCP server. 108 When the DHCP server copies over the relay-agent-information option 109 from the request to the reply packet, it will copy over the virtual- 110 subnet-selection sub-option as well. 112 When the relay agent receives a DHCP reply packet from the server 113 with a virtual-subnet-selection sub-option, it will forward the 114 packet onto the proper VPN based on the VSS information in the 115 virtual-subnet-selection sub-option. 117 2. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC 2119]. 123 This document uses the following terms: 125 o "DHCP client" 127 A DHCP client is an Internet host using DHCP to obtain 128 configuration parameters such as a network address. 130 o "DHCP relay agent" 132 A DHCP relay agent is a third-party agent that transfers BOOTP 133 and DHCP messages between clients and servers residing on 134 different subnets, per [RFC 951] and [RFC 1542]. 136 o "DHCP server" 138 A DHCP server is an Internet host that returns configuration 139 parameters to DHCP clients. 141 o "downstream" 143 Downstream is the direction from the access concentrator towards 144 the subscriber. 146 o "upstream" 148 Upstream is the direction from the subscriber towards the access 149 concentrator. 151 o "VSS information" 153 Information about a VPN necessary to allocate an address to a 154 DHCP client on that VPN and necessary to forward a DHCP reply 155 packet to a DHCP client on that VPN. 157 o "VPN" 159 Virtual private network. A network which appears to the client 160 to be a private network. 162 o "VPN Identifier" 164 The VPN-ID is defined by [RFC 2685] to be a sequence of 14 hex 165 digits. 167 3. Virtual Subnet Selection Sub-Option Definition 169 The virtual-subnet-selection sub-option MAY be used by any DHCP relay 170 agent which desires to specify the VSS information about a VPN from 171 which a DHCP client request was sent. 173 The virtual-subnet-selection sub-option contains a generalized way to 174 specify the VSS information about a VPN. 176 The format of the option is: 178 SubOpt Len Type VPN identifier 179 +------+------+------+------+------+------+--- 180 | TBD | n | t | id1 | id2 | id3 | ... 181 +------+------+------+------+------+------+--- 183 Type: 0 NVT ASCII VPN identifier 184 1 RFC2685 VPN-ID 185 2-255 Not Allowed 187 There are two types of identifiers which can be placed in the 188 virtual-subnet-selection sub-option. The first type of identifier 189 which can be placed in the virtual-subnet-selection sub-option is an 190 NVT ASCII string. It MUST NOT be terminated with a zero byte. 192 The second type of identifier which can be placed in the virtual- 193 subnet-selection sub-option is an RFC2685 VPN-ID [RFC 2685], which is 194 typically 14 hex digits in length (though it can be any length as far 195 as the virtual-subnet-selection sub-option is concerned). 197 All other values of the type field are invalid as of this memo and 198 VSS sub-options containing any other value than zero (0) or one (1) 199 SHOULD be ignored. 201 A relay agent which recieves a DHCP request from a DHCP client on a 202 VPN SHOULD include a virtual-subnet-selection sub-option in the 203 relay-agent-information option that it inserts in the DHCP packet 204 prior to forwarding it on to the DHCP server. 206 The value placed in the virtual-subnet-selection sub-option SHOULD be 207 sufficient for the relay agent to properly route any DHCP reply 208 packet returned from the DHCP server to the DHCP client for which it 209 is destined. Servers supporting this sub-option MUST return an 210 instance of this sub-option in the relay-agent-info option to any 211 relay-agent that sends it. Servers SHOULD return the an exact copy 212 of the sub-option unless they desire to change the VPN on which a 213 client was configured, which would typically be a very unusual thing 214 to do. 216 In the event that a virtual-subnet-selection option and a virtual- 217 subnet-selection sub-option are both received in a particular DHCP 218 client packet, the information from the virtual-subnet-selection 219 sub-option MUST be used in preference to the information in the 220 virtual-subnet-selection option. 222 Relay agents which include this sub-option when forwarding DHCP 223 client requests MUST discard DHCPOFFER or DHCPACK packets that do not 224 contain this sub-option in their associated relay-agent-info options. 225 This does not imply any memory of the particular packets forwarded 226 with this sub-option included. Rather, the expectation is that the 227 relay agent will use whatever algorithm that it used on the 228 DHCPDISCOVER and DHCPREQUEST packets to decide to include this sub- 229 option on the DHCPOFFER and DHCPACK packets to decide if they MUST 230 have this sub-option included in their relay-agent-info options. 232 In some cases, a DHCP server may use the virtual-subnet-selection 233 sub-option to inform a relay agent that a particular DHCP client is 234 associated with a particular VPN. It does this by sending the 235 virtual-subnet-selection sub-option with the appropriate information 236 to the relay agent in the relay-agent-information option. If the 237 relay agent is unable to honor the DHCP server's requirement to place 238 the DHCP client into that VPN it MUST drop the packet and not send it 239 to the DHCP client. 241 This sub-option SHOULD NOT be used without also making use of some 242 form of authentication for relay-agent-information option. 244 4. Security 246 Message authentication in DHCP for intradomain use where the out-of- 247 band exchange of a shared secret is feasible is defined in [RFC 248 3118]. Potential exposures to attack are discussed in section 7 of 249 the DHCP protocol specification in [RFC 2131]. 251 The virtual-subnet-selection sub-option could be used by a client in 252 order to obtain an IP address from a VPN other than the one on which 253 it resides. This attack can be partially prevented by the relay 254 agent not forwarding any DHCP packet which already contains a relay- 255 agent-information option. 257 Any program which unicasts a DHCP packet to the DHCP server with a 258 relay-agent-information option in it with a vpn-id for a different 259 VPN would cause the DHCP server to allocate an address from that 260 different VPN, but since the DHCP server cannot (in general) 261 communicate directly back to the program that sent in the malicious 262 DHCP packet, the entire cycle of creating a lease will not be 263 completed. Certainly many leases could be offered, which would 264 result in a temporaty form of address-pool exhaustion. 266 Servers that implement the virtual-subnet-selection sub-option MUST 267 by default disable use of the feature; it must specifically be 268 enabled through configuration. Moreover, a server SHOULD provide the 269 ability to selectively enable use of the feature under restricted 270 conditions, e.g., by enabling use of the option only from explicitly 271 configured client-ids, enabling its use only by clients on a 272 particular subnet, or restricting the VPNs from which addresses may 273 be requested. 275 5. IANA Considerations 277 IANA has assigned the value of TBD for the VPN Identifier sub-option 278 from the DHCP Relay Agent Sub-options space [RFC 3046] for the VPN 279 Identifier sub-option defined in Section 3. 281 This document defines a number space for the type byte of the 282 virtual-subnet-selection sub-option. Certain allowable values for 283 this byte are defined in this specification (see Section 3). New 284 values may only be defined by IETF Consensus, as described in [RFC 285 2434]. Basically, this means that they are defined by RFCs approved 286 by the IESG. 288 Moreover, any changes or additions to the type byte codes MUST be 289 made concurrently in the type byte codes of the virtual-subnet- 290 selection option. The type bytes and data formats of the virtual- 291 subnet-selection option and virtual-subnet-selection sub-option MUST 292 always be identical. 294 6. Acknowledgments 296 None. 298 7. Normative References 300 [RFC 951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 301 September 1985. 303 [RFC 1542] Wimer, W., "Clarifications and Extensions for the 304 Bootstrap Protol", RFC 1542, October 1993. 306 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", RFC 2119, March 1997. 309 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 310 2131, March 1997. 312 [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks 313 Identifier", Internet RFC 2685, September 1999. 315 [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 316 3046, January 2001. 318 8. Authors' Addresses 320 Kim Kinnear 321 Mark Stapp 322 Cisco Systems 323 1414 Massachusetts Ave. 324 Boxborough, Massachusetts 01719 326 Phone: (978) 936-0000 328 EMail: kkinnear@cisco.com 329 mjs@cisco.com 331 Jay Kumarasamy 332 Richard Johnson 333 Cisco Systems 334 170 W. Tasman Dr. 335 San Jose, CA 95134 337 Phone: (408) 526-4000 339 EMail: jayk@cisco.com 340 raj@cisco.com 342 9. Full Copyright Statement 344 Copyright (C) The IETF Trust (2007). 346 This document is subject to the rights, licenses and restrictions 347 contained in BCP 78, and except as set forth therein, the authors retain 348 all their rights. 350 This document and the information contained herein are provided on an 351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 352 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 353 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 354 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 355 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 358 10. Intellectual Property 360 The IETF takes no position regarding the validity or scope of any 361 Intellectual Property Rights or other rights that might be claimed to 362 pertain to the implementation or use of the technology described in this 363 document or the extent to which any license under such rights might or 364 might not be available; nor does it represent that it has made any 365 independent effort to identify any such rights. Information on the 366 procedures with respect to rights in RFC documents can be found in BCP 367 78 and BCP 79. 369 Copies of IPR disclosures made to the IETF Secretariat and any 370 assurances of licenses to be made available, or the result of an attempt 371 made to obtain a general license or permission for the use of such 372 proprietary rights by implementers or users of this specification can be 373 obtained from the IETF on-line IPR repository at 374 http://www.ietf.org/ipr. 376 The IETF invites any interested party to bring to its attention any 377 copyrights, patents or patent applications, or other proprietary rights 378 that may cover technology that may be required to implement this 379 standard. Please address the information to the IETF at ietf- 380 ipr@ietf.org. 382 11. Acknowledgment 384 Funding for the RFC Editor function is provided by the IETF 385 Administrative Support Activity (IASA).