idnits 2.17.1 draft-ietf-dhc-vpn-option-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 221. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 213), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** 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. ** 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. ** 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 -- 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 (September 27, 2004) is 7150 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 225, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Richard Johnson 3 Internet Draft Kim Kinnear 4 Expiration: March 2005 Mark Stapp 5 File: draft-ietf-dhc-vpn-option-03.txt Jay Kumarasamy 6 Cisco Systems, Inc. 8 DHCP VPN Information option 9 11 September 27, 2004 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 or will be disclosed, and any of which I become aware will be 18 disclosed, in accordance with RFC 3668. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 This memo defines a new DHCP option for passing VPN information 46 between the DHCP client and the DHCP server. It is intended for use 47 primarily by DHCP proxy clients in situations where VPN information 48 needs to be passed to the DHCP server for proper address allocation 49 to take place. 51 1.0 Introduction 53 There is a growing use of Virtual Private Network (VPN) 54 configurations. The growth comes from many areas; individual client 55 systems needing to appear to be on the home corporate network even 56 when traveling, ISPs providing extranet connectivity for customer 57 companies, etc. In some of these cases there is a need for the DHCP 58 server to know the VPN from which an address, and other resources, 59 should be allocated. 61 If the allocation is being done through a DHCP relay, then a relay 62 suboption could be included. In some cases, however an IP address is 63 being sought by a DHCP proxy on behalf of a client (would may be 64 assigned the address via a different protocol). In this case, there 65 is a need to include VPN information relating to the client as a DHCP 66 option. 68 A good example might be a dial-in aggregation device where PPP 69 addresses are acquired via DHCP and then given to the remove customer 70 system via IPCP. In a network where such a device is used to 71 aggregate PPP dial-in from multiple companies, each company may be 72 assigned a unique VPN. 74 This memo defines a new DHCP [2] option, the VPN Information option, 75 which allows the DHCP client to specify the VPN Information needed in 76 order to allocate an address. If the receiving DHCP server 77 understands the VPN Information option, this information may be used 78 in conjunction with other information in determining the subnet on 79 which to select an address as well as other information such as DNS 80 server, default router, etc. 82 1.1 Conventions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC-2119 [3]. 88 2.0 VPN Information Option Definition 90 The VPN Information option is a DHCP option [3]. The option contains 91 generalized VPN information in one of two formats: NVT ASCII VPN 92 identifier, or RFC2685 VPN-ID [4]. 94 The format of the option is: 96 Code Len Type VPN Information octets 97 +-----+-----+------+-----+-----+-----+--- 98 | TBD | n | t | v1 | v2 | v3 | ... 99 +-----+-----+------+-----+-----+-----+--- 101 Type: 0 NVT ASCII VPN identifier 102 1 RFC2685 VPN-ID 103 2-255 Not Allowed 105 The option minimum length (n) is 2. 107 There are two types of identifiers which can be placed in the VPN 108 Information Option. The first type of identifier which can be placed 109 in the VPN Information Option is an NVT ASCII string. It MUST NOT be 110 terminated with a zero byte. 112 The second type of identifier which can be placed in the VPN 113 Information Option is an RFC2685 VPN-ID [4], which is typically 14 114 hex digits in length (though it can be any length as far as the VPN 115 Information Option is concerned). 117 If the type field is set to zero (0), it indicates that all following 118 bytes of the option contain a NVT ASCII string. This string MUST NOT 119 be terminated with a zero byte. 121 If the type field is set to one (1), it indicates that all following 122 bytes should be interpreted in agreement with [4] as a VPN 123 Identifier, typically 14 hex digits. 125 All other values of the type field are invalid as of this memo and 126 VPN options containing any other value than zero (0) or one (1) 127 SHOULD be ignored. 129 Any VPN information contained in a DHCP Relay Suboption SHOULD 130 override the information contained in this VPN Information option. 132 Servers configured to support this option MUST return an identical 133 copy of the option to any client that sends it, regardless of whether 134 or not the client requests the option in a parameter request list. 135 Clients using this option MUST discard DHCPOFFER or DHCPACK packets 136 that do not contain this option. 138 This option provides the DHCP server additional information upon 139 which to make a determination of address to be assigned. The DHCP 140 server, if it is configure to support this option, should use this 141 information in addition to other options included in the DHCPDISCOVER 142 packet in order to assign an IP address for DHCP client. 144 In the event that a VPN Informmation Option and a VPN Information 145 Relay Suboption are both received in a particular DHCP client packet, 146 the information from the VPN Information Suboption MUST be used in 147 preference to the information in the VPN Information Option. 149 Servers that do not understand this option will allocate an address 150 using their normal algorithms and will not return this option in the 151 DHCPOFFER or DHCPACK. In this case the client will discard the 152 DHCPOFFER or DHCPACK. Servers that understand this option but are 153 administratively configured to ignore the option MUST ignore the 154 option, use their normal algorithms to allocate an address, and MUST 155 NOT return this option in the DHCPOFFER or DHCPACK. In this case the 156 client will discard the DHCPOFFER or DHCPACK. In other words, this 157 option MUST NOT appear in a DHCPOFFER from a server unless it was 158 used by the server in making the address allocation requested. 160 This option SHOULD NOT be used without also making use of the DHCP 161 Authentication option [5]. 163 3.0 Security Considerations 165 Message authentication in DHCP for intradomain use where the out-of- 166 band exchange of a shared secret is feasible is defined in [5]. 167 Potential exposures to attack are discussed in section 7 of the DHCP 168 protocol specification in [2]. 170 The VPN Information option could be used by a client in order to 171 obtain an IP address from a VPN other than the one where it should. 172 DHCP relays MAY choose to remove the option before passing on 173 DHCPDISCOVER packets. Another possible defense would be for the DHCP 174 relay to insert a Relay option containing a VPN Information 175 Suboption, which would override the DHCP VPN Information option. 177 This option would allow a client to perform a more complete address- 178 pool exhaustion attack since the client would no longer be restricted 179 to attacking address-pools on just its local subnet. 181 Servers that implement the VPN Information option MUST by default 182 disable use of the feature; it must specifically be enabled through 183 configuration. Moreover, a server SHOULD provide the ability to 184 selectively enable use of the feature under restricted conditions, 185 e.g., by enabling use of the option only from explicitly configured 186 client-ids, enabling its use only by clients on a particular subnet, 187 or restricting the VPNs from which addresses may be requested. 189 4.0 IANA Considerations 191 IANA has assigned a value of TBD for the DHCP option code described 192 in this document. No assignment of values for the type field need be 193 made at this time. New values may only be defined by IETF Consensus, 194 as described in [6]. Basically, this means that they are defined by 195 RFCs approved by the IESG. 197 Moreover, any changes or additions to the type byte codes MUST be 198 made concurrently in the type byte codes of the VPN Information 199 Option. The type bytes and data formats of the VPN Information 200 Option and VPN Information Suboption MUST always be identical. 202 5.0 Acknowledgements 204 This document is the result of work done within Cisco Systems. 205 Thanks to Kim Kinnear, Mark Stapp, and Jay Kumarasamy for their work 206 on this option definition and the other related work for which this 207 is necessary. 209 Copyright notice 211 Copyright (C) The Internet Society (2004). This document is subject 212 to the rights, licenses and restrictions contained in BCP 78, and 213 except as set forth therein, the authors retain all their rights. 215 This document and the information contained herein are provided on an 216 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 217 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 218 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 219 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 220 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 221 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 223 References 225 [1] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", RFC 2119, BCP 14, March 1997. 228 [2] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 229 March 1997. 231 [3] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 232 Extensions", RFC 2132, March 1997. 234 [4] Fox, B. and Gleeson, B., "Virtual Private Networks 235 Identifier", RFC 2685, September 1999 237 [5] Droms, R. "Authentication for DHCP Messages", RFC 3118, 238 June 2001 240 [6] Narten, T. and Alvestrand, H., 241 "Guidelines for Writing an IANA Considerations Section in RFCs", 242 RFC 2434, October 1998 244 Author Information: 246 Richard Johnson 247 Jay Kumarasamy 248 Cisco Systems 249 170 W. Tasman Dr. 250 San Jose, CA 95134 252 Phone: (408) 526-4000 254 EMail: jayk@cisco.com 255 raj@cisco.com 257 Kim Kinnear 258 Mark Stapp 259 Cisco Systems 260 250 Apollo Drive 261 Chelmsford, MA 01824 263 Phone: (978) 244-8000 265 EMail: kkinnear@cisco.com 266 mjs@cisco.com