idnits 2.17.1 draft-ietf-dhc-vpn-option-01.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == 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. ** The abstract seems to contain references ([RFC2434], [RFC2131], [RFC2685]), 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: administratively configured to ignore the option MUST ignore the option, use their normal algorithms to allocate an address, and MUST NOT return this option in the DHCPOFFER or DHCPACK. In this case the client will discard the DHCPOFFER or DHCPACK. In other words, this option MUST not appear in a DHCPOFFER from a server unless it was used by the server in making the address allocation requested. -- 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 (November 2001) is 8195 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 2685' is mentioned on line 106, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 186, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC2119' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 211, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Request for Comments: DRAFT Richard Johnson 3 Kim Kinnear 4 Mark Stapp 5 Jay Kumarasamy 6 Cisco Systems, Inc. 8 November 2001 9 Expires May 2001 11 DHCP VPN Information option 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 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 To learn the current status of any Internet-Draft, please check the 36 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 37 Directories on ds.internic.net (US East Coast), nic.nordu.net 38 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 39 Rim). 41 Copyright Notice 43 Copyright (C) The Internet Society (2000). All Rights Reserved. 45 DRAFT DHCP VPN Information option November 2001 47 Abstract 49 This memo defines a new DHCP option for passing VPN information 50 between the DHCP client and the DHCP server. It is intended for use 51 primarily by DHCP proxy clients in situations where VPN information 52 needs to be passed to the DHCP server for proper address allocation 53 to take place. 55 Introduction 57 There is a growing use of Virtual Private Network (VPN) 58 configurations. The growth comes from many areas; individual client 59 systems needing to appear to be on the home corporate network even 60 when traveling, ISPs providing extranet connectivity for customer 61 companies, etc. In some of these cases there is a need for the DHCP 62 client to communicate to the DHCP server the VPN from which an 63 address, and other resources, should be allocated. Currently there 64 is no way to pass this information. 66 This option would most likely not be used by an actual DHCP end-user 67 client such as a workstation or laptop. It is primarily intended to 68 be used by a DHCP proxy client which would be using DHCP in order to 69 allocate an IP address on behalf of some other protocol or client. 71 This memo defines a new DHCP option, the VPN Information option, 72 which allows the DHCP client to specify the VPN Information needed in 73 order to allocate an address. If the receiving DHCP server 74 understands the VPN Information option, this information may be used 75 in conjunction with other information in determining the subnet on 76 which to select an address as well as other information such as DNS 77 server, default router, etc. 79 VPN Information Option Definition 81 The VPN Information option is a DHCP option. The option contains 82 generalized VPN information in one of two formats: NVT ASCII VPN 83 identifier, or RFC2685 VPN-ID. 85 The format of the option is: 87 Code Len Type VPN Information octets 88 +-----+-----+------+-----+-----+-----+--- 89 | TBD | n | t | v1 | v2 | v3 | ... 90 +-----+-----+------+-----+-----+-----+--- 92 Type: 0 NVT ASCII VPN identifier 93 1 RFC2685 VPN-ID 94 2-255 Not Allowed 96 DRAFT DHCP VPN Information option November 2001 98 The option minimum length (n) is 2. 100 There are two types of identifiers which can be placed in the VPN 101 Information Suboption. The first type of identifier which can be 102 placed in the VPN Information Suboption is an NVT ASCII string. It 103 MUST NOT be terminated with a zero byte. 105 The second type of identifier which can be placed in the VPN 106 Information Suboption is an RFC2685 VPN-ID [RFC 2685], which is 107 typically 14 hex digits in length (though it can be any length as far 108 as the VPN Information Suboption is concerned). 110 If the type field is set to zero (0), it indicates that all following 111 bytes of the option contain a NVT ASCII string. This string MUST NOT 112 be terminated with a zero byte. 114 If the type field is set to one (1), it indicates that all following 115 bytes should be interpreted in agreement with [RFC2685] as a VPN 116 Identifier, typically 14 hex digits. 118 All other values of the type field are invalid as of this memo and 119 VPN options containing any other value than zero (0) or one (1) 120 SHOULD be ignored. 122 Any VPN information contained in a DHCP Relay suboption SHOULD 123 override the information contained in this VPN Information option. 125 Servers configured to support this option MUST return an identical 126 copy of the option to any client that sends it, regardless of whether 127 or not the client requests the option in a parameter request list. 128 Clients using this option MUST discard DHCPOFFER or DHCPACK packets 129 that do not contain this option. 131 This option provides the DHCP server additional information upon 132 which to make a determination of address to be assigned. The DHCP 133 server, if it is configure to support this option, should use this 134 information in addition to other options included in the DHCPDISCOVER 135 packet in order to assign an IP address for DHCP client. 137 In the event that a VPN Informmation Option and a VPN Information 138 Relay Suboption are both received in a particular DHCP client packet, 139 the information from the VPN Information Suboption MUST be used in 140 preference to the information in the VPN Information Option. 142 Servers that do not understand this option will allocate an address 143 using their normal algorithms and will not return this option in the 144 DHCPOFFER or DHCPACK. In this case the client will discard the 145 DHCPOFFER or DHCPACK. Servers that understand this option but are 147 DRAFT DHCP VPN Information option November 2001 149 administratively configured to ignore the option MUST ignore the 150 option, use their normal algorithms to allocate an address, and MUST 151 NOT return this option in the DHCPOFFER or DHCPACK. In this case the 152 client will discard the DHCPOFFER or DHCPACK. In other words, this 153 option MUST not appear in a DHCPOFFER from a server unless it was 154 used by the server in making the address allocation requested. 156 Security Considerations 158 DHCP currently provides no authentication or security mechanisms. 159 Potential exposures to attack are discussed is section 7 of the 160 protocol specification [RFC2131]. 162 The VPN Information option could be used by a client in order to 163 obtain an IP address from a VPN other than the one where it should. 164 DHCP relays MAY choose to remove the option before passing on 165 DHCPDISCOVER packets. Another possible defense would be for the DHCP 166 relay to insert a Relay option containing a VPN Information 167 Suboption, which would override the DHCP VPN Information option. 169 This option would allow a client to perform a more complete address- 170 pool exhaustion attack since the client would no longer be restricted 171 to attacking address-pools on just its local subnet. 173 Servers that implement the VPN Information option MUST by default 174 disable use of the feature; it must specifically be enabled through 175 configuration. Moreover, a server SHOULD provide the ability to 176 selectively enable use of the feature under restricted conditions, 177 e.g., by enabling use of the option only from explicitly configured 178 client-ids, enabling its use only by clients on a particular subnet, 179 or restricting the VPNs from which addresses may be requested. 181 IANA Considerations 183 IANA has assigned a value of TBD for the DHCP option code described 184 in this document. No assignment of values for the type field need be 185 made at this time. New values may only be defined by IETF Consensus, 186 as described in [RFC 2434]. Basically, this means that they are 187 defined by RFCs approved by the IESG. 189 Moreover, any changes or additions to the type byte codes MUST be 190 made concurrently in the type byte codes of the VPN Information 191 Option. The type bytes and data formats of the VPN Information 192 Option and VPN Information Suboption MUST always be identical. 194 DRAFT DHCP VPN Information option November 2001 196 Acknowledgements 198 This document is the result of work done within Cisco Systems. 199 Thanks to Kim Kinnear, Mark Stapp, and Jay Kumarasamy for their work 200 on this option definition and the other related work for which this 201 is necessary. 203 References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", RFC 2119, BCP 14, March 1997. 208 [RFC2131] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 209 March 1997. 211 [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 212 Extensions", RFC 2132, March 1997. 214 [RFC2685] Fox, B. and Gleeson, B., "Virtual Private Networks 215 Identifier", RFC 2685, September 1999 217 Author Information: 219 Richard Johnson 220 Jay Kumarasamy 221 Cisco Systems 222 170 W. Tasman Dr. 223 San Jose, CA 95134 225 Phone: (408) 526-4000 227 EMail: jayk@cisco.com 228 raj@cisco.com 230 Kim Kinnear 231 Mark Stapp 232 Cisco Systems 233 250 Apollo Drive 234 Chelmsford, MA 01824 236 Phone: (978) 244-8000 238 EMail: kkinnear@cisco.com 239 mjs@cisco.com 241 DRAFT DHCP VPN Information option November 2001