idnits 2.17.1 draft-ietf-dhc-agent-options-04.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 60 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 9 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 245: '...lay agent option SHOULD be configurabl...' RFC 2119 keyword, line 246: '... and SHOULD be disabled by default. ...' RFC 2119 keyword, line 250: '...elay Agent Information field SHALL add...' RFC 2119 keyword, line 258: '...dy present in the packet SHALL discard...' RFC 2119 keyword, line 261: '... Relay agents MAY have a configurabl...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 288 has weird spacing: '...s. This inclu...' == Line 419 has weird spacing: '... agents to id...' -- 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 (August 3, 1998) is 9390 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 511, but no explicit reference was found in the text Summary: 11 errors (**), 0 flaws (~~), 6 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 August 3, 1998 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), ftp.ietf.org 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 August 3, 1998 48 Table of Contents 50 1 Introduction........................................... 2 51 1.1 High-Speed Circuit Switched Data Networks.............. 3 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....................................... 7 57 3.0 Relay Agent Information Suboptions..................... 8 58 3.1 Agent Circuit ID....................................... 8 59 3.2 Agent Remote ID........................................ 9 60 3.3 Agent Subnet Mask...................................... 10 61 4.0 Issues Resolved........................................ 10 62 5.0 Security Considerations................................ 11 63 6.0 References............................................. 12 64 7.0 Glossary............................................... 12 65 8.0 Author's Address....................................... 12 67 Revision History 69 Rev Date Description 70 --- -------- ----------- 71 -04 08/03/98 -Remove 576 byte limit 72 -Remove "nested" relay agent operation 73 -Add Agent Subnet Mask sub-option 74 -Clarify agent options not on RENEWING packets 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 89 central point. The PPP protocol is widely used to assign IP 91 August 3, 1998 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 136 appropriate for relatively small corporate networking environments, 138 August 3, 1998 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 187 equipment, which is a trusted component, add information to DHCP 189 August 3, 1998 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 August 3, 1998 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 238 3 Agent Subnet Mask 240 Future drafts may define additional Relay Agent Information sub- 241 options. 243 2.1 Agent Operation 245 Overall adding of the DHCP relay agent option SHOULD be configurable, 246 and SHOULD be disabled by default. Relay agents SHOULD have separate 247 configurables for each sub-option to control whether it is added to 248 client-to-server packets. 250 A DHCP relay agent adding a Relay Agent Information field SHALL add 251 it as the last DHCP agent option in the DHCP options field of any 252 recognized DHCP packet forwarded from a client to a server. Such 253 additions shall be made for only those packets recognized as DHCP; 254 BOOTP-only packets shall not be affected. 256 Relay agents receiving a DHCP packet with giaddr set to zero 257 (indicating that they are the first-hop router) but with a Relay 258 Agent Information option already present in the packet SHALL discard 259 the packet and increment an error count. 261 Relay agents MAY have a configurable for the maximum size of the DHCP 262 packet to be created after appending the Agent Information option. 263 Packets which, after appending the Relay Agent Information option, 264 would exceed this configured maximum size shall be forwarded WITHOUT 265 adding the Agent Information option. An error counter SHOULD be 266 incremented in this case. In the absence of this configurable, the 267 agent SHALL NOT increase a forwarded DHCP packet size to exceed the 268 MTU of the interface on which it is forwarded. 270 The Relay Agent Information option echoed by a server SHOULD be 271 removed by the agent when forwarding a server-to-client response back 272 to the client. The agent MAY choose to not remove the option when, 273 for example, the Relay Agent Information field is not the last option 274 in the server-to-client response. 276 August 3, 1998 278 The agent SHALL NOT add an "Option Overload" option to the packet or 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 Relay agents are NOT required to monitor or modify client-originated 288 DHCP packets addressed to a server unicast address. This includes 289 the DHCP-REQUEST sent when entering the RENEWING state. 291 2.1.1 Reforwarded DHCP requests 293 A DHCP relay agent may receive a client DHCP packet forwarded from a 294 BOOTP/DHCP relay agent closer to the client. Such a packet will have 295 giaddr as non-zero, and may or may not already have a DHCP Relay 296 Agent option in it. 298 Relay agents configured to add a Relay Agent option which receive a 299 client DHCP packet with a nonzero giaddr SHALL discard the packet if 300 the giaddr spoofs a giaddr address implemented by the local agent 301 itself. 303 Otherwise, the relay agent SHALL forward any received DHCP packet 304 with a valid non-zero giaddr WITHOUT adding any relay agent options. 305 Per RFC 2131, it shall also NOT modify the giaddr value. 307 2.2 Server Operation 309 DHCP servers unaware of the Relay Agent Information option will 310 ignore the option upon receive and will not echo it back on 311 responses. This is the specified server behavior for unknown 312 options. 314 DHCP servers claiming to support the Relay Agent Information option 315 SHALL echo the entire contents of the Relay Agent Information option 316 in all replies. Servers SHOULD copy the Relay Agent Information 317 option as the last DHCP option in the response. Servers SHALL NOT 318 place the echoed Relay Agent Information option in the overloaded 319 sname or file fields. If a server is unable to copy a full Relay 320 Agent Information field into a response, it SHALL send the response 321 without the Relay Information Field, and SHOULD increment an error 322 counter for the situation. 324 Servers using the DHCP Authentication option SHALL exclude the 326 August 3, 1998 328 entirety of the Relay Agent Information option (including Code, 329 Length, and Information fields) from the MAC authentication code 330 calculation. 332 The operation of DHCP servers for specific sub-options is specified 333 with that sub-option. 335 Note that since DHCP relay agents are not required to monitor 336 unicasts between client and server, the relay agent options may not 337 appear in the unicast DHCP-REQUESTs from renewing clients. Relay 338 agent options are intended for use with new leases. 340 3.0 Relay Agent Information Sub-options 342 3.1 Agent Circuit ID Sub-option 344 This sub-option MAY be added by DHCP relay agents which terminate 345 switched or permanent circuits. It encodes an agent-local identifier 346 of the circuit from which a DHCP client-to-server packet was 347 received. It is intended for use by agents in relaying DHCP 348 responses back to the proper circuit. Possible uses of this field 349 include 350 - Router interface number 351 - Switching Hub port number 352 - Remote Access Server port number 353 - Frame Relay DLCI 354 - ATM virtual circuit number 355 - Cable Data virtual circuit number 357 The format of the Agent Circuit ID may be further standardized by 358 IETF working groups responsible for IP communication on that type of 359 circuit. In the absence of such standardization, the format may 360 proprietary to the relay agent vendor. 362 Servers MAY use the Circuit ID for IP and other parameter assignment 363 policies. The Circuit ID SHOULD be considered an opaque value, with 364 policies based on exact string match only; that is, the Circuit ID 365 SHOULD NOT be internally parsed by the server. 367 The DHCP server SHOULD report the Agent Circuit ID value of current 368 leases in statistical reports (including its MIB) and in logs. Since 369 the Circuit ID is local only to a particular relay agent, a circuit 370 ID should be qualified with the giaddr value that identifies the 371 relay agent. 373 August 3, 1998 375 SubOpt Len Circuit ID 376 +------+------+------+------+------+------+------+------+-- 377 | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... 378 +------+------+------+------+------+------+------+------+-- 380 3.2 Agent Remote ID Sub-option 382 This sub-option MAY be added by DHCP relay agents which terminate 383 switched or permanent circuits and have mechanisms to identify the 384 remote host end of the circuit. The Remote ID field may be used to 385 encode, for instance: 386 -- a "caller ID" telephone number for dial-up connection 387 -- a "user name" prompted for by a Remote Access Server 388 -- a remote caller ATM address 389 -- a "modem ID" of a cable data modem 390 -- the remote IP address of a point-to-point link 391 -- a remote X.25 address for X.25 connections 393 The format of the Agent Remote ID will depend on the type of circuit 394 connected to the relay agent, and further specification of this field 395 may be standardized by the IETF working groups responsible for IP 396 communications on those circuit types. The only requirement is that 397 the remote ID be administered as globally unique. 399 DHCP servers MAY use this option to select parameters specific to 400 particular users, hosts, or subscriber modems. The option SHOULD be 401 considered an opaque value, with policies based on exact string match 402 only; that is, the option SHOULD NOT be internally parsed by the 403 server. 405 The relay agent MAY use this field in addition to or instead of the 406 Agent Circuit ID field to select the circuit on which to forward the 407 DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this 408 value in any reports or MIBs associated with a particular client. 410 SubOpt Len Agent Remote ID 411 +------+------+------+------+------+------+------+------+-- 412 | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... 413 +------+------+------+------+------+------+------+------+-- 415 August 3, 1998 417 3.3 Agent Subnet Mask 419 This sub-option MAY be added by DHCP relay agents to identify the 420 subnet mask of the Logical IP Subnet (LIS) from which the client DHCP 421 packet was received. The LIS of the client is defined as the subnet 422 formed by the giaddr ANDed with the Agent Subnet Mask. 424 Servers MAY use this mask field to automatically create scopes of 425 assignable IP addresses. Use of this field avoids the need to have 426 identical configuration of the logical IP subnets on which clients 427 reside in both the relaying routers and the DHCP server. In this 428 case, the router configuration defines the LISs, and the DHCP servers 429 automatically discover the LISs from the relay agent options of 430 forwarded client DHCP requests. 432 SubOpt Len Agent Subnet Mask 433 +------+------+------+------+------+------+ 434 | 3 | 4 | m1 | m2 | m3 | m4 | 435 +------+------+------+------+------+------+ 437 4.0 Issues Resolved 439 Broadcast Forwarding 441 The circuit access equipment forwards the normally broadcasted 442 DHCP response only on the circuit indicated in the Agent Circuit 443 ID. 445 DHCP Address Exhaustion 447 In general, the DHCP server may be extended to maintain a database 448 with the "triplet" of 450 (client IP address, client MAC address, client remote ID) 452 The DHCP server SHOULD implement policies that restrict the number 453 of IP addresses to be assigned to a single remote ID. 455 August 3, 1998 457 Static Assignment 459 The DHCP server may use the remote ID to select the IP address to 460 be assigned. It may permit static assignment of IP addresses to 461 particular remote IDs, and disallow an address request from an 462 unauthorized remote ID. 464 IP Spoofing 466 The circuit access device may associate the IP address assigned by 467 a DHCP server in a forwarded DHCP Ack packet with the circuit to 468 which it was forwarded. The circuit access device MAY prevent 469 forwarding of IP packets with source IP addresses -other than- 470 those it has associated with the receiving circuit. This prevents 471 simple IP spoofing attacks on the Central Lan, and IP spoofing of 472 other hosts. 474 Client Identifer Spoofing 476 By using the agent-supplied Agent Remote ID option, the untrusted 477 and as-yet unstandardized client identifer field need not be used 478 by the DHCP server. 480 MAC Address Spoofing 482 By associating a MAC address with an Agent Remote ID, the DHCP 483 server can prevent offering an IP address to an attacker spoofing 484 the same MAC address on a different remote ID. 486 5.0 Security Considerations 488 DHCP per se currently provides no authentication or security 489 mechanisms. Potential exposures to attack are discussed in section 7 490 of the DHCP protocol specification [1]. 492 This document introduces mechanisms to address several security 493 attacks on the operation of IP address assignment, including IP 494 spoofing, Client ID spoofing, MAC address spoofing, and DHCP server 495 address exhaustion. It relies on an implied trusted relationship 496 between the DHCP Relay Agent and the DHCP server, with an assumed 497 untrusted DHCP client. It introduces a new identifer, the "Remote 498 ID", that is also assumed to be trusted. The Remote ID is provided by 499 the access network or modem and not by client premise equipment. 500 Cryptographic or other techniques to authenticate the remote ID are 501 certainly possible and encouraged, but are beyond the scope of this 502 document. 504 August 3, 1998 506 6.0 References 508 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 509 Bucknell University, March 1997. 511 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor 512 Extension" RFC 2132. 514 7.0 Glossary 516 IANA Internet Assigned Numbers Authority 517 LIS Logical IP Subnet 518 MAC Message Authentication Code 519 RAS Remote Access Server 521 8.0 Author's Address 523 Michael Patrick 524 Motorola Information Systems Group 525 20 Cabot Blvd., MS M4-30 526 Mansfield, MA 02048 528 Phone: (508) 261-5707 529 Email: mpatrick@dma.isg.mot.com