idnits 2.17.1 draft-ietf-dhc-agent-options-03.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-18) 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 11 longer pages, the longest (page 2) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 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 20 instances of too long lines in the document, the longest one being 6 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 250: '...lay agent option SHOULD be configurabl...' RFC 2119 keyword, line 251: '... and SHOULD be disabled by default. ...' RFC 2119 keyword, line 255: '...elay Agent Information field SHALL add...' RFC 2119 keyword, line 263: '...dy present in the packet SHALL discard...' RFC 2119 keyword, line 266: '... Relay agents SHOULD have a configur...' (28 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 behavior 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 (November 24, 1997) is 9642 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 502, 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. -------------------------------------------------------------------------------- 2 DHC Working Grop Michael Patrick 3 Motorola ISG 4 November 24, 1997 6 DHCP Relay Agent Information Option 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 Please check the "1id-abstracts.txt" listing contained in the 22 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 23 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net 24 (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 Newer high-speed public Internet access technologies call for a 29 high-speed modem to have a LAN attachment to one or more user hosts. 30 It is advantageous to use DHCP to assign user host IP addresses in 31 this environment, but a number of security and scaling problems arise 32 with such ''public'' DHCP use. This draft calls for the definition of 33 a ''DHCP Relay Agent Information'' option that is appended to a DHCP 34 packet forwarded from a client to a server by a relay agent. The 35 Server may or may not use the information in the the Relay Agent 36 Information option; in either case, it echoes back the option 37 verbatim in server-to-client replies. 39 The ''Relay Agent Information'' option contains sub-options that convey 40 information known by the relay agent. The initial sub-options are 41 defined for a relay agent that is co-located in a public circuit 42 access unit. These include a ''circuit ID'' for the incoming circuit 43 and a ''remote ID'' which provides a trusted identifier for the remote 44 high-speed modem. 46 November 24, 1997 48 Table of Contents 50 1 Introduction........................................... 2 51 1.1 High-Speed Circuit Switched Data Networks.............. 2 52 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4 53 2.0 Relay Agent Information Option......................... 5 54 2.1 Agent Operation........................................ 6 55 2.1.1 Reforwarding......................................... 7 56 2.2 Server Operation....................................... 8 57 3.0 Relay Agent Information Suboptions..................... 9 58 3.1 Agent Circuit ID....................................... 9 59 3.2 Agent Remote ID........................................ 10 60 4.0 Issues Resolved........................................ 10 61 5.0 Security Considerations................................ 11 62 6.0 References............................................. 12 63 7.0 Glossary............................................... 12 64 8.0 Author's Address....................................... 12 66 Revision History 68 Rev Date Description 69 --- -------- ----------- 70 -03 11/25/97 Add "2.1.1 Reforwarding". Add per-option 71 configurables. 72 -02 07/30/97 Add Security Considerations 73 -01 06/06/97 Updated per March 97 IETF review: 74 Organize as one DHCP option with 75 sub-options. 76 Clarify operation when option already 77 present. 78 Move Agent Subnet Mask option to separate 79 document. 80 -00 12/11/96 Original 82 1 Introduction 84 1.1 High-Speed Circuit Switched Data Networks 86 Public Access to the Internet is usually via a circuit switched data 87 network. Today, this is primarily implemented with dial-up modems 88 connecting to a Remote Access Server. But higher speed circuit 89 access networks also include ISDN, ATM, Frame Relay, and Cable Data 90 Networks. All of these networks can be characterized as a "star" 91 topology where multiple users connect to a "circuit access unit" via 93 November 24, 1997 95 switched or permanent circuits. 97 With dial-up modems, only a single host PC attempts to connect to the 98 central point. The PPP protocol is widely used to assign IP 99 addresses to be used by the single host PC. 101 The newer high-speed circuit technologies, however, frequently 102 provide a LAN interface (especially Ethernet) to one or more host 103 PCs. It is desirable to support centralized assignment of the IP 104 addresses of host computers connecting on such circuits via DHCP. 105 The DHCP server can be, but usually is not, co-implemented with the 106 centralized circuit concentration access device. The DHCP server is 107 often connected as a separate server on the "Central LAN" to which 108 the central access device (or devices) attach. 110 A common physical model for high-speed Internet circuit access is 111 shown in Figure 1, below. 113 +---------------+ | 114 Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A 115 LAN | | Access | Lan |- Host B 116 | | Unit 1 | |- Host C 117 |-----| |-- | 118 | |(relay agent) |... 119 +---------+ | +---------------+ 120 | DHCP |--| 121 | Server | | 122 +---------+ | 123 | 124 | +---------------+ 125 +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D 126 | Other | | | Access | Lan 127 | Servers |--|-----| Unit 2 | 128 | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E 129 | DNS) | | |(relay agent) |... Lan 130 | | +---------------+ 131 +---------+ 132 Figure 1: DHCP High Speed Circuit Access Model 134 Note that in this model, the "modem" connects to a LAN at the user 135 site, rather than to a single host. Multiple hosts are implemented at 136 this site. Although it is certainly possible to implement a full IP 137 router at the user site, this requires a relatively expensive piece 138 of equipment (compared to typical modem costs). Furthermore, a 140 November 24, 1997 142 router requires an IP address not only for every host, but for the 143 router itself. Finally, a user-side router requires a dedicated 144 Logical IP Subnet (LIS) for each user. While this model is 145 appropriate for relatively small corporate networking environments, 146 it is not appropriate for large, public accessed networks. In this 147 scenario, it is advantageous to implement an IP networking model that 148 does not allocate an IP address for the modem (or other networking 149 equipment device at the user site), and especially not an entire LIS 150 for the user side LAN. 152 1.2 DHCP Relay Agent in the Circuit Access Unit 154 It is desirable to use DHCP to assign the IP addresses for public 155 high-speed circuit access. A number of circuit access units (e.g. 156 RAS's, cable modem termination systems, ADSL access units, etc) 157 connect to a LAN (or local internet) to which is attached a DHCP 158 server. 160 For scaling and security reasons, it is advantageous to implement a 161 "router hop" at the circuit access unit, much like high-capacity 162 RAS's do today. The circuit access equipment acts as both a router 163 to the circuits and as the DHCP relay agent. 165 The advantages of co-locating the DHCP relay agent with the circuit 166 access equipment are: 168 DHCP broadcast replies can be routed to only the proper circuit, 169 avoiding, say, the replication of the DCHP reply broadcast onto 170 thousands of access circuits; 172 The same mechanism used to identify the remote connection of the 173 circuit (e.g. a user ID requested by a Remote Access Server acting as 174 the circuit access equipment) may be used as a host identifier by 175 DHCP, and used for parameter assignment. This includes centralized 176 assignment of IP addresses to hosts. This provides a secure remote 177 ID from a trusted source -- the relay agent. 179 A number of issues arise when forwarding DHCP requests from hosts 180 connecting publicly accessed high-speed circuits with LAN connections 181 at the host. Many of these are security issues arising from DHCP 182 client requests from untrusted sources. How does the relay agent 183 know to which circuit to forward replies? How does the system 184 prevent DHCP IP exhaustion attacks? This is when an attacker 185 requests all available IP addresses from a DHCP server by sending 186 requests with fabricated client MAC addresses. How can an IP address 187 or LIS be permanently assigned to a particular user or modem? How 188 does one prevent "spoofing" of client identifer fields used to assign 189 IP addresses? How does one prevent denial of service by "spoofing" 191 November 24, 1997 193 other client's MAC addresses? 195 All of these issues may be addressed by having the circuit access 196 equipment, which is a trusted component, add information to DHCP 197 client requests that it forwards to the DHCP server. 199 2.0 Relay Agent Information Option 201 This document defines a new DHCP Option called the Relay Agent 202 Information Option. It is a "container" option for specific agent- 203 supplied sub-options. The format of the Relay Agent Information 204 option is: 206 Code Len Agent Information Field 207 +------+------+------+------+------+------+--...-+------+ 208 | 82 | N | i1 | i2 | i3 | i4 | | iN | 209 +------+------+------+------+------+------+--...-+------+ 211 The length N gives the total number of octets in the Agent 212 Information Field. The Agent Information field consists of a sequence 213 of SubOpt/Length/Value tuples for each sub-option, encoded in the 214 following manner: 216 SubOpt Len Sub-option Value 217 +------+------+------+------+------+------+--...-+------+ 218 | 1 | N | s1 | s2 | s3 | s4 | | sN | 219 +------+------+------+------+------+------+--...-+------+ 220 SubOpt Len Sub-option Value 221 +------+------+------+------+------+------+--...-+------+ 222 | 2 | N | i1 | i2 | i3 | i4 | | iN | 223 +------+------+------+------+------+------+--...-+------+ 225 No "pad" sub-option is defined, and the Information field shall NOT 226 be terminated with a 255 sub-option. The length N of the DHCP Agent 227 Information Option shall include all bytes of the sub-option 228 code/length/value tuples. Since at least one sub-option must be 229 defined, the minimum Relay Agent Information length is two (2). The 230 length N of the sub-options shall be the number of octets in only 231 that sub-option's value field. A sub-option length may be zero. The 232 sub-options need not appear in sub-option code order. 234 November 24, 1997 236 Sub-option codes shall be assigned by IANA. The initial assignment 237 shall be as follows: 239 DHCP Agent Sub-Option Descrption 240 Sub-option Code 241 --------------- ---------------------- 242 1 Agent Circuit ID Sub-option 243 2 Agent Remote ID Sub-option 245 Future drafts may define additional Relay Agent Information sub- 246 options. 248 2.1 Agent Operation 250 Overall adding of the DHCP relay agent option SHOULD be configurable, 251 and SHOULD be disabled by default. Relay agents SHOULD have separate 252 configurables for each sub-option to control whether it is added to 253 client-to-server packets. 255 A DHCP relay agent adding a Relay Agent Information field SHALL add 256 it as the last DHCP agent option in the DHCP options field of any 257 recognized DHCP packet forwarded from a client to a server. Such 258 additions shall be made for only those packets recognized as DHCP; 259 BOOTP-only packets shall not be affected. 261 Relay agents receiving a DHCP packet with giaddr set to zero 262 (indicating that they are the first-hop router) but with a Relay 263 Agent Information option already present in the packet SHALL discard 264 the packet and increment an error count. 266 Relay agents SHOULD have a configurable for the maximum size of the 267 DHCP packet to be created after appending the Agent Information 268 option. Packets which, after appending the Relay Agent Information 269 option, would exceed this configured maximum size shall be forwarded 270 WITHOUT adding the Agent Information option. An error counter SHOULD 271 be incremented in this case. In the absence of this configurable, 272 the agent SHALL NOT exceed a size of 576 bytes for the IP MTU 273 containing the modified DHCP packet. The default value of the 274 configurable shall be 576 bytes. 276 The Relay Agent Information option echoed by a server SHOULD be 277 removed by the agent when forwarding a server-to-client response back 278 to the client. The agent MAY choose to not remove the option when, 279 for example, the Relay Agent Information field is not the last option 280 in the server-to-client response. 282 November 24, 1997 284 The agent SHALL NOT add an "Option Overload" option to the packet or 285 use the "file" or "sname" fields for adding Relay Agent Information 286 option. It SHALL NOT parse or remove Relay Agent Information options 287 that may appear in the sname or file fields of a server-to-client 288 packet forwarded through the agent. 290 The operation of relay agents for specific sub-options is specified 291 with that sub-option. 293 2.1.1 Reforwarded DHCP requests 295 A DHCP relay agent may receive a client DHCP packet forwarded from a 296 BOOTP/DHCP relay agent closer to the client. Such a packet will have 297 giaddr as non-zero, and may or may not already have a DHCP Relay 298 Agent option in it. 300 Relay agents configured to add a Relay Agent option which receive a 301 client DHCP packet with a nonzero giaddr SHALL discard the packet if 302 the giaddr spoofs a giaddr address implemented by the local agent 303 itself. 305 If no DHCP Agent option already exists in the packet, the local agent 306 SHALL add a new DHCP Agent option to the forwarded packet in 307 accordance with 2.1, above. 309 If a DHCP agent option does exist in the packet, the relay agent 310 SHOULD process such a reforwarded DHCP packet in a configurable 311 manner, with at least the following choices: 312 R1) Forward, APPENDING: add a new DHCP Agent Option for 313 the local agent; 314 R2) Forward, REPLACING: 315 Replace existing sub-options with the local agent's 316 option; add new sub-options if not already in the 317 Agent Option field. 318 R3) Forward, UNTOUCHED: 319 Do not modify the existing DHCP agent option; 320 R4) Discard the packet (i.e. reforwarding is disabled) 321 The default reforwarding option SHOULD be R1, to append the current 322 agent's options after any existing relay agent options. 324 Per RFC 1542, the relay agent SHALL NOT update the giaddr of any re- 325 forwarded DHCP packet. This necessarily means that the reforwarding 326 relay agent may not be able to strip any new or modified relay agent 327 options added by it, since the server will IP unicast reply to the 328 closer relay agent, rather than the reforwarding agent. 330 November 24, 1997 332 2.2 Server Operation 334 DHCP servers unaware of the Relay Agent Information option SHOULD 335 ignore the option upon receive and SHOULD not echo it back on 336 responses. This is the specified server behavior for unknown 337 options. 339 DHCP servers claiming to support the Relay Agent Information option 340 SHALL echo the entire contents of the Relay Agent Information option 341 in all replies. Servers SHOULD copy the Relay Agent Information 342 option as the last DHCP option in the response. Servers SHALL NOT 343 place the echoed Relay Agent Information option in the overloaded 344 sname or file fields. If a server is unable to copy a full Relay 345 Agent Information field into a response, it SHALL send the response 346 without the Relay Information Field, and SHOULD increment an error 347 counter for the situation. 349 Servers using the DHCP Authentication option SHALL exclude the 350 entirety of the Relay Agent Information option (including Code, 351 Length, and Information fields) from the MAC authentication code 352 calculation. 354 The operation of DHCP servers for specific sub-options is specified 355 with that sub-option. 357 November 24, 1997 359 3.0 Relay Agent Information Sub-options 361 3.1 Agent Circuit ID Sub-option 363 This sub-option MAY be added by DHCP relay agents which terminate 364 switched or permanent circuits. It encodes an agent-local identifier 365 of the circuit from which a DHCP client-to-server packet was 366 received. It is intended for use by agents in relaying DHCP 367 responses back to the proper circuit. Possible uses of this field 368 include 369 - Router interface number 370 - Switching Hub port number 371 - Remote Access Server port number 372 - Frame Relay DLCI 373 - ATM virtual circuit number 374 - Cable Data virtual circuit number 376 The format of the Agent Circuit ID may be further standardized by 377 IETF working groups responsible for IP communication on that type of 378 circuit. In the absence of such standardization, the format may 379 proprietary to the relay agent vendor. 381 Servers MAY use the information for IP and other parameter assignment 382 policies, but care should be taken due to the potential proprietary 383 format. The DHCP server SHOULD report the Agent Circuit ID value of 384 current leases in statistical reports (including its MIB) and in 385 logs. Since the Circuit ID is local only to a particular relay 386 agent, a circuit ID should be qualified with the giaddr value that 387 identifies the relay agent. 389 SubOpt Len Circuit ID 390 +------+------+------+------+------+------+------+------+-- 391 | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... 392 +------+------+------+------+------+------+------+------+-- 394 November 24, 1997 396 3.2 Agent Remote ID Sub-option 398 This sub-option MAY be added by DHCP relay agents which terminate 399 switched or permanent circuits and have mechanisms to identify the 400 remote host end of the circuit. The Remote ID field may be used to 401 encode, for instance: 402 -- a "caller ID" telephone number for dial-up connection 403 -- a "user name" prompted for by a Remote Access Server 404 -- a remote caller ATM address 405 -- a "modem ID" of a cable data modem 406 -- the remote IP address of a point-to-point link 407 -- a remote X.25 address for X.25 connections 409 The format of the Agent Remote ID will depend on the type of circuit 410 connected to the relay agent, and further specification of this field 411 may be standardized by the IETF working groups responsible for IP 412 communications on those circuit types. The only requirement is that 413 the remote ID be administered as globally unique. 415 DHCP servers MAY use this option to select parameters specific to 416 particular users, hosts, or subscriber modems. The relay agent MAY 417 use this field in addition to or instead of the Agent Circuit ID 418 field to select the circuit on which to forward the DHCP reply (e.g. 419 Offer, Ack, or Nak). DHCP servers SHOULD report this value in any 420 reports or MIBs associated with a particular client. 422 SubOpt Len Agent Remote ID 423 +------+------+------+------+------+------+------+------+-- 424 | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... 425 +------+------+------+------+------+------+------+------+-- 427 4.0 Issues Resolved 429 Broadcast Forwarding 431 The circuit access equipment forwards the normally broadcasted 432 DHCP response only on the circuit indicated in the Agent Circuit 433 ID. 435 DHCP Address Exhaustion 437 In general, the DHCP server may be extended to maintain a database 438 with the "triplet" of 440 November 24, 1997 442 (client IP address, client MAC address, client remote ID) 444 The DHCP server SHOULD implement policies that restrict the number 445 of IP addresses to be assigned to a single remote ID. 447 Static Assignment 449 The DHCP server may use the remote ID to select the IP address to 450 be assigned. It may permit static assignment of IP addresses to 451 particular remote IDs, and disallow an address request from an 452 unauthorized remote ID. 454 IP Spoofing 456 The circuit access device may associate the IP address assigned by 457 a DHCP server in a forwarded DHCP Ack packet with the circuit to 458 which it was forwarded. The circuit access device MAY prevent 459 forwarding of IP packets with source IP addresses -other than- 460 those it has associated with the receiving circuit. This prevents 461 simple IP spoofing attacks on the Central Lan, and IP spoofing of 462 other hosts. 464 Client Identifer Spoofing 466 By using the agent-supplied Agent Remote ID option, the untrusted 467 and as-yet unstandardized client identifer field need not be used 468 by the DHCP server. 470 MAC Address Spoofing 472 By associating a MAC address with an Agent Remote ID, the DHCP 473 server can prevent offering an IP address to an attacker spoofing 474 the same MAC address on a different remote ID. 476 5.0 Security Considerations 478 DHCP per se currently provides no authentication or security 479 mechanisms. Potential exposures to attack are discussed in section 7 480 of the DHCP protocol specification [1]. 482 This document introduces mechanisms to address several security 483 attacks on the operation of IP address assignment, including IP 484 spoofing, Client ID spoofing, MAC address spoofing, and DHCP server 486 November 24, 1997 488 address exhaustion. It relies on an implied trusted relationship 489 between the DHCP Relay Agent and the DHCP server, with an assumed 490 untrusted DHCP client. It introduces a new identifer, the "Remote 491 ID", that is also assumed to be trusted. The Remote ID is provided by 492 the access network or modem and not by client premise equipment. 493 Cryptographic or other techniques to authenticate the remote ID are 494 certainly possible and encouraged, but are beyond the scope of this 495 document. 497 6.0 References 499 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 500 Bucknell University, March 1997. 502 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor 503 Extension" 504 RFC 2132. 506 7.0 Glossary 508 IANA Internet Assigned Numbers Authority 509 LIS Logical IP Subnet 510 MAC Message Authentication Code 511 RAS Remote Access Server 513 8.0 Author's Address 515 Michael Patrick 516 Motorola Information Systems Group 517 20 Cabot Blvd., MS M4-30 518 Mansfield, MA 02048 520 Phone: (508) 261-5707 521 Email: mpatrick@dma.isg.mot.com