idnits 2.17.1 draft-ietf-dhc-agent-options-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 244: '...elay Agent Information field SHALL add...' RFC 2119 keyword, line 252: '...dy present in the packet SHALL discard...' RFC 2119 keyword, line 255: '... Relay Agent Information option SHOULD...' RFC 2119 keyword, line 259: '... Relay agents SHOULD have a configur...' RFC 2119 keyword, line 263: '...mation option. An error counter SHOULD...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 'SHOULD not' in this paragraph: DHCP servers unaware of the Relay Agent Information option SHOULD ignore the option upon receive and SHOULD not echo it back on responses. This is the specified server behaviour for unknown options. -- 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 30, 1997) is 9765 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) == Unused Reference: '2' is defined on line 457, but no explicit reference was found in the text Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Grop Michael Patrick 2 Motorola ISG 3 July 30, 1997 5 DHCP Relay Agent Information Option 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a "working 18 draft" or "work in progress." 20 Please check the "1id-abstracts.txt" listing contained in the 21 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 22 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net 23 (US East Coast), or ftp.isi.edu (US West Coast). 25 Abstract 27 Newer high-speed public Internet access technologies call for a 28 high-speed modem to have a LAN attachment to one or more user hosts. 29 It is advantageous to use DHCP to assign user host IP addresses in 30 this environment, but a number of security and scaling problems arise 31 with such 'public' DHCP use. This draft calls for the definition of 32 a 'DHCP Relay Agent Information' option that is appended to a DHCP 33 packet forwarded from a client to a server by a relay agent. The 34 Server may or may not use the information in the the Relay Agent 35 Information option; in either case, it echoes back the option 36 verbatim in server-to-client replies. 38 The 'Relay Agent Information' option contains sub-options that convey 39 information known by the relay agent. The initial sub-options are 40 defined for a relay agent that is co-located in a public circuit 41 access unit. These include a 'circuit ID' for the incoming circuit 42 and a 'remote ID' which provides a trusted identifier for the remote 43 high-speed modem. 45 February 11, 1997 47 Table of Contents 49 1 Introduction........................................... 2 50 1.1 High-Speed Circuit Switched Data Networks.............. 2 51 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4 52 2.0 Relay Agent Information Option......................... 5 53 2.1 Agent Operation........................................ 6 54 2.2 Server Operation....................................... 7 55 3.0 Relay Agent Information Suboptions..................... 8 56 3.1 Agent Circuit ID....................................... 8 57 3.2 Agent Remote ID........................................ 9 58 4.0 Issues Resolved........................................ 9 59 5.0 Security Considerations................................ 10 60 6.0 References............................................. 11 61 7.0 Glossary............................................... 11 62 8.0 Author's Address....................................... 11 64 Revision History 66 Rev Date Description 67 --- -------- ----------- 68 -02 07/30/97 Add Security Considerations 69 -01 06/06/97 Updated per March 97 IETF review: 70 Organize as one DHCP option with sub-options. 71 Clarify operation when option already present. 72 Move Agent Subnet Mask option to separate 73 document. 74 -00 12/11/96 Original 76 1 Introduction 78 1.1 High-Speed Circuit Switched Data Networks 80 Public Access to the Internet is usually via a circuit switched data 81 network. Today, this is primarily implemented with dial-up modems 82 connecting to a Remote Access Server. But higher speed circuit 83 access networks also include ISDN, ATM, Frame Relay, and Cable Data 84 Networks. All of these networks can be characterized as a "star" 85 topology where multiple users connect to a "circuit access unit" via 86 switched or permanent circuits. 88 With dial-up modems, only a single host PC attempts to connect to the 90 February 11, 1997 92 central point. The PPP protocol is widely used to assign IP 93 addresses to be used by the single host PC. 95 The newer high-speed circuit technologies, however, frequently 96 provide a LAN interface (especially Ethernet) to one or more host 97 PCs. It is desirable to support centralized assignment of the IP 98 addresses of host computers connecting on such circuits via DHCP. 99 The DHCP server can be, but usually is not, co-implemented with the 100 centralized circuit concentration access device. The DHCP server is 101 often connected as a separate server on the "Central LAN" to which 102 the central access device (or devices) attach. 104 A common physical model for high-speed Internet circuit access is 105 shown in Figure 1, below. 107 +---------------+ | 108 Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A 109 LAN | | Access | Lan |- Host B 110 | | Unit 1 | |- Host C 111 |-----| |-- | 112 | |(relay agent) |... 113 +---------+ | +---------------+ 114 | DHCP |--| 115 | Server | | 116 +---------+ | 117 | 118 | +---------------+ 119 +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D 120 | Other | | | Access | Lan 121 | Servers |--|-----| Unit 2 | 122 | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E 123 | DNS) | | |(relay agent) |... Lan 124 | | +---------------+ 125 +---------+ 126 Figure 1: DHCP High Speed Circuit Access Model 128 Note that in this model, the "modem" connects to a LAN at the user 129 site, rather than to a single host. Multiple hosts are implemented at 130 this site. Although it is certainly possible to implement a full IP 131 router at the user site, this requires a relatively expensive piece 132 of equipment (compared to typical modem costs). Furthermore, a 133 router requires an IP address not only for every host, but for the 134 router itself. Finally, a user-side router requires a dedicated 135 Logical IP Subnet (LIS) for each user. While this model is 137 February 11, 1997 139 appropriate for relatively small corporate networking environments, 140 it is not appropriate for large, public accessed networks. In this 141 scenario, it is advantageous to implement an IP networking model that 142 does not allocate an IP address for the modem (or other networking 143 equipment device at the user site), and especially not an entire LIS 144 for the user side LAN. 146 1.2 DHCP Relay Agent in the Circuit Access Unit 148 It is desirable to use DHCP to assign the IP addresses for public 149 high-speed circuit access. A number of circuit access units (e.g. 150 RAS's, cable modem termination systems, ADSL access units, etc) 151 connect to a LAN (or local internet) to which is attached a DHCP 152 server. 154 For scaling and security reasons, it is advantageous to implement a 155 "router hop" at the circuit access unit, much like high-capacity 156 RAS's do today. The circuit access equipment acts as both a router 157 to the circuits and as the DHCP relay agent. 159 The advantages of co-locating the DHCP relay agent with the circuit 160 access equipment are: 162 DHCP broadcast replies can be routed to only the proper circuit, 163 avoiding, say, the replication of the DCHP reply broadcast onto 164 thousands of access circuits; 166 The same mechanism used to identify the remote connection of the 167 circuit (e.g. a user ID requested by a Remote Access Server acting as 168 the circuit access equipment) may be used as a host identifier by 169 DHCP, and used for parameter assignment. This includes centralized 170 assignment of IP addresses to hosts. This provides a secure remote 171 ID from a trusted source -- the relay agent. 173 A number of issues arise when forwarding DHCP requests from hosts 174 connecting publicly accessed high-speed circuits with LAN connections 175 at the host. Many of these are security issues arising from DHCP 176 client requests from untrusted sources. How does the relay agent 177 know to which circuit to forward replies? How does the system 178 prevent DHCP IP exhaustion attacks? This is when an attacker 179 requests all available IP addresses from a DHCP server by sending 180 requests with fabricated client MAC addresses. How can an IP address 181 or LIS be permanently assigned to a particular user or modem? How 182 does one prevent "spoofing" of client identifer fields used to assign 183 IP addresses? How does one prevent denial of service by "spoofing" 184 other client's MAC addresses? 186 All of these issues may be addressed by having the circuit access 188 February 11, 1997 190 equipment, which is a trusted component, add information to DHCP 191 client requests that it forwards to the DHCP server. 193 2.0 Relay Agent Information Option 195 This document defines a new DHCP Option called the Relay Agent 196 Information Option. It is a "container" option for specific agent- 197 supplied sub-options. The format of the Relay Agent Information 198 option is: 200 Code Len Agent Information Field 201 +------+------+------+------+------+------+--...-+------+ 202 | 82 | N | i1 | i2 | i3 | i4 | | iN | 203 +------+------+------+------+------+------+--...-+------+ 205 The length N gives the total number of octets in the Agent 206 Information Field. The Agent Information field consists of a sequence 207 of SubOpt/Length/Value tuples for each sub-option, encoded in the 208 following manner: 210 SubOpt Len Sub-option Value 211 +------+------+------+------+------+------+--...-+------+ 212 | 1 | N | s1 | s2 | s3 | s4 | | sN | 213 +------+------+------+------+------+------+--...-+------+ 214 SubOpt Len Sub-option Value 215 +------+------+------+------+------+------+--...-+------+ 216 | 2 | N | i1 | i2 | i3 | i4 | | iN | 217 +------+------+------+------+------+------+--...-+------+ 219 No "pad" sub-option is defined, and the Information field shall NOT 220 be terminated with a 255 sub-option. The length N of the DHCP Agent 221 Information Option shall include all bytes of the sub-option 222 code/length/value tuples. Since at least one sub-option must be 223 defined, the minimum Relay Agent Information length is two (2). The 224 length N of the sub-options shall be the number of octets in only 225 that sub-option's value field. A sub-option length may be zero. The 226 sub-options need not appear in sub-option code order. 228 February 11, 1997 230 Sub-option codes shall be assigned by IANA. The initial assignment 231 shall be as follows: 233 DHCP Agent Sub-Option Descrption 234 Sub-option Code 235 --------------- ---------------------- 236 1 Agent Circuit ID Sub-option 237 2 Agent Remote ID Sub-option 239 Future drafts may define additional Relay Agent Information sub- 240 options. 242 2.1 Agent Operation 244 A DHCP relay agent adding a Relay Agent Information field SHALL add 245 it as the last DHCP agent option in the DHCP options field of any 246 recognized DHCP packet forwarded from a client to a server. Such 247 additions shall be made for only those packets recognized as DHCP; 248 BOOTP-only packets shall not be affected. 250 Relay agents receiving a DHCP packet with giaddr set to zero 251 (indicating that they are the first-hop router) but with a Relay 252 Agent Information option already present in the packet SHALL discard 253 the packet and increment an error count. 255 Relay agents supporting the Relay Agent Information option SHOULD 256 have separate configurables for each sub-option to control whether it 257 is added to client-to-server packets. 259 Relay agents SHOULD have a configurable for the maximum size of the 260 DHCP packet to be created after appending the Agent Information 261 option. Packets which, after appending the Relay Agent Information 262 option, would exceed this configured maximum size shall be forwarded 263 WITHOUT adding the Agent Information option. An error counter SHOULD 264 be incremented in this case. In the absence of this configurable, 265 the agent SHALL NOT exceed a size of 576 bytes for the IP MTU 266 containing the modified DHCP packet. The default value of the 267 configurable shall be 576 bytes. 269 The Relay Agent Information option echoed by a server SHOULD be 270 removed by the agent when forwarding a server-to-client response back 271 to the client. The agent MAY choose to not remove the option when, 272 for example, the Relay Agent Information field is not the last option 273 in the server-to-client response. 275 The agent SHALL NOT add an "Option Overload" option to the packet or 277 February 11, 1997 279 use the "file" or "sname" fields for adding Relay Agent Information 280 option. It SHALL NOT parse or remove Relay Agent Information options 281 that may appear in the sname or file fields of a server-to-client 282 packet forwarded through the agent. 284 The operation of relay agents for specific sub-options is specified 285 with that sub-option. 287 2.2 Server Operation 289 DHCP servers unaware of the Relay Agent Information option SHOULD 290 ignore the option upon receive and SHOULD not echo it back on 291 responses. This is the specified server behaviour for unknown 292 options. 294 DHCP servers claiming to support the Relay Agent Information option 295 SHALL echo the entire contents of the Relay Agent Information option 296 in all replies. Servers SHOULD copy the Relay Agent Information 297 option as the last DHCP option in the response. Servers SHALL NOT 298 place the echoed Relay Agent Information option in the overloaded 299 sname or file fields. If a server is unable to copy a full Relay 300 Agent Information field into a response, it SHALL send the response 301 without the Relay Information Field, and SHOULD increment an error 302 counter for the situation. 304 Servers using the DHCP Authentication option SHALL exclude the 305 entirety of the Relay Agent Information option (including Code, 306 Length, and Information fields) from the MAC authentication code 307 calculation. 309 The operation of DHCP servers for specific sub-options is specified 310 with that sub-option. 312 February 11, 1997 314 3.0 Relay Agent Information Sub-options 316 3.1 Agent Circuit ID Sub-option 318 This sub-option MAY be added by DHCP relay agents which terminate 319 switched or permanent circuits. It encodes an agent-local identifier 320 of the circuit from which a DHCP client-to-server packet was 321 received. It is intended for use by agents in relaying DHCP 322 responses back to the proper circuit. Possible uses of this field 323 include 324 - Router interface number 325 - Switching Hub port number 326 - Remote Access Server port number 327 - Frame Relay DLCI 328 - ATM virtual circuit number 329 - Cable Data virtual circuit number 331 The format of the Agent Circuit ID may be further standardized by 332 IETF working groups responsible for IP communication on that type of 333 circuit. In the absence of such standardization, the format may 334 proprietary to the relay agent vendor. 336 Servers MAY use the information for IP and other parameter assignment 337 policies, but care should be taken due to the potential proprietary 338 format. The DHCP server SHOULD report the Agent Circuit ID value of 339 current leases in statistical reports (including its MIB) and in 340 logs. Since the Circuit ID is local only to a particular relay 341 agent, a circuit ID should be qualified with the giaddr value that 342 identifies the relay agent. 344 SubOpt Len Circuit ID 345 +------+------+------+------+------+------+------+------+-- 346 | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... 347 +------+------+------+------+------+------+------+------+-- 349 February 11, 1997 351 3.2 Agent Remote ID Sub-option 353 This sub-option MAY be added by DHCP relay agents which terminate 354 switched or permanent circuits and have mechanisms to identify the 355 remote host end of the circuit. The Remote ID field may be used to 356 encode, for instance: 357 -- a "caller ID" telephone number for dial-up connection 358 -- a "user name" prompted for by a Remote Access Server 359 -- a remote caller ATM address 360 -- a "modem ID" of a cable data modem 361 -- the remote IP address of a point-to-point link 362 -- a remote X.25 address for X.25 connections 364 The format of the Agent Remote ID will depend on the type of circuit 365 connected to the relay agent, and further specification of this field 366 may be standardized by the IETF working groups responsible for IP 367 communications on those circuit types. The only requirement is that 368 the remote ID be administered as globally unique. 370 DHCP servers MAY use this option to select parameters specific to 371 particular users, hosts, or subscriber modems. The relay agent MAY 372 use this field in addition to or instead of the Agent Circuit ID 373 field to select the circuit on which to forward the DHCP reply (e.g. 374 Offer, Ack, or Nak). DHCP servers SHOULD report this value in any 375 reports or MIBs associated with a particular client. 377 SubOpt Len Agent Remote ID 378 +------+------+------+------+------+------+------+------+-- 379 | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... 380 +------+------+------+------+------+------+------+------+-- 382 4.0 Issues Resolved 384 Broadcast Forwarding 386 The circuit access equipment forwards the normally broadcasted 387 DHCP response only on the circuit indicated in the Agent Circuit 388 ID. 390 DHCP Address Exhaustion 392 In general, the DHCP server may be extended to maintain a database 393 with the "triplet" of 395 February 11, 1997 397 (client IP address, client MAC address, client remote ID) 399 The DHCP server SHOULD implement policies that restrict the number 400 of IP addresses to be assigned to a single remote ID. 402 Static Assignment 404 The DHCP server may use the remote ID to select the IP address to 405 be assigned. It may permit static assignment of IP addresses to 406 particular remote IDs, and disallow an address request from an 407 unauthorized remote ID. 409 IP Spoofing 411 The circuit access device may associate the IP address assigned by 412 a DHCP server in a forwarded DHCP Ack packet with the circuit to 413 which it was forwarded. The circuit access device MAY prevent 414 forwarding of IP packets with source IP addresses -other than- 415 those it has associated with the receiving circuit. This prevents 416 simple IP spoofing attacks on the Central Lan, and IP spoofing of 417 other hosts. 419 Client Identifer Spoofing 421 By using the agent-supplied Agent Remote ID option, the untrusted 422 and as-yet unstandardized client identifer field need not be used 423 by the DHCP server. 425 MAC Address Spoofing 427 By associating a MAC address with an Agent Remote ID, the DHCP 428 server can prevent offering an IP address to an attacker spoofing 429 the same MAC address on a different remote ID. 431 5.0 Security Considerations 433 DHCP per se currently provides no authentication or security 434 mechanisms. Potential exposures to attack are discussed in section 7 435 of the DHCP protocol specification [1]. 437 This document introduces mechanisms to address several security 438 attacks on the operation of IP address assignment, including IP 439 spoofing, Client ID spoofing, MAC address spoofing, and DHCP server 441 February 11, 1997 443 address exhaustion. It relies on an implied trusted relationship 444 between the DHCP Relay Agent and the DHCP server, with an assumed 445 untrusted DHCP client. It introduces a new identifer, the "Remote 446 ID", that is also assumed to be trusted. The Remote ID is provided by 447 the access network or modem and not by client premise equipment. 448 Cryptographic or other techniques to authenticate the remote ID are 449 certainly possible and encouraged, but are beyond the scope of this 450 document. 452 6.0 References 454 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 455 Bucknell University, March 1997. 457 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor Extension" 458 RFC 2132. 460 7.0 Glossary 462 IANA Internet Assigned Numbers Authority 463 LIS Logical IP Subnet 464 MAC Message Authentication Code 465 RAS Remote Access Server 467 8.0 Author's Address 469 Michael Patrick 470 Motorola Information Systems Group 471 20 Cabot Blvd., MS M4-30 472 Mansfield, MA 02048 474 Phone: (508) 261-5707 475 Email: mpatrick@dma.isg.mot.com