idnits 2.17.1 draft-ietf-dhc-agent-options-00.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-20) 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 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 1 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 183 instances of too long lines in the document, the longest one being 20 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 232: '... This option MAY be added by DHCP ...' RFC 2119 keyword, line 250: '...HCP relay agents SHALL NOT modify any ...' RFC 2119 keyword, line 254: '...ting this option MUST return the optio...' RFC 2119 keyword, line 255: '...nd Ack responses. Servers MAY use the...' RFC 2119 keyword, line 258: '... server MAY report the Agent ...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 11, 1996) is 9992 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: '1' is defined on line 397, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 399, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1531 (ref. '1') (Obsoleted by RFC 1541) ** Obsolete normative reference: RFC 1533 (ref. '2') (Obsoleted by RFC 2132) Summary: 14 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 December 11, 1996 5 DHCP Agent-Supplied Options 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 three options which are added by the DHCP relay agent when forwarding 33 public DHCP requests: 35 -- Agent Circuit ID 36 -- Agent Remote ID 37 -- Agent Subnet Mask 39 These options solve the identified problems. 41 December 11, 1996 43 Table of Contents 45 1 Introduction...........................................2 46 1.1 High-Speed Circuit Switched Data Networks..............2 47 1.2 Bridge vs. Router Models...............................3 48 1.3 DHCP Relay Agent in the Circuit Access Equipment.......4 49 2.0 Agent-Supplied Options.................................6 50 2.1 Agent Circuit ID.......................................6 51 2.2 Agent Remote ID........................................7 52 2.3 Agent Subnet Mask......................................7 53 3.0 Issues Resolved........................................8 54 4.0 References.............................................10 55 5.0 Author's Address.......................................10 57 1 Introduction 59 1.1 High-Speed Circuit Switched Data Networks 61 Public Access to the Internet is usually via a circuit switched data 62 network. Today, this is primarily implemented with dial-up modems 63 connecting to a Remote Access Server. But higher speed circuit 64 access networks also include ISDN, ATM, Frame Relay, and Cable Data 65 Networks. All of these networks can be characterized as a "star" 66 topology where multiple users connect to a central access point. 68 With dial-up modems, only a single host PC attempts to connect to the 69 central point. The PPP protocol is widely used to assign IP 70 addresses to be used by the single host PC. 72 The newer high-speed circuit technologies, however, frequently 73 provide a LAN interface (especially Ethernet) to one or more host 74 PCs. It is desirable to support centralized assignment of the IP 75 addresses of host computers connecting on such circuits via DHCP. 76 The DHCP server can be, but usually is not, co-implemented with the 77 centralized circuit concentration access device. The DHCP server is 78 often connected as a separate server on the "Central LAN" to which 79 the central access device (or devices) attach. 81 A common physical model for high-speed Internet circuit access is 82 shown in Figure 1, below. 84 December 11, 1996 86 +---------------+ 87 Central | DHCP |-- ckt 1--- Modem1-- Host--- Host A 88 LAN | | Relay | Lan +- Host B 89 | | Agent | +- Host C 90 |-----| 1 |-- 91 | | |... 92 +---------+ | +---------------+ 93 | DHCP |--| 94 | Server | | 95 +---------+ | 96 | 97 | +---------------+ 98 +---------+ | | DHCP |-- ckt 1--- Modem2-- Host--- Host D 99 | Other | | | Relay | Lan 100 | Servers |--|-----| Agent | 101 | (Web, | | | 2 |-- ckt 2--- Modem3-- Host--- Host E 102 | DNS) | | | |... Lan 103 | | +---------------+ 104 +---------+ 105 Figure 1: DHCP High Speed Circuit Access Model 107 Note that in this model, the "modem" connects to a LAN at the user 108 site, rather than to a single host. Multiple hosts are implemented at 109 this site. Although it is certainly possible to implement a full IP 110 router at the user site, this requires a relatively expensive piece 111 of equipment (compared to typical modem costs). Furthermore, a 112 router requires an IP address not only for every host, but for the 113 router itself. Finally, a user-side router requires a dedicated 114 Logical IP Subnet (LIS) for each user. While this model is 115 appropriate for relatively small corporate networking environments, 116 it is not appropriate for large, public accessed networks. In this 117 scenario, it is advantageous to implement an IP networking model that 118 does not allocate an IP address for the modem (or other networking 119 equipment device at the user site), and especially not an entire LIS 120 for the user side LAN. 122 1.2 Bridge vs. Router Models 124 For relay agents implementing a "bridge" model, i.e. where the 125 service offered is to bridge the Host LAN with the Central LAN, the 126 DHCP broadcast from the host is forwarded at the data link layer to 127 the DHCP server. The central access device performs proxy ARP for 129 December 11, 1996 131 hosts, and DHCP proceeds as if the host and the DHCP server are on 132 the same IP subnetwork. 134 It is envisioned, however, that public access devices must support 135 tens of thousands of hosts connecting into the service, e.g. through 136 a cable data service. In this environment, it is unreasonable to 137 require all hosts and servers on the central LAN to maintain ARP 138 tables with tens of thousands of entries. A this scale, then, it is 139 necessary to provides a "Routing" model of public Internet access, 140 where one or more Logical IP Subnets (LISs) are implemented for 141 connecting hosts. The connecting hosts must be assigned, via DHCP, 142 host addresses from a set of LISs. 144 The Routing access model requires at some point between the Host and 145 the Central LAN a Logical IP Subnet (LIS) interface be identified, 146 and that the Host be assigned an IP address on that LIS. The 147 choices in use today by LAN-attached modems include: 149 1. Modem LIS: A LIS is defined for all hosts connected to the 150 Modem. This describes "dial-up" routers, ISDN routers, IP 151 routing Frame Relay Access Devices, and some cable data modems. 153 2. Router LIS: The circuit attachment equipment provides only 154 bridging between an intermediate LAN and the Host LAN. A 155 traditional router implements a LIS interface to the 156 intermediate LAN, routing it to the central LAN. This 157 characterizes traditional dial-up Remote Access Servers, and 158 some cable data head-end equipment. 160 3. Virtual LIS: The circuit attachment equipment provides 161 "virtual" LISs, and permits hosts connecting on its circuits to 162 belong to any of them. This characterizes switching hubs, and 163 some cable data network routers. 165 1.3 DHCP Relay Agent in the Circuit Access Equipment 167 This document advocates the co-located implementation of a DHCP relay 168 agent with the circuit access equipment. In the Modem LIS and Virtual 169 LIS model, the circuit access equipment acts as both a router to the 170 circuits and as the DHCP relay agent. It is appropriate for any of 171 the circuit access routing models discussed above, although is most 172 appropriate for the Modem LIS and Virtual LIS models. 174 The advantages of co-locating the DHCP relay agent with the circuit 175 access equipment are: 177 December 11, 1996 179 1. DHCP broadcast replies can be routed to only the proper 180 circuit, avoiding, say, the replication of the DCHP reply 181 broadcast onto thousands of access circuits; 183 2. The same mechanism use to identify the remote connection of the 184 circuit (e.g. a user ID requested by a Remote Access Server 185 acting as teh circuit access equiment) may be used as a host 186 indentifier by DHCP, and used for parameter assignment. This 187 includes centralized static assignment of IP addresses to 188 hosts. This provides a secure remote ID from a trusted source 189 -- the relay agent. 191 A number of issues arise when forwarding DHCP requests from hosts 192 connecting publicly accessed high-speed circuits with LAN connections 193 at the host. Many of these are security issues arising from DHCP 194 client requests from untrusted sources. 196 - How does the relay agent know to which circuit to forward 197 replies? 199 - How does the DHCP server know from which LIS to assign an IP 200 address? 202 - How does the system prevent DHCP IP exhaustion attacks? This 203 is when an attacker requests all available IP addresses from a 204 DHCP server by sending requests with fabricated client MAC 205 addresses. 207 - How can an IP address or LIS be permanently assigned to a 208 particular user or modem? 210 - How does one prevent "spoofing" of client identifer fields used 211 to assign IP addresses? 213 - How does one prevent denial of service by "spoofing" other 214 client's MAC addresses? 216 All of these issues may be addressed by having the circuit access 217 equipment, which is a trusted component, add information to DHCP 218 client requests that it forwards to the DHCP server. 220 2.0 Agent-Supplied Options 222 This document describes options which are added by the DHCP relay 223 agent. It also specifies handling of those options by the DHCP 225 December 11, 1996 227 server. The option IDs shown have been assigned by IANA, and are in 228 decimal format. 230 2.1 Agent Circuit ID 232 This option MAY be added by DHCP relay agents which terminate 233 switched or permanent circuits. It encodes a agent-local identifier 234 of the circuit from which a DHCP discover/request packet was 235 received. It is intended for use by agents in relaying DHCP 236 responses back to the proper circuit. Possible uses of this field 237 include 238 - Router interface number 239 - Switching Hub port number 240 - Remote Access Server port number 241 - Frame Relay DLCI 242 - ATM virtual circuit number 243 - Cable Data virtual circuit number 245 The format of the Agent Circuit ID may be further standardized by 246 IETF working groups responsible for IP communication on that type of 247 circuit. In the absence of such standardization, the format may 248 proprietary to the relay agent vendor. 250 DHCP relay agents SHALL NOT modify any existing Agent Circuit ID 251 field which may be in a received DHCP Discover/Request; such an 252 option may have been added by a circuit bridge. 254 DHCP servers supporting this option MUST return the option value 255 unchanged in all Offer and Ack responses. Servers MAY use the 256 information for IP and other parameter assignment policies, but care 257 should be taken due to the potential proprietary format. The DHCP 258 server MAY report the Agent Circuit ID value of current leases in 259 statistical reports (including its MIB) and in logs. 261 Code Len Circuit ID 262 +------+------+------+------+------+------+------+------+-- 263 | 82 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... 264 +------+------+------+------+------+------+------+------+-- 266 2.2 Agent Remote ID 268 This option MAY be added by DHCP relay agents which terminate 269 switched or permanent circuits and have mechanisms to identify the 270 remote host end of the circuit. The Remote ID field may be used to 272 December 11, 1996 274 encode, for instance: 275 -- a "caller ID" telephone number for dial-up connection 276 -- a "user name" prompted for by a Remote Access Server 277 -- a remote caller ATM address 278 -- a "modem ID" of a cable data modem 279 -- the remote IP address of a point-to-point link 280 -- a remote X.25 address for X.25 connections 282 The format of the Agent Remote ID will depend on the type of circuit 283 connected to the relay agent, and further specification of this field 284 may be standardized by the IETF working groups responsible for IP 285 communications on those circuit types. The only requirement is that 286 the remote ID be administered as globally unique. 288 DHCP servers supporting this option MUST return the option value 289 unchanged in all Offer and Ack responses. DHCP servers MAY use this 290 option to select parameters specific to particular users, hosts, or 291 subscriber modems. The relay agent MAY use this field in addition to 292 or instead of the Agent Circuit ID field to select the circuit on 293 which to forward the DHCP Offer/Ack reply. 295 DHCP relay agents SHALL NOT modify any existing Agent Remote ID field 296 in received broadcasted DHCP Discover/Ack packets; such a field may 297 have been added by a circuit bridge. 299 Code Len Agent Remote ID 300 +------+------+------+------+------+------+------+------+-- 301 | 83 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... 302 +------+------+------+------+------+------+------+------+-- 304 2.3 Agent Subnet Mask 306 This option MAY be added by DHCP relay agents which terminate 307 multiple Logical IP Subnets. It provides the server with the subnet 308 mask for the LIS on which the relay agent received the request. (The 309 giaddr field provides the agent's IP host address on that LIS.) 311 DHCP servers supporting this option MAY copy the Agent Subnet mask 312 value into the Client Subnet Mask (option 1) parameter returned to 313 the host, and SHOULD have a configurable option to do so. DHCP 314 Servers SHOULD NOT return the Agent Subnet Mask option in the 315 response. 317 This option is intended to avoid the duplicate configuration in both 319 December 11, 1996 321 the relay agent and the server of the agent's circuit subnet masks. 322 A DHCP relay agent terminating a public data switched network may 323 have thousands of such configured circuits and masks. 325 DHCP relay agents SHALL remove any incoming Agent Subnet Mask options 326 on received broadcasted DHCP Discover/Request packets from clients. 327 This option is only appropriately added by the relay agent 328 implementing a LIS interface. 330 Code Len Agent Subnet Mask 331 +------+------+------+------+------+------+ 332 | 84 | 4 | m1 | m2 | m3 | m4 | 333 +------+------+------+------+------+------+ 335 3.0 Issues Resolved 337 Broadcast Forwarding 339 The circuit access equipment forwards the normally broadcasted 340 DHCP response only on the circuit indicated in the Agent Circuit 341 ID. 343 DHCP LIS selection 345 The DHCP server MAY use the "Gateway IP Address" to select the 346 Logical IP subnet from which to assign IP addresses. It may select 347 either the Subnet Mask provided by the forwarding relay agent, or 348 use local configuration information to select the Subnet Mask 349 based on giaddr (or other info in the DHCP request). 351 Note that the DHCP server SHOULD use the "giaddr" field of the 352 relayed DHCP request for the Router Option reported to the host. 354 DHCP Address Exhaustion 356 In general, the DHCP server may be extended to maintain a database 357 with the "triplet" of 359 (client IP address, client MAC address, client remote ID) 361 December 11, 1996 363 The DHCP server SHOULD implement policies that restrict the number 364 of IP addresses to be assigned to a single remote ID. 366 Static Assignment 368 The DHCP server may use the remote ID to select the IP address to 369 be assigned. It may permit static assignment of IP addresses to 370 particular remote IDs, and disallow an address request from an 371 unauthorized remote ID. 373 IP Spoofing 375 The circuit access device may associate the IP address assigned by 376 a DHCP server in a forwarded DHCP Ack packet with the circuit to 377 which it was forwarded. The circuit access device MAY prevent 378 forwarding of IP packets with source IP addresses -other than- 379 those it has associated with the receiving circuit. This prevents 380 simple IP spoofing attacks on the Central Lan, and IP spoofing of 381 other hosts. 383 Client Identifer Spoofing 385 By using the agent-supplied Agent Remote ID option, the untrusted 386 and as-yet unstandardized client identifer field need not be used 387 by the DHCP server. 389 MAC Address Spoofing 391 By associating a MAC address with an Agent Remote ID, the DHCP 392 server can prevent offering an IP address to an attacker on a 393 different remote ID. 395 4.0 References 397 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 1531 399 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor Extension" 400 RFC 1533. 402 5.0 Author's Address 404 December 11, 1996 406 Michael Patrick 407 Motorola Information Systems Group 408 20 Cabot Blvd., MS M4-30 409 Mansfield, MA 02048 411 Phone: (508) 261-5707 412 Email: mpatrick@dma.isg.mot.com