idnits 2.17.1 draft-ietf-dhc-subscriber-id-06.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 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 281. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 302), 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 (April 7, 2004) is 7317 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: October 6, 2004 M. Stapp 4 Cisco Systems, Inc. 5 April 7, 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 October 6, 2004. 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 exact contents of the Subscriber-ID string are of course 120 provider-specific. This specification does not establish any 121 requirements on the content of the suboption. 123 3.1 Suboption Format 125 This memo defines a new DHCP relay agent option suboption that 126 carries a "Subscriber-ID" value. The value is an ASCII string. The 127 suboption takes a form similar to many other relay information option 128 suboptions: 130 0 1 2 3 4 5 131 +-----+-----+-----+-----+-----+----+-- 132 |Code | Len | Subscriber-ID string ... 133 +-----+-----+-----+-----+-----+----+-- 135 The Code for the suboption is TBD. 137 The one-byte Len field is the length of the ID string, in bytes. The 138 minimum length of the ID string is 1 byte. 140 The "Subscriber-ID" is an NVT ASCII string. The string MUST NOT be 141 NULL terminated since the length is specified in the "Len" field. 143 4. Relay Agent Behavior 145 DHCP relay agents MAY be configured to include a Subscriber-ID 146 suboption if they include a relay agent information option in relayed 147 DHCP messages. The subscriber-id strings themselves are assigned and 148 configured through mechanisms that are outside the scope of this 149 memo. 151 5. DHCP Server Behavior 153 This suboption provides additional information to the DHCP server. 154 The DHCP server, if it is configured to support this option, may use 155 this information in addition to other relay agent option data and 156 other options included in the DHCP client messages in order to assign 157 an IP address and/or other configuration parameters to the client. 158 There is no special additional processing for this suboption. 160 6. Security Considerations 162 Message authentication in DHCP for intradomain use where the 163 out-of-band exchange of a shared secret is feasible is defined in RFC 164 3118 [4]. Potential exposures to attack are discussed in section 7 of 165 the DHCP protocol specification in RFC 2131 [2]. 167 The DHCP relay agent option depends on a trusted relationship between 168 the DHCP relay agent and the server, as described in section 5 of RFC 169 3046. Fraudulent relay agent option data could potentially lead to 170 theft-of-service or exhaustion of limited resources (like IP 171 addresses) by unauthorized clients. A host that tampered with relay 172 agent data associated with another host's DHCP messages could deny 173 service to that host, or interfere with its operation by leading the 174 DHCP server to assign it inappropriate configuration parameters. 176 While the introduction of fraudulent relay agent options can be 177 prevented by a perimeter defense that blocks these options unless the 178 relay agent is trusted, a deeper defense using authentication for 179 relay agent options via the Authentication Suboption [5] or IPSEC [6] 180 SHOULD be deployed as well. 182 There are several data in a DHCP message that convey information that 183 may identify an individual host on the network. These include the 184 chaddr, the client-id option, and the hostname and client-fqdn 185 options. Depending on the type of identifier selected, the 186 Subscriber-ID suboption may also convey information that identifies a 187 specific host or a specific user on the network. In practice, this 188 information isn't exposed outside the internal service-provider 189 network, where DHCP messages are usually confined. Administrators who 190 configure data that's going to be used in DHCP Subscriber-ID 191 suboptions should be careful to use identifiers that are appropriate 192 for the types of networks they administer. If DHCP messages travel 193 outside the service-provider's own network, or if the suboption 194 values may become visible to other users, that may raise privacy 195 concerns for the access provider or service provider. 197 7. IANA Considerations 199 IANA has assigned a value of from the DHCP Relay Agent 200 Information Option [3] suboption codes for the Subscriber-ID 201 Suboption described in this document. 203 8. Acknowledgements 205 This document is the result of work done within Cisco Systems. Thanks 206 especially to Andy Sudduth for his review comments. 208 Normative References 210 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 211 Levels", RFC 2119, March 1997. 213 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 214 March 1997. 216 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 217 January 2001. 219 Informative References 221 [4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 222 RFC 3118, June 2001. 224 [5] Stapp, M., "The Authentication Suboption for the DHCP Relay 225 Agent Option (draft-ietf-dhc-auth-suboption-*.txt)", October 226 2003. 228 [6] Droms, R., "Authentication of Relay Agent Options Using IPSEC 229 (draft-ietf-dhc-relay-agent-ipsec-*.txt)", November 2003. 231 Authors' Addresses 233 Richard Johnson 234 Cisco Systems, Inc. 235 170 W. Tasman Dr. 236 San Jose, CA 95134 237 USA 239 Phone: 408.526.4000 240 EMail: raj@cisco.com 242 Theyn Palaniappan 243 Cisco Systems, Inc. 244 170 W. Tasman Dr. 245 San Jose, CA 95134 246 USA 248 Phone: 408.526.4000 249 EMail: athenmoz@cisco.com 250 Mark Stapp 251 Cisco Systems, Inc. 252 1414 Massachusetts Ave. 253 Boxborough, MA 01719 254 USA 256 Phone: 978.936.0000 257 EMail: mjs@cisco.com 259 Intellectual Property Statement 261 The IETF takes no position regarding the validity or scope of any 262 Intellectual Property Rights or other rights that might be claimed to 263 pertain to the implementation or use of the technology described in 264 this document or the extent to which any license under such rights 265 might or might not be available; nor does it represent that it has 266 made any independent effort to identify any such rights. Information 267 on the IETF's procedures with respect to rights in IETF Documents can 268 be found in BCP 78 and BCP 79. 270 Copies of IPR disclosures made to the IETF Secretariat and any 271 assurances of licenses to be made available, or the result of an 272 attempt made to obtain a general license or permission for the use of 273 such proprietary rights by implementers or users of this 274 specification can be obtained from the IETF on-line IPR repository at 275 http://www.ietf.org/ipr. 277 The IETF invites any interested party to bring to its attention any 278 copyrights, patents or patent applications, or other proprietary 279 rights that may cover technology that may be required to implement 280 this standard. Please address the information to the IETF at 281 ietf-ipr@ietf.org. 283 The IETF has been notified of intellectual property rights claimed in 284 regard to some or all of the specification contained in this 285 document. For more information consult the online list of claimed 286 rights. 288 Disclaimer of Validity 290 This document and the information contained herein are provided on an 291 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 292 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 293 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 294 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 295 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 296 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 298 Copyright Statement 300 Copyright (C) The Internet Society (2004). This document is subject 301 to the rights, licenses and restrictions contained in BCP 78, and 302 except as set forth therein, the authors retain all their rights. 304 Acknowledgment 306 Funding for the RFC Editor function is currently provided by the 307 Internet Society.