idnits 2.17.1 draft-ietf-dhc-subscriber-id-05.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: ---------------------------------------------------------------------------- == 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 (January 15, 2004) is 7400 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group R. Johnson 3 Internet-Draft T. Palaniappan 4 Expires: July 15, 2004 M. Stapp 5 Cisco Systems, Inc. 6 January 15, 2004 8 Subscriber-ID Suboption for the DHCP Relay Agent Option 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any 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 27 http://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 July 15, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 58 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 61 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 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 76 data-over-cable and xDSL, for example, it has proven useful for the 77 relay agent to add information to the DHCP message before forwarding 78 it, using the 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 85 that 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 94 DOCSIS cable-modem identifier. As a result, the values carried in 95 these suboptions are dependent on the physical network 96 configuration. If a client connects to the service provider network 97 through different paths, different values are carried in 98 network-dependent suboptions. 100 3. The Subscriber-ID Suboption 102 In complex service provider environments, there is a need to connect 103 a customer's DHCP configuration with the customer's administrative 104 information. The Subscriber-ID suboption carries a value that can be 105 independent of the physical network configuration through which the 106 subscriber is connected. This value complements, and might well be 107 used in addition to, the network-based relay agent option suboptions 108 discussed in Section 2. The "subscriber-id" assigned by the provider 109 is intended to be stable as customers connect through different 110 paths, and as network changes occur. 112 The Subscriber-ID information allows the service provider to 113 assign/activate subscriber-specific actions, e.g. assignment of host 114 IP address and subnet mask, DNS configuration, trigger accounting, 115 etc. This suboption is de-coupled from the access network's physical 116 structure, so subscriber moves from one access-point to another, for 117 example, would not require reconfiguration at the service provider's 118 DHCP servers. 120 The exact contents of the Subscriber-ID string are of course 121 provider-specific. This specification does not establish any 122 requirements on the content of the suboption. 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 129 option 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-byte Len field is the length of the ID string, in bytes. The 139 minimum length of the ID string is 1 byte. 141 The "Subscriber-ID" is an NVT ASCII string. The string MUST NOT be 142 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 148 relayed DHCP messages. The subscriber-id strings themselves are 149 assigned and configured through mechanisms that are outside the 150 scope of this 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 158 assign an IP address and/or other configuration parameters to the 159 client. 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 165 RFC 3118[4]. Potential exposures to attack are discussed in section 166 7 of the DHCP protocol specification in RFC 2131[2]. 168 The DHCP relay agent option depends on a trusted relationship 169 between the DHCP relay agent and the server, as described in section 170 5 of RFC 3046. Fraudulent relay agent option data could potentially 171 lead to 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 179 the relay agent is trusted, a deeper defense using authentication 180 for relay agent options via the Authentication Suboption[5] or 181 IPSEC[6] SHOULD be deployed as well. 183 There are several data in a DHCP message that convey information 184 that may identify an individual host on the network. These include 185 the 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 188 a 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 191 who 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. 207 Thanks 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 Informative References 222 [4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 223 RFC 3118, June 2001. 225 [5] Stapp, M., "The Authentication Suboption for the DHCP Relay 226 Agent Option (draft-ietf-dhc-auth-suboption-*.txt)", October 227 2003. 229 [6] Droms, R., "Authentication of Relay Agent Options Using IPSEC 230 (draft-ietf-dhc-relay-agent-ipsec-*.txt)", November 2003. 232 Authors' Addresses 234 Richard Johnson 235 Cisco Systems, Inc. 236 170 W. Tasman Dr. 237 San Jose, CA 95134 238 USA 240 Phone: 408.526.4000 241 EMail: raj@cisco.com 243 Theyn Palaniappan 244 Cisco Systems, Inc. 245 170 W. Tasman Dr. 246 San Jose, CA 95134 247 USA 249 Phone: 408.526.4000 250 EMail: athenmoz@cisco.com 251 Mark Stapp 252 Cisco Systems, Inc. 253 1414 Massachusetts Ave. 254 Boxborough, MA 01719 255 USA 257 Phone: 978.936.1535 258 EMail: mjs@cisco.com 260 Full Copyright Statement 262 Copyright (C) The Internet Society (2004). All Rights Reserved. 264 This document and translations of it may be copied and furnished to 265 others, and derivative works that comment on or otherwise explain it 266 or assist in its implementation may be prepared, copied, published 267 and distributed, in whole or in part, without restriction of any 268 kind, provided that the above copyright notice and this paragraph 269 are included on all such copies and derivative works. However, this 270 document itself may not be modified in any way, such as by removing 271 the copyright notice or references to the Internet Society or other 272 Internet organizations, except as needed for the purpose of 273 developing Internet standards in which case the procedures for 274 copyrights defined in the Internet Standards process must be 275 followed, or as required to translate it into languages other than 276 English. 278 The limited permissions granted above are perpetual and will not be 279 revoked by the Internet Society or its successors or assigns. 281 This document and the information contained herein is provided on an 282 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 283 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 284 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 285 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 286 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Acknowledgement 290 Funding for the RFC editor function is currently provided by the 291 Internet Society.