idnits 2.17.1 draft-ietf-dhc-agent-vpn-id-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 304 has weird spacing: '...imed to perta...' == Line 333 has weird spacing: '...for the purpo...' -- 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 (May 2003) is 7645 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 123, but not defined == Missing Reference: 'RFC 1542' is mentioned on line 123, but not defined == Missing Reference: 'RFC2685' is mentioned on line 146, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 245, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC 2132' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'RFC 3118' is defined on line 274, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 2 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 November 2002 9 Expires May 2003 11 VPN Identifier sub-option 12 for the Relay Agent Information Option 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 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 Copyright Notice 38 Copyright (C) The Internet Society (2002). All Rights Reserved. 40 Abstract 42 In some environments, a relay agent resides in a network element 43 which also has access to one or more VPNs. If one DHCP server wishes 44 to offer service to DHCP clients on those different VPNs the DHCP 45 server needs to know the VPN on which each client resides. The vpn- 46 id sub-option of the relay-agent-information option is used by the 47 relay agent to tell the DHCP server the VPN for every DHCP request it 48 passes on to the DHCP server, and is also used to properly forward 49 any DHCP reply that the DHCP server sends back to the relay agent. 51 1. Introduction 53 There exist situations where there are multiple VPNs serviced by one 54 or more network elements which also contain relay agents. These 55 VPNs contain DHCP clients, and there is a desire to allow one DHCP 56 server to supply the full range of DHCP services to these DHCP 57 clients. 59 The network element which contains the relay agent typically is also 60 the network element which knows about the VPN association of the DHCP 61 client and could include this information in the relay-agent- 62 information option in the client's DHCP requests. This document 63 defines a sub-option for the relay-agent-information option which 64 contains the vpn-id, and which allows the relay agent to communicate 65 the VPN association to the DHCP server. 67 When the DHCP server sends its response to the relay agent for for- 68 warding back to the DHCP client, the relay agent will also need to 69 use the vpn-id sub-option to determine to which VPN to send the DHCP 70 response. 72 This sub-option can also be used by the DHCP server to inform a relay 73 agent that a particular DHCP client is associated with a particular 74 VPN by sending the vpn-id sub-option to the relay agent in the 75 relay-agent-information option back to the relay agent. 77 Consider the following architecture: 79 +--------+ +---------------+ 80 | DHCP | IP x| Relay Agent | IP z 81 | Server |-.......-| and +---+-------+-------+ 82 +--------+ | VPN manager | | | | 83 +---+-----------+ | | | 84 |IP y +-----+ +--+--+ +--+--+ 85 +-+-----+ |Host1| |Host2| |Host3| 86 | | +-----+ +-----+ +-----+ 87 | | 88 +-----+ +--+--+ VPN 2 89 |Host1| |Host2| 90 +-----+ +-----+ 92 VPN 1 94 In this architecture, the relay agent knows the VPN for each of the 95 DHCP clients, and inserts that information in the vpn-id sub-option 96 in every DHCP request it forwards onto the DHCP server. 98 When the DHCP server copies over the relay-agent-information option 99 from the request to the reply packet, it will copy over the vpn-id 100 sub-option as well. 102 When the relay agent receives a DHCP reply packet from the server 103 with a vpn-id sub-option, it will forward the packet onto the proper 104 VPN based on the value of the vpn-id sub-option. 106 2. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC 2119]. 112 This document uses the following terms: 114 o "DHCP client" 116 A DHCP client is an Internet host using DHCP to obtain confi- 117 guration parameters such as a network address. 119 o "DHCP relay agent" 121 A DHCP relay agent is a third-party agent that transfers BOOTP 122 and DHCP messages between clients and servers residing on dif- 123 ferent subnets, per [RFC 951] and [RFC 1542]. 125 o "DHCP server" 127 A DHCP server is an Internet host that returns configuration 128 parameters to DHCP clients. 130 o "downstream" 132 Downstream is the direction from the access concentrator towards 133 the subscriber. 135 o "upstream" 137 Upstream is the direction from the subscriber towards the access 138 concentrator. 140 o "VPN" 141 Virtual private network. A network which appears to the client 142 to be a private network. 144 o "VPN Identifier" 146 The VPN-ID is defined by [RFC2685] to be a sequence of 14 hex 147 digits. 149 3. VPN identifier sub-option definition 151 The vpn-id sub-option MAY be used by any DHCP relay agent which 152 desires to specify the VPN from which a DHCP client request was sent. 154 The vpn-id sub-option contains a generalized VPN identifier. 156 The format of the option is: 158 SubOpt Len Type VPN identifier 159 +------+------+------+------+------+------+--- 160 | TBD | n | t | id1 | id2 | id3 | ... 161 +------+------+------+------+------+------+--- 163 Type: 0 NVT ASCII VPN identifier 164 1 RFC2685 VPN-ID 165 2-255 Not Allowed 167 There are two types of identifiers which can be placed in the vpn-id 168 sub-option. The first type of identifier which can be placed in the 169 vpn-id sub-option is an NVT ASCII string. It MUST NOT be terminated 170 with a zero byte. 172 The second type of identifier which can be placed in the vpn-id sub- 173 option is an RFC2685 VPN-ID [RFC 2685], which is typically 14 hex 174 digits in length (though it can be any length as far as the vpn-id 175 sub-option is concerned). 177 A relay agent which recieves a DHCP request from a DHCP client on a 178 VPN SHOULD include a vpn-id sub-option in the relay-agent-information 179 option that it inserts in the DHCP packet prior to forwarding it on 180 to the DHCP server. 182 The value placed in the vpn-id sub-option SHOULD be sufficient for 183 the relay agent to properly route any DHCP reply packet returned from 184 the DHCP server to the DHCP client for which it is destined. Servers 185 supporting this sub-option MUST return an identical copy of the sub- 186 option in the relay-agent-info option to any relay-agent that sends 187 it. 189 In the event that a vpn-id option and a vpn-id sub-option are both 190 received in a particular DHCP client packet, the information from the 191 vpn-id sub-option MUST be used in preference to the information in 192 the vpn-id option. 194 Relay agents which include this sub-option when forwarding DHCP 195 client requests MUST discard DHCPOFFER or DHCPACK packets that do not 196 contain this sub-option in their associated relay-agent-info options. 198 In some cases, a DHCP server may use the vpn-id sub-option to inform 199 a relay agent that a particular DHCP client is associated with a par- 200 ticular VPN. It does this by sending the vpn-id sub-option with the 201 appropriate information to the relay agent in the relay-agent- 202 information option. If the relay agent is unable to honor the DHCP 203 server's requirement to place the DHCP client into that VPN it MUST 204 drop the packet and not send it back to the DHCP client. 206 4. Security 208 Message authentication in DHCP for intradomain use where the out-of- 209 band exchange of a shared secret is feasible is defined in [RFC 210 3118]. Potential exposures to attack are discussed in section 7 of 211 the DHCP protocol specification in [RFC 2131]. 213 The vpn-id sub-option could be used by a client in order to obtain an 214 IP address from a VPN other than the one on which it resides. This 215 attack can be partially prevented by the relay agent not forwarding 216 any DHCP packet which already contains a relay-agent-information 217 option. 219 Any program which unicasts a DHCP packet to the DHCP server with a 220 relay-agent-information option in it with a vpn-id for a different 221 VPN would cause the DHCP server to allocate an address from that dif- 222 ferent VPN, but since the DHCP server cannot (in general) communicate 223 directly back to the program that sent in the malicious DHCP packet, 224 the entire cycle of creating a lease will not be completed. Cer- 225 tainly many leases could be offered, which would result in a form of 226 address-pool exhaustion. 228 Servers that implement the vpn-id sub-option MUST by default disable 229 use of the feature; it must specifically be enabled through confi- 230 guration. Moreover, a server SHOULD provide the ability to selec- 231 tively enable use of the feature under restricted conditions, e.g., 232 by enabling use of the option only from explicitly configured 233 client-ids, enabling its use only by clients on a particular subnet, 234 or restricting the VPNs from which addresses may be requested. 236 5. IANA Considerations 238 IANA has assigned the value of TBD for the VPN Identifier sub-option 239 from the DHCP Relay Agent Sub-options space [RFC 3046] for the VPN 240 Identifier sub-option defined in Section 3. 242 This document defines a number space for the type byte of the vpn-id 243 sub-option. Certain allowable values for this byte are defined in 244 this specification (see Section 3). New values may only be defined 245 by IETF Consensus, as described in [RFC 2434]. Basically, this means 246 that they are defined by RFCs approved by the IESG. 248 Moreover, any changes or additions to the type byte codes MUST be 249 made concurrently in the type byte codes of the vpn-id option. The 250 type bytes and data formats of the vpn-id option and vpn-id sub- 251 option MUST always be identical. 253 6. Acknowledgments 255 None (yet). 257 7. References 259 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", RFC 2119, March 1997. 262 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 263 2131, March 1997. 265 [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 266 Extensions", Internet RFC 2132, March 1997. 268 [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks Identif- 269 ier", Internet RFC 2685, September 1999. 271 [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 272 3046, January 2001. 274 [RFC 3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, 275 June 2001. 277 8. Author's information 279 Kim Kinnear 280 Mark Stapp 281 Cisco Systems 282 250 Apollo Drive 283 Chelmsford, MA 01824 285 Phone: (978) 497-8000 287 EMail: kkinnear@cisco.com 288 mjs@cisco.com 290 Jay Kumarasamy 291 Richard Johnson 292 Cisco Systems 293 170 W. Tasman Dr. 294 San Jose, CA 95134 296 Phone: (408) 526-4000 298 EMail: jayk@cisco.com 299 raj@cisco.com 301 9. Intellectual Property Statement 303 The IETF takes no position regarding the validity or scope of any intel- 304 lectual property or other rights that might be claimed to pertain to 305 the implementation or use of the technology described in this document 306 or the extent to which any license under such rights might or might not 307 be available; neither does it represent that it has made any effort to 308 identify any such rights. Information on the IETF's procedures with 309 respect to rights in standards-track and standards-related documentation 310 can be found in BCP-11. Copies of claims of rights made available for 311 publication and any assurances of licenses to be made available, or the 312 result of an attempt made to obtain a general license or permission for 313 the use of such proprietary rights by implementors or users of this 314 specification can be obtained from the IETF Secretariat. 316 The IETF invites any interested party to bring to its attention any 317 copyrights, patents or patent applications, or other proprietary rights 318 which may cover technology that may be required to practice this stan- 319 dard. Please address the information to the IETF Executive Director. 321 10. Full Copyright Statement 323 Copyright (C) The Internet Society (2002). All Rights Reserved. 325 This document and translations of it may be copied and furnished to oth- 326 ers, and derivative works that comment on or otherwise explain it or 327 assist in its implementation may be prepared, copied, published and dis- 328 tributed, in whole or in part, without restriction of any kind, provided 329 that the above copyright notice and this paragraph are included on all 330 such copies and derivative works. However, this document itself may not 331 be modified in any way, such as by removing the copyright notice or 332 references to the Internet Society or other Internet organizations, 333 except as needed for the purpose of developing Internet standards in 334 which case the procedures for copyrights defined in the Internet Stan- 335 dards process must be followed, or as required to translate it into 336 languages other than English. 338 The limited permissions granted above are perpetual and will not be 339 revoked by the Internet Society or its successors or assigns. 341 This document and the information contained herein is provided on an "AS 342 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 343 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 344 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 345 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- 346 NESS FOR A PARTICULAR PURPOSE.