idnits 2.17.1 draft-stapp-dhc-vendor-suboption-01.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.5 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 299. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 315), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 8, 2004) is 7230 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) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-dhc-auth-suboption-04 == Outdated reference: A later version (-02) exists of draft-ietf-dhc-relay-agent-ipsec-01 == Outdated reference: A later version (-03) exists of draft-ietf-dhc-vendor-02 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group M. Stapp 2 Internet-Draft R. Johnson 3 Expires: January 6, 2005 T. Palaniappan 4 Cisco Systems, Inc. 5 July 8, 2004 7 Vendor-Specific Information Suboption for the DHCP Relay Agent Option 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3667. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 6, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This memo defines a new Vendor-Specific Information suboption for the 41 Dynamic Host Configuration Protocol's (DHCP) relay agent information 42 option. The suboption allows a DHCP relay agent to include 43 vendor-specific information in DHCP messages it forwards, as 44 configured by its administrator. 46 Table of Contents 48 1. Requirements Terminology . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. The Vendor-Specific Suboption . . . . . . . . . . . . . . . . . 3 51 4. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . . 4 52 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . . 5 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 55 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 56 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 57 Informative References . . . . . . . . . . . . . . . . . . . . . 7 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . . 9 61 1. Requirements Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [1]. 67 2. Introduction 69 DHCP (RFC 2131 [2]) provides IP addresses and configuration 70 information for IPv4 clients. It includes a relay agent capability, 71 in which processes within the network infrastructure receive 72 broadcast messages from clients and forward them to DHCP servers as 73 unicast messages. In network environments like DOCSIS data-over-cable 74 and xDSL, for example, it has proven useful for the relay agent to 75 add information to the DHCP message before forwarding it, using the 76 relay agent information option (RFC 3046 [3]). 78 Servers that recognize the relay agent option echo it back in their 79 replies, and some of the information that relays add may be used to 80 help an edge device efficiently return replies to clients. The 81 information that relays supply can also be used in the server's 82 decision making about the addresses and configuration parameters that 83 the client should receive. 85 In many environments it's desirable to associate some vendor- or 86 provider-specific information with clients' DHCP messages. This is 87 often done using the relay agent information option. RFC 3046 defines 88 Remote-ID and Circuit-ID sub-options that are used to carry such 89 information. The values of those suboptions, however, are usually 90 based on some network resource, such as an IP address of a network 91 access device, an ATM Virtual Circuit identifier, or a DOCSIS 92 cable-modem identifier. As a result, the values carried in these 93 suboptions are dependent on the physical network configuration. The 94 Vendor-Specific suboption allows administrators to associate other 95 useful data with relayed DHCP messages. 97 3. The Vendor-Specific Suboption 99 This memo defines a new DHCP relay agent option suboption that 100 carries vendor-defined data. The suboption takes a form similar to 101 the Vendor-Identifying Vendor-Specific Option [8]. 103 0 1 2 3 104 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Code | Length | Enterprise Number1 | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | DataLen1 | | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 110 \ Suboption Data1 \ 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Enterprise Number2 | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | DataLen2 | Suboption Data2 | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 \ \ 117 . . 118 . . 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 The Code for the suboption is (to be assigned by IANA). 123 The one-byte Length field is the length of the data carried in the 124 suboption, in bytes. The length includes the length of the first 125 Enterprise Number; the minimum length is 4 bytes. 127 "Enterprise NumberN" is a vendor's Enterprise Number as registered 128 with IANA [4]. It is a four-byte integer value in network byte-order. 130 DataLenN is the length of the data associated with the Enterprise 131 Number. 133 The Suboption Data is an opaque sequence of bytes. 135 The Vendor-Specific suboption includes at least one Enterprise Number 136 and carries opaque data defined by the organization identified by the 137 Enterprise Number. A relay may include data associated with more than 138 one vendor's Enterprise Number within a single instance of the 139 Suboption. 141 The Vendor-Specific data are of course provider-specific. This 142 specification does not establish any requirements on the data in the 143 suboption. Vendors who make use of this suboption are encouraged to 144 document their usage in order to make interoperability possible. 146 4. Relay Agent Behavior 148 DHCP relay agents MAY be configured to include Vendor-Specific 149 suboptions if they include a relay agent information option in 150 relayed DHCP messages. The suboptions' types and data are assigned 151 and configured through mechanisms that are outside the scope of this 152 memo. 154 Relay implementors are encouraged to offer their administrators some 155 means of configuring what data can be included in this suboption, and 156 to document what they are capable of. 158 5. DHCP Server Behavior 160 This suboption provides additional information to the DHCP server. 161 The DHCP server, if it is configured to support this suboption, may 162 use this information in addition to other relay agent option data and 163 other options included in the DHCP client messages in order to assign 164 an IP address and/or other configuration parameters to the client. 165 There is no special additional processing for this suboption. 167 DHCP server vendors are encouraged to offer their administrators some 168 means of configuring the use of data from incoming Vendor-Specific 169 suboptions in DHCP decision-making. 171 6. Security Considerations 173 Message authentication in DHCP for intradomain use where the 174 out-of-band exchange of a shared secret is feasible is defined in RFC 175 3118 [5]. Potential exposures to attack are discussed in section 7 of 176 the DHCP protocol specification in RFC 2131 [2]. 178 The DHCP relay agent option depends on a trusted relationship between 179 the DHCP relay agent and the server, as described in section 5 of RFC 180 3046. Fraudulent relay agent option data could potentially lead to 181 theft-of-service or exhaustion of limited resources (like IP 182 addresses) by unauthorized clients. A host that tampered with relay 183 agent data associated with another host's DHCP messages could deny 184 service to that host, or interfere with its operation by leading the 185 DHCP server to assign it inappropriate configuration parameters. 187 While the introduction of fraudulent relay agent options can be 188 prevented by a perimeter defense that blocks these options unless the 189 relay agent is trusted, a deeper defense using authentication for 190 relay agent options via the Authentication Suboption [6] or IPSEC [7] 191 SHOULD be deployed as well. 193 There are several data in a DHCP message that convey information that 194 may identify an individual host on the network. These include the 195 chaddr, the client-id option, and the hostname and client-fqdn 196 options. Depending on the type of data included, the Vendor-Specific 197 suboption may also convey information that identifies a specific host 198 or a specific user on the network. In practice, this information 199 isn't exposed outside the internal service-provider network, where 200 DHCP messages are usually confined. Administrators who configure data 201 that's going to be used in DHCP Vendor-Specific suboptions should be 202 careful to use data that are appropriate for the types of networks 203 they administer. If DHCP messages travel outside the 204 service-provider's own network, or if the suboption values may become 205 visible to other users, that may raise privacy concerns for the 206 access provider or service provider. 208 7. IANA Considerations 210 IANA is requested to assign a suboption number for the 211 Vendor-Specific Information Suboption from the DHCP Relay Agent 212 Information Option [3] suboption number space. 214 8. Acknowledgements 216 The authors are grateful to Andy Sudduth, Josh Littlefield, and Kim 217 Kinnear for their review and comments. 219 Normative References 221 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 222 Levels", RFC 2119, March 1997. 224 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 225 March 1997. 227 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 228 January 2001. 230 [4] IANA, "Private Enterprise Numbers (http://www.iana.org/ 231 assignments/enterprise-numbers.html)". 233 Informative References 235 [5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 236 RFC 3118, June 2001. 238 [6] Stapp, M., "The Authentication Suboption for the DHCP Relay 239 Agent Option", draft-ietf-dhc-auth-suboption-04.txt (work in 240 progress), October 2003. 242 [7] Droms, R., "Authentication of Relay Agent Options Using IPsec", 243 draft-ietf-dhc-relay-agent-ipsec-01.txt (work in progress), 244 November 2003. 246 [8] Littlefield, J., "Vendor-Identifying Vendor Options for DHCPv4", 247 draft-ietf-dhc-vendor-02.txt (work in progress), November 2004. 249 Authors' Addresses 251 Mark Stapp 252 Cisco Systems, Inc. 253 1414 Massachusetts Ave. 254 Boxborough, MA 01719 255 USA 257 Phone: 978.936.0000 258 EMail: mjs@cisco.com 259 Richard Johnson 260 Cisco Systems, Inc. 261 170 W. Tasman Dr. 262 San Jose, CA 95134 263 USA 265 Phone: 408.526.4000 266 EMail: raj@cisco.com 268 Theyn Palaniappan 269 Cisco Systems, Inc. 270 170 W. Tasman Dr. 271 San Jose, CA 95134 272 USA 274 Phone: 408.526.4000 275 EMail: athenmoz@cisco.com 277 Intellectual Property Statement 279 The IETF takes no position regarding the validity or scope of any 280 Intellectual Property Rights or other rights that might be claimed to 281 pertain to the implementation or use of the technology described in 282 this document or the extent to which any license under such rights 283 might or might not be available; nor does it represent that it has 284 made any independent effort to identify any such rights. Information 285 on the IETF's procedures with respect to rights in IETF Documents can 286 be found in BCP 78 and BCP 79. 288 Copies of IPR disclosures made to the IETF Secretariat and any 289 assurances of licenses to be made available, or the result of an 290 attempt made to obtain a general license or permission for the use of 291 such proprietary rights by implementers or users of this 292 specification can be obtained from the IETF on-line IPR repository at 293 http://www.ietf.org/ipr. 295 The IETF invites any interested party to bring to its attention any 296 copyrights, patents or patent applications, or other proprietary 297 rights that may cover technology that may be required to implement 298 this standard. Please address the information to the IETF at 299 ietf-ipr@ietf.org. 301 Disclaimer of Validity 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Copyright Statement 313 Copyright (C) The Internet Society (2004). This document is subject 314 to the rights, licenses and restrictions contained in BCP 78, and 315 except as set forth therein, the authors retain all their rights. 317 Acknowledgment 319 Funding for the RFC Editor function is currently provided by the 320 Internet Society.