idnits 2.17.1 draft-ietf-dhc-agent-options-06.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 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. == 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 11) being 225 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 559: '...sub-option codes MUST be assigned by I...' RFC 2119 keyword, line 568: '...option SHOULD be configurable,...' RFC 2119 keyword, line 570: '... and SHOULD be disabled by default. ...' RFC 2119 keyword, line 571: '...agents SHOULD have separate...' RFC 2119 keyword, line 579: '...elay Agent Information field SHALL add...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 657 has weird spacing: '...s. This inclu...' == Line 917 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 5, 1999) is 9029 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Grop Michael Patrick 3 Motorola ING 5 August 5, 1999 7 DHCP Relay Agent Information 8 Option 10 Status of this Memo 12 This document is an Internet Draft. 13 Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet 22 Drafts are draft documents valid for a maximum of six months. Internet 23 Drafts may be updated, replaced, or obsoleted by other documents at any 24 time. It is not appropriate to use Internet Drafts as reference material 25 or to cite them other than as a "working draft" or "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Please check the "1id-abstracts.txt" listing contained in the 35 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 37 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US 38 East Coast), or ftp.isi.edu (US West Coast). 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [4]. 46 Abstract 48 Newer high-speed public Internet access technologies call for a 50 high-speed modem to have a LAN attachment to one or more customer 52 premise hosts. It is advantageous to use the Dynamic Host 54 Configuration Protocol as defined in RFC 2131 [1] to assign customer 56 premise host IP addresses in this environment. 57 However, a number of security and scaling problems arise with such 58 "public" DHCP use. This document describes a new DHCP option to address 59 these issues. This option extends the set of DHCP options as defined in 60 RFC 2132 [2]. 62 The new option is called the Relay Agent Information option and is 64 inserted by the DHCP relay agent when forwarding client-originated 66 DHCP packets to a DHCP server. Servers recognizing the Relay Agent 68 Information option may use the information to implement IP address or 70 other parameter assignment policies. The DHCP Server echoes the 72 option back verbatim to the relay agent in server-to-client replies, 74 and the relay agent strips the option before forwarding the reply to 76 Expires February 2000 [Page 77 1] 79 August 5, 80 1999 82 the client. 84 The "Relay Agent Information" option is organized as a single DHCP 86 option that contains one or more "sub-options" that convey 88 information known by the relay agent. The initial sub-options are 90 defined for a relay agent that is co-located in a public circuit 92 access unit. These include a "circuit ID" for the incoming circuit, a 93 "remote ID" which provides a trusted identifier for the remote high-speed 94 modem, and the "subnet mask" of the logical IP subnet from which the 95 relay agent received the client DHCP packet. 97 Table of Contents 99 1 100 Introduction........................................... 3 102 1.1 103 High-Speed Circuit Switched Data Networks.............. 3 105 1.2 DHCP 106 Relay Agent in the Circuit Access Equipment....... 4 108 2.0 Relay Agent 109 Information Option......................... 6 111 2.1 Agent 112 Operation........................................ 7 114 2.1.1 115 Reforwarded DHCP requests............................ 8 117 2.2 Server 118 Operation....................................... 8 120 3.0 Relay Agent 121 Information Suboptions..................... 9 123 3.1 Agent Circuit 124 ID....................................... 9 126 3.2 Agent Remote 127 ID........................................ 10 129 3.3 Agent Subnet 130 Mask...................................... 11 132 4.0 Issues 133 Resolved........................................ 11 135 5.0 Security 136 Considerations................................ 12 138 6.0 IANA 139 Considerations.................................... 13 141 7.0 142 Intellectual Property Notice........................... 13 144 8.0 145 References............................................. 14 147 9.0 148 Glossary............................................... 14 150 10.0 151 Author's Address...................................... 14 153 Revision History 155 Rev Date Description 157 --- 158 -------- ----------- 160 -06 4/8/99 Added 161 editorial paragraph at end of 1.1 noting 163 that some host lan installations may not rely 165 on a centralized DHCP server. 167 Added 168 editorial pararaph at end of 5.0 noting 170 the 171 security risks of automatically reforward- 173 ing IP/ARP packets back downstream. 175 Expires February 2000 177 178 August 5, 1999 180 1 Introduction 182 1.1 High-Speed Circuit Switched Data 183 Networks 185 Public Access to the Internet is usually via a circuit switched 186 data 188 network. Today, this is primarily implemented with dial-up modems 190 connecting to a Remote Access Server. But higher speed circuit 192 access 193 networks also include ISDN, ATM, Frame Relay, and Cable Data 195 Networks. 196 All of these networks can be characterized as a "star" 198 topology where 199 multiple users connect to a "circuit access unit" via 201 switched or 202 permanent circuits. 204 With dial-up modems, only a single host PC attempts 205 to connect to the 207 central point. The PPP protocol is widely used to 208 assign IP 210 addresses to be used by the single host PC. 212 The newer 213 high-speed circuit technologies, however, frequently 215 provide a LAN 216 interface (especially Ethernet) to one or more host 218 PCs. It is desirable 219 to support centralized assignment of the IP 221 addresses of host computers 222 connecting on such circuits via DHCP. 224 The DHCP server can be, but usually 225 is not, co-implemented with the 227 centralized circuit concentration access 228 device. The DHCP server is 230 often connected as a separate server on the 231 "Central LAN" to which 233 the central access device (or devices) attach. 235 A common physical model for high-speed Internet circuit access is 237 shown 238 in Figure 1, below. 240 Expires February 2000 242 243 August 5, 1999 245 +---------------+ 246 | 248 Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host 249 A 251 LAN | | Access | Lan |- Host 252 B 254 | | Unit 1 | |- Host 255 C 257 |-----| |-- | 259 | |(relay agent) |... 261 +---------+ | +---------------+ 263 | 264 DHCP |--| 266 | Server | | 268 +---------+ | 270 | 272 | +---------------+ 274 +---------+ | | Circuit |-- ckt 1--- 275 Modem2-- Host--- Host D 277 | Other | | | Access | 278 Lan 280 | Servers |--|-----| Unit 2 | 282 | (Web, | | | 283 |-- ckt 2--- Modem3-- Host--- Host E 285 | DNS) | | |(relay agent) 286 |... Lan 288 | | +---------------+ 290 +---------+ 292 Figure 1: DHCP High Speed Circuit Access Model 294 Note that in this model, the "modem" connects to a LAN at the user 296 site, 297 rather than to a single host. Multiple hosts are implemented at 299 this 300 site. Although it is certainly possible to implement a full IP 302 router at 303 the user site, this requires a relatively expensive piece 305 of equipment 306 (compared to typical modem costs). Furthermore, a 308 router requires an IP 309 address not only for every host, but for the 311 router itself. Finally, a 312 user-side router requires a dedicated 314 Logical IP Subnet (LIS) for each 315 user. While this model is 317 appropriate for relatively small corporate 318 networking environments, 320 it is not appropriate for large, public accessed 321 networks. In this 323 scenario, it is advantageous to implement an IP 324 networking model that 326 does not allocate an IP address for the modem (or 327 other networking 329 equipment device at the user site), and especially not 330 an entire LIS 332 for the user side LAN. 334 Note that using this method to 335 obtain IP addresses means that IP 337 addresses can only be obtained while 338 communication to the central 340 site is available. Some host lan 341 installations may use a local DHCP 343 server or other methods to obtain IP 344 addresses for in-house use. 346 Expires February 2000 348 349 August 5, 1999 351 1.2 DHCP Relay Agent in the Circuit Access Unit 353 It is 354 desirable to use DHCP to assign the IP addresses for public 356 high-speed 357 circuit access. A number of circuit access units (e.g. 359 RAS's, cable 360 modem termination systems, ADSL access units, etc) 362 connect to a LAN (or 363 local internet) to which is attached a DHCP 365 server. 367 For scaling and 368 security reasons, it is advantageous to implement a 370 "router hop" at the 371 circuit access unit, much like high-capacity 373 RAS's do today. The circuit 374 access equipment acts as both a router 376 to the circuits and as the DHCP 377 relay agent. 379 The advantages of co-locating the DHCP relay agent with the 380 circuit 382 access equipment are: 384 DHCP broadcast replies can be routed to 385 only the proper circuit, 387 avoiding, say, the replication of the DCHP reply 388 broadcast onto 390 thousands of access circuits; 392 The same mechanism used 393 to identify the remote connection of the 395 circuit (e.g. a user ID 396 requested by a Remote Access Server acting as 398 the circuit access 399 equipment) may be used as a host identifier by 401 DHCP, and used for 402 parameter assignment. This includes centralized 404 assignment of IP 405 addresses to hosts. This provides a secure remote 407 ID from a trusted 408 source -- the relay agent. 410 A number of issues arise when forwarding DHCP 411 requests from hosts 413 connecting publicly accessed high-speed circuits with 414 LAN connections 416 at the host. Many of these are security issues arising 417 from DHCP 419 client requests from untrusted sources. How does the relay 420 agent 422 know to which circuit to forward replies? How does the system 424 prevent DHCP IP exhaustion attacks? This is when an attacker 426 requests 427 all available IP addresses from a DHCP server by sending 429 requests with 430 fabricated client MAC addresses. How can an IP address 432 or LIS be 433 permanently assigned to a particular user or modem? How 435 does one prevent 436 "spoofing" of client identifer fields used to assign 438 IP addresses? How 439 does one prevent denial of service by "spoofing" 441 other client's MAC 442 addresses? 444 All of these issues may be addressed by having the circuit 445 access 447 equipment, which is a trusted component, add information to DHCP 449 client requests that it forwards to the DHCP server. 451 Expires 452 February 2000 [Page 453 5] 455 August 5, 456 1999 458 2.0 Relay Agent Information Option 460 This document defines a new 461 DHCP Option called the Relay Agent 463 Information Option. It is a 464 "container" option for specific agent- 466 supplied sub-options. The format 467 of the Relay Agent Information 469 option is: 471 Code Len 472 Agent Information Field 474 +------+------+------+------+------+------+--...-+------+ 476 | 82 477 | N | i1 | i2 | i3 | i4 | | iN | 479 +------+------+------+------+------+------+--...-+------+ 481 The length N 482 gives the total number of octets in the Agent 484 Information Field. The 485 Agent Information field consists of a sequence 487 of SubOpt/Length/Value 488 tuples for each sub-option, encoded in the 490 following manner: 492 SubOpt Len Sub-option Value 494 +------+------+------+------+------+------+--...-+------+ 496 | 1 497 | N | s1 | s2 | s3 | s4 | | sN | 499 +------+------+------+------+------+------+--...-+------+ 501 SubOpt 502 Len Sub-option Value 504 +------+------+------+------+------+------+--...-+------+ 506 | 2 507 | N | i1 | i2 | i3 | i4 | | iN | 509 +------+------+------+------+------+------+--...-+------+ 511 No "pad" 512 sub-option is defined, and the Information field shall NOT 514 be terminated 515 with a 255 sub-option. The length N of the DHCP Agent 517 Information Option 518 shall include all bytes of the sub-option 520 code/length/value tuples. Since 521 at least one sub-option must be 523 defined, the minimum Relay Agent 524 Information length is two (2). The 526 length N of the sub-options shall be 527 the number of octets in only 529 that sub-option's value field. A sub-option 530 length may be zero. The 532 sub-options need not appear in sub-option code 533 order. 535 The initial assignment of DHCP Relay Agent Sub-options is as 536 follows: 538 DHCP Agent Sub-Option Descrption 540 Sub-option Code 542 --------------- 543 ---------------------- 545 1 Agent 546 Circuit ID Sub-option 548 2 Agent 549 Remote ID Sub-option 551 3 Agent Subnet 552 Mask Sub-option 554 Expires February 2000 556 557 August 5, 1999 559 New sub-option codes MUST be assigned by IANA according 560 to the policy 562 described in the "IANA Considerations" section of this 563 document. 565 2.1 Agent Operation 567 Overall adding of the DHCP relay agent 568 option SHOULD be configurable, 570 and SHOULD be disabled by default. Relay 571 agents SHOULD have separate 573 configurables for each sub-option to control 574 whether it is added to 576 client-to-server packets. 578 A DHCP relay agent 579 adding a Relay Agent Information field SHALL add 581 it as the last DHCP 582 agent option in the DHCP options field of any 584 recognized DHCP packet 585 forwarded from a client to a server. Such 587 additions shall be made for 588 only those packets recognized as DHCP; 590 BOOTP-only packets shall not be 591 affected. 593 Relay agents receiving a DHCP packet with giaddr set to zero 595 (indicating that they are the first-hop router) but with a Relay 597 Agent 598 Information option already present in the packet SHALL discard 600 the packet 601 and increment an error count. 603 Relay agents MAY have a configurable for 604 the maximum size of the DHCP 606 packet to be created after appending the 607 Agent Information option. 609 Packets which, after appending the Relay Agent 610 Information option, 612 would exceed this configured maximum size shall be 613 forwarded WITHOUT 615 adding the Agent Information option. An error counter 616 SHOULD be 618 incremented in this case. In the absence of this configurable, 619 the 621 agent SHALL NOT increase a forwarded DHCP packet size to exceed the 623 MTU of the interface on which it is forwarded. 625 The Relay Agent 626 Information option echoed by a server MUST be removed 628 by the agent when 629 forwarding a server-to-client response back to the 631 client. 633 The agent 634 SHALL NOT add an "Option Overload" option to the packet or 636 use the "file" 637 or "sname" fields for adding Relay Agent Information 639 option. It SHALL 640 NOT parse or remove Relay Agent Information options 642 that may appear in 643 the sname or file fields of a server-to-client 645 packet forwarded through 646 the agent. 648 The operation of relay agents for specific sub-options is 649 specified 651 with that sub-option. 653 Relay agents are NOT required to 654 monitor or modify client-originated 656 DHCP packets addressed to a server 657 unicast address. This includes 659 the DHCP-REQUEST sent when entering the 660 RENEWING state. 662 Expires February 2000 664 665 August 5, 1999 667 2.1.1 Reforwarded DHCP requests 669 A DHCP relay agent may 670 receive a client DHCP packet forwarded from a 672 BOOTP/DHCP relay agent 673 closer to the client. Such a packet will have 675 giaddr as non-zero, and may 676 or may not already have a DHCP Relay 678 Agent option in it. 680 Relay agents 681 configured to add a Relay Agent option which receive a 683 client DHCP packet 684 with a nonzero giaddr SHALL discard the packet if 686 the giaddr spoofs a 687 giaddr address implemented by the local agent 689 itself. 691 Otherwise, the 692 relay agent SHALL forward any received DHCP packet 694 with a valid non-zero 695 giaddr WITHOUT adding any relay agent options. 697 Per RFC 2131, it shall 698 also NOT modify the giaddr value. 700 2.2 Server Operation 702 DHCP 703 servers unaware of the Relay Agent Information option will 705 ignore the 706 option upon receive and will not echo it back on 708 responses. This is the 709 specified server behavior for unknown 711 options. 713 DHCP servers claiming 714 to support the Relay Agent Information option 716 SHALL echo the entire 717 contents of the Relay Agent Information option 719 in all replies. Servers 720 SHOULD copy the Relay Agent Information 722 option as the last DHCP option in 723 the response. Servers SHALL NOT 725 place the echoed Relay Agent Information 726 option in the overloaded 728 sname or file fields. If a server is unable to 729 copy a full Relay 731 Agent Information field into a response, it SHALL send 732 the response 734 without the Relay Information Field, and SHOULD increment an 735 error 737 counter for the situation. 739 The operation of DHCP servers for 740 specific sub-options is specified 742 with that sub-option. 744 Note that 745 DHCP relay agents are not required to monitor unicast DHCP 747 messages sent 748 directly between the client and server (i.e, those that 750 aren't sent via a 751 relay agent). However, some relay agents MAY chose 753 to do such monitoring 754 and add relay agent options. Consequently, 756 servers SHOULD be prepared to 757 handle relay agent options in unicast 759 messages, but MUST NOT expect them 760 to always be there. 762 Expires February 2000 764 765 August 5, 1999 767 3.0 Relay Agent Information Sub-options 769 3.1 Agent Circuit 770 ID Sub-option 772 This sub-option MAY be added by DHCP relay agents which 773 terminate 775 switched or permanent circuits. It encodes an agent-local 776 identifier 778 of the circuit from which a DHCP client-to-server packet was 780 received. It is intended for use by agents in relaying DHCP 782 responses 783 back to the proper circuit. Possible uses of this field 785 include 787 - 788 Router interface number 790 - Switching Hub port number 792 - Remote 793 Access Server port number 795 - Frame Relay DLCI 797 - ATM virtual 798 circuit number 800 - Cable Data virtual circuit number 802 Servers MAY 803 use the Circuit ID for IP and other parameter assignment 805 policies. The 806 Circuit ID SHOULD be considered an opaque value, with 808 policies based on 809 exact string match only; that is, the Circuit ID 811 SHOULD NOT be internally 812 parsed by the server. 814 The DHCP server SHOULD report the Agent Circuit ID 815 value of current 817 leases in statistical reports (including its MIB) and in 818 logs. Since 820 the Circuit ID is local only to a particular relay agent, a 821 circuit 823 ID should be qualified with the giaddr value that identifies the 825 relay agent. 827 SubOpt Len Circuit ID 829 +------+------+------+------+------+------+------+------+-- 831 | 1 832 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... 834 +------+------+------+------+------+------+------+------+-- 836 Expires February 2000 [Page 837 9] 839 August 5, 840 1999 842 3.2 Agent Remote ID Sub-option 844 This sub-option MAY be added by 845 DHCP relay agents which terminate 847 switched or permanent circuits and have 848 mechanisms to identify the 850 remote host end of the circuit. The Remote ID 851 field may be used to 853 encode, for instance: 855 -- a "caller ID" 856 telephone number for dial-up connection 858 -- a "user name" prompted for 859 by a Remote Access Server 861 -- a remote caller ATM address 863 -- a 864 "modem ID" of a cable data modem 866 -- the remote IP address of a 867 point-to-point link 869 -- a remote X.25 address for X.25 connections 871 The remote ID MUST be globally unique. 873 DHCP servers MAY use this option 874 to select parameters specific to 876 particular users, hosts, or subscriber 877 modems. The option SHOULD be 879 considered an opaque value, with policies 880 based on exact string match 882 only; that is, the option SHOULD NOT be 883 internally parsed by the 885 server. 887 The relay agent MAY use this field 888 in addition to or instead of the 890 Agent Circuit ID field to select the 891 circuit on which to forward the 893 DHCP reply (e.g. Offer, Ack, or Nak). 894 DHCP servers SHOULD report this 896 value in any reports or MIBs associated 897 with a particular client. 899 SubOpt Len Agent Remote ID 901 +------+------+------+------+------+------+------+------+-- 903 | 2 904 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... 906 +------+------+------+------+------+------+------+------+-- 908 Expires February 2000 [Page 909 10] 911 August 5, 912 1999 914 3.3 Agent Subnet Mask Sub-option 916 This sub-option MAY be added by 917 DHCP relay agents to identify the 919 subnet mask of the Logical IP Subnet 920 (LIS) from which the client DHCP 922 packet was received. The LIS of the 923 client is defined as the subnet 925 formed by the giaddr ANDed with the 926 Agent Subnet Mask. 928 Servers MAY use this mask field to automatically 929 create scopes of 931 assignable IP addresses. Use of this field avoids the 932 need to have 934 identical configuration of the logical IP subnets on which 935 clients 937 reside in both the relaying routers and the DHCP server. In 938 this 940 case, the router configuration defines the LISs, and the DHCP 941 servers 943 automatically discover the LISs from the relay agent options of 945 forwarded client DHCP requests. 947 SubOpt Len Agent Subnet 948 Mask 950 +------+------+------+------+------+------+ 952 | 3 953 | 4 | m1 | m2 | m3 | m4 | 955 +------+------+------+------+------+------+ 957 4.0 Issues Resolved 959 Broadcast Forwarding 961 The circuit access equipment forwards the 962 normally broadcasted 964 DHCP response only on the circuit indicated in 965 the Agent Circuit 967 ID. 969 DHCP Address Exhaustion 971 In general, 972 the DHCP server may be extended to maintain a database 974 with the 975 "triplet" of 977 (client IP address, client MAC address, 978 client remote ID) 980 The DHCP server SHOULD implement policies that 981 restrict the number 983 of IP addresses to be assigned to a single remote 984 ID. 986 Expires February 2000 988 989 August 5, 1999 991 Static Assignment 993 The DHCP server may use the 994 remote ID to select the IP address to 996 be assigned. It may permit 997 static assignment of IP addresses to 999 particular remote IDs, and 1000 disallow an address request from an 1002 unauthorized remote ID. 1004 IP 1005 Spoofing 1007 The circuit access device may associate the IP address 1008 assigned by 1010 a DHCP server in a forwarded DHCP Ack packet with the 1011 circuit to 1013 which it was forwarded. The circuit access device MAY 1014 prevent 1016 forwarding of IP packets with source IP addresses -other 1017 than- 1019 those it has associated with the receiving circuit. This 1020 prevents 1022 simple IP spoofing attacks on the Central LAN, and IP 1023 spoofing of 1025 other hosts. 1027 Client Identifer Spoofing 1029 By using 1030 the agent-supplied Agent Remote ID option, the untrusted 1032 and as-yet 1033 unstandardized client identifer field need not be used 1035 by the DHCP 1036 server. 1038 MAC Address Spoofing 1040 By associating a MAC address with an 1041 Agent Remote ID, the DHCP 1043 server can prevent offering an IP address to 1044 an attacker spoofing 1046 the same MAC address on a different remote 1047 ID. 1049 5.0 Security Considerations 1051 DHCP as currently defined provides no 1052 authentication or security 1054 mechanisms. Potential exposures to attack are 1055 discussed in section 7 1057 of the DHCP protocol specification in RFC 2131 1058 [1]. 1060 This document introduces mechanisms to address several security 1062 attacks on the operation of IP address assignment, including IP 1064 spoofing, 1065 Client ID spoofing, MAC address spoofing, and DHCP server 1067 address 1068 exhaustion. It relies on an implied trusted relationship 1070 between the DHCP 1071 Relay Agent and the DHCP server, with an assumed 1073 untrusted DHCP client. 1074 It introduces a new identifer, the "Remote 1076 ID", that is also assumed to 1077 be trusted. The Remote ID is provided by 1079 the access network or modem and 1080 not by client premise equipment. 1082 Cryptographic or other techniques to 1083 authenticate the remote ID are 1085 certainly possible and encouraged, but are 1086 beyond the scope of this 1088 document. 1090 Expires February 2000 1092 1093 August 5, 1999 1095 Note that any future mechanisms for authenticating DHCP 1096 client to 1098 server communications must take care to omit the DHCP Relay 1099 Agent 1101 option from server authentication calculations. This was the 1103 principal reason for organizing the DHCP Relay Agent Option as a 1105 single 1106 option with sub-options, and for requiring the relay agent to 1108 remove the 1109 option before forwarding to the client. 1111 While it is beyond the scope of 1112 this document to specify the general 1114 forwarding algorithm of public data 1115 circuit access units, note that 1117 automatic reforwarding of IP or ARP 1118 broadcast packets back downstream 1120 exposes serious IP security risks. For 1121 example, if an upstream 1123 broadcast DHCP-DISCOVER or DHCP-REQUEST were 1124 re-broadcast back 1126 downstream, any public host may easily spoof the 1127 desired DHCP server. 1129 6.0 IANA Considerations 1131 IANA is required to 1132 maintain a new number space of "DHCP Relay Agent 1134 Sub-options", with the 1135 initial sub-options as described in this 1137 document. 1139 IANA MUST assign 1140 future DHCP Relay Agent Sub-options with a "IETF 1142 Consensus" policy as 1143 described in RFC 2434 [3]. Future proposed 1145 sub-options MUST be 1146 referenced symbolically in the internet-drafts 1148 that describe them, and 1149 shall be assigned numeric codes by IANA when 1151 and if the draft is approved 1152 by IESG for Proposed Standard RFC 1154 status. 1156 7.0 Intellectual Property 1157 Notices 1159 This section contains two notices as required by [5] for 1160 standards 1162 track documents. 1164 Per [5], section 10.4(A): 1166 The IETF 1167 takes no position regarding the validity or scope of any 1169 intellectual 1170 property or other rights that might be claimed to 1172 pertain to the 1173 implementation or use of the technology described in 1175 this document or the 1176 extent to which any license under such rights 1178 might or might not be 1179 available; neither does it represent that it 1181 has made any effort to 1182 identify any such rights. Information on the 1184 IETF's procedures with 1185 respect to rights in standards-track and 1187 standards-related documentation 1188 can be found in BCP-11. Copies of 1190 claims of rights made available for 1191 publication and any assurances of 1193 licenses to be made available, or the 1194 result of an attempt made to 1196 obtain a general license or permission for 1197 the use of such 1199 proprietary rights by implementors or users of this 1200 specification can 1202 be obtained from the IETF Secretariat. 1204 Expires 1205 February 2000 [Page 1206 13] 1208 August 5, 1209 1999 1211 Per [5] section 10.4(D): 1213 The IETF has been notified of 1214 intellectual property rights claimed in 1216 regard to some or all of the 1217 specification contained in this 1219 document. For more information consult 1220 the online list of claimed 1222 rights. 1224 8.0 References 1226 [1] 1227 Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 1229 Bucknell University, March 1997. 1231 [2] Alexander,S. and Droms, 1232 R., "DHCP Options and BOOTP Vendor 1234 Extension" RFC 2132. 1236 [3] Narten,T. and Alvestrand, H. "Guidelines for Writing an 1238 IANA Considerations Section in RFCs", RFC 2434. 1240 [4] Bradner, S. 1241 "Key words for use in RFCs to Indicate Requirement 1243 Levels", 1244 RFC 2119. 1246 [5] Bradner, S. "The Internet Standards Process -- 1247 Revision 3", 1249 RFC 2026 1251 9.0 Glossary 1253 IANA 1254 Internet Assigned Numbers Authority 1256 LIS Logical IP Subnet 1258 MAC Message Authentication Code 1260 RAS Remote Access 1261 Server 1263 10.0 Author's Address DS 1265 Michael Patrick 1267 Motorola 1268 Information Systems Group 1270 20 Cabot Blvd., MS M4-30 1272 Mansfield, 1273 MA 02048 1275 Phone: (508) 261-5707 1277 Email: 1278 mpatrick@dma.isg.mot.com 1280 Expires February 2000