idnits 2.17.1 draft-ietf-dhc-subscriber-id-07.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 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 285. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 306), 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 (September 3, 2004) is 7168 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 information found for draft-ietf-dhc-auth-suboption- - is the name correct? -- No information found for draft-ietf-dhc-relay-agent-ipsec- - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group R. Johnson 2 Internet-Draft T. Palaniappan 3 Expires: March 4, 2005 M. Stapp 4 Cisco Systems, Inc. 5 September 3, 2004 7 Subscriber-ID 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 March 4, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This memo defines a new Subscriber-ID suboption for the Dynamic Host 41 Configuration Protocol's (DHCP) relay agent information option. The 42 suboption allows a DHCP relay agent to associate a stable 43 "Subscriber-ID" with DHCP client messages in a way that is 44 independent of the client and of the underlying physical network 45 infrastructure. 47 Table of Contents 49 1. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. The Subscriber-ID Suboption . . . . . . . . . . . . . . . . . 3 52 3.1 Suboption Format . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 4 54 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 58 Normative References . . . . . . . . . . . . . . . . . . . . . 7 59 Informative References . . . . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . 9 63 1. Requirements Terminology 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [1]. 69 2. Introduction 71 DHCP (RFC 2131 [2]) provides IP addresses and configuration 72 information for IPv4 clients. It includes a relay agent capability, 73 in which processes within the network infrastructure receive 74 broadcast messages from clients and forward them to DHCP servers as 75 unicast messages. In network environments like DOCSIS data-over-cable 76 and xDSL, for example, it has proven useful for the relay agent to 77 add information to the DHCP message before forwarding it, using the 78 relay agent information option (RFC 3046 [3]). 80 Servers that recognize the relay agent option echo it back in their 81 replies, and some of the information that relays add may be used to 82 help an edge device efficiently return replies to clients. The 83 information that relays supply can also be used in the server's 84 decision making about the addresses and configuration parameters that 85 the client should receive. 87 In many service provider environments it's desirable to associate 88 some provider-specific information with clients' DHCP messages. This 89 is often done using the relay agent information option. RFC 3046 90 defines Remote-ID and Circuit-ID sub-options that are used to carry 91 such information. The values of those suboptions, however, are 92 usually based on some network resource, such as an IP address of a 93 network access device, an ATM Virtual Circuit identifier, or a DOCSIS 94 cable-modem identifier. As a result, the values carried in these 95 suboptions are dependent on the physical network configuration. If a 96 client connects to the service provider network through different 97 paths, different values are carried in network-dependent suboptions. 99 3. The Subscriber-ID Suboption 101 In complex service provider environments, there is a need to connect 102 a customer's DHCP configuration with the customer's administrative 103 information. The Subscriber-ID suboption carries a value that can be 104 independent of the physical network configuration through which the 105 subscriber is connected. This value complements, and might well be 106 used in addition to, the network-based relay agent option suboptions 107 discussed in Section 2. The "subscriber-id" assigned by the provider 108 is intended to be stable as customers connect through different 109 paths, and as network changes occur. 111 The Subscriber-ID information allows the service provider to assign/ 112 activate subscriber-specific actions, e.g. assignment of host IP 113 address and subnet mask, DNS configuration, trigger accounting, etc. 114 This suboption is de-coupled from the access network's physical 115 structure, so subscriber moves from one access-point to another, for 116 example, would not require reconfiguration at the service provider's 117 DHCP servers. 119 The Subscriber-ID is an ASCII string; the encoding of the string is 120 defined in Section 3.1. The semantic contents of the Subscriber-ID 121 string are of course provider-specific. This specification does not 122 establish any semantic requirements on the data in the string. 124 3.1 Suboption Format 126 This memo defines a new DHCP relay agent option suboption that 127 carries a "Subscriber-ID" value. The value is an ASCII string. The 128 suboption takes a form similar to many other relay information option 129 suboptions: 131 0 1 2 3 4 5 132 +-----+-----+-----+-----+-----+----+-- 133 |Code | Len | Subscriber-ID string ... 134 +-----+-----+-----+-----+-----+----+-- 136 The Code for the suboption is TBD. 138 The one-octet Len field is the length of the ID string, in octets. 139 The minimum length of the ID string is 1 octet. 141 The "Subscriber-ID" is an NVT ASCII [4] string. The string MUST NOT 142 be NULL terminated since the length is specified in the "Len" field. 144 4. Relay Agent Behavior 146 DHCP relay agents MAY be configured to include a Subscriber-ID 147 suboption if they include a relay agent information option in relayed 148 DHCP messages. The subscriber-id strings themselves are assigned and 149 configured through mechanisms that are outside the scope of this 150 memo. 152 5. DHCP Server Behavior 154 This suboption provides additional information to the DHCP server. 155 The DHCP server, if it is configured to support this option, may use 156 this information in addition to other relay agent option data and 157 other options included in the DHCP client messages in order to assign 158 an IP address and/or other configuration parameters to the client. 159 There is no special additional processing for this suboption. 161 6. Security Considerations 163 Message authentication in DHCP for intradomain use where the 164 out-of-band exchange of a shared secret is feasible is defined in RFC 165 3118 [5]. Potential exposures to attack are discussed in section 7 of 166 the DHCP protocol specification in RFC 2131 [2]. 168 The DHCP relay agent option depends on a trusted relationship between 169 the DHCP relay agent and the server, as described in section 5 of RFC 170 3046. Fraudulent relay agent option data could potentially lead to 171 theft-of-service or exhaustion of limited resources (like IP 172 addresses) by unauthorized clients. A host that tampered with relay 173 agent data associated with another host's DHCP messages could deny 174 service to that host, or interfere with its operation by leading the 175 DHCP server to assign it inappropriate configuration parameters. 177 While the introduction of fraudulent relay agent options can be 178 prevented by a perimeter defense that blocks these options unless the 179 relay agent is trusted, a deeper defense using authentication for 180 relay agent options via the Authentication Suboption [6] or IPSec [7] 181 SHOULD be deployed as well. 183 There are several data in a DHCP message that convey information that 184 may identify an individual host on the network. These include the 185 chaddr, the client-id option, and the hostname and client-fqdn 186 options. Depending on the type of identifier selected, the 187 Subscriber-ID suboption may also convey information that identifies a 188 specific host or a specific user on the network. In practice, this 189 information isn't exposed outside the internal service-provider 190 network, where DHCP messages are usually confined. Administrators who 191 configure data that's going to be used in DHCP Subscriber-ID 192 suboptions should be careful to use identifiers that are appropriate 193 for the types of networks they administer. If DHCP messages travel 194 outside the service-provider's own network, or if the suboption 195 values may become visible to other users, that may raise privacy 196 concerns for the access provider or service provider. 198 7. IANA Considerations 200 IANA has assigned a value of from the DHCP Relay Agent 201 Information Option [3] suboption codes for the Subscriber-ID 202 Suboption described in this document. 204 8. Acknowledgements 206 This document is the result of work done within Cisco Systems. Thanks 207 especially to Andy Sudduth for his review comments. 209 Normative References 211 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 212 Levels", RFC 2119, March 1997. 214 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 215 March 1997. 217 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 218 January 2001. 220 [4] Postel, J. and J. Reynolds, "TELNET Protocol Specification", RFC 221 854, May 1983. 223 Informative References 225 [5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 226 RFC 3118, June 2001. 228 [6] Stapp, M., "The Authentication Suboption for the DHCP Relay 229 Agent Option (draft-ietf-dhc-auth-suboption-*.txt)", August 230 2004. 232 [7] Droms, R., "Authentication of Relay Agent Options Using IPSec 233 (draft-ietf-dhc-relay-agent-ipsec-*.txt)", November 2003. 235 Authors' Addresses 237 Richard Johnson 238 Cisco Systems, Inc. 239 170 W. Tasman Dr. 240 San Jose, CA 95134 241 USA 243 Phone: 408.526.4000 244 EMail: raj@cisco.com 246 Theyn Palaniappan 247 Cisco Systems, Inc. 248 170 W. Tasman Dr. 249 San Jose, CA 95134 250 USA 252 Phone: 408.526.4000 253 EMail: athenmoz@cisco.com 254 Mark Stapp 255 Cisco Systems, Inc. 256 1414 Massachusetts Ave. 257 Boxborough, MA 01719 258 USA 260 Phone: 978.936.0000 261 EMail: mjs@cisco.com 263 Intellectual Property Statement 265 The IETF takes no position regarding the validity or scope of any 266 Intellectual Property Rights or other rights that might be claimed to 267 pertain to the implementation or use of the technology described in 268 this document or the extent to which any license under such rights 269 might or might not be available; nor does it represent that it has 270 made any independent effort to identify any such rights. Information 271 on the IETF's procedures with respect to rights in IETF Documents can 272 be found in BCP 78 and BCP 79. 274 Copies of IPR disclosures made to the IETF Secretariat and any 275 assurances of licenses to be made available, or the result of an 276 attempt made to obtain a general license or permission for the use of 277 such proprietary rights by implementers or users of this 278 specification can be obtained from the IETF on-line IPR repository at 279 http://www.ietf.org/ipr. 281 The IETF invites any interested party to bring to its attention any 282 copyrights, patents or patent applications, or other proprietary 283 rights that may cover technology that may be required to implement 284 this standard. Please address the information to the IETF at 285 ietf-ipr@ietf.org. 287 The IETF has been notified of intellectual property rights claimed in 288 regard to some or all of the specification contained in this 289 document. For more information consult the online list of claimed 290 rights. 292 Disclaimer of Validity 294 This document and the information contained herein are provided on an 295 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 296 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 297 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 298 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 299 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 302 Copyright Statement 304 Copyright (C) The Internet Society (2004). This document is subject 305 to the rights, licenses and restrictions contained in BCP 78, and 306 except as set forth therein, the authors retain all their rights. 308 Acknowledgment 310 Funding for the RFC Editor function is currently provided by the 311 Internet Society.