Relay Agent Options "00.1"
"Michael W. Patrick" <email@example.com> Mon, 05 May 1997 18:31 UTC
Received: from cnri by ietf.org id aa25486; 5 May 97 14:31 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa16674; 5 May 97 14:31 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/22.214.171.124/17Jul96-0109PM) id AA01786; Mon, 5 May 1997 14:17:29 -0400
Date: Mon, 5 May 1997 14:17:29 -0400
From: "Michael W. Patrick" <firstname.lastname@example.org>
To: Multiple recipients of list <email@example.com>
Subject: Relay Agent Options "00.1"
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
DHCP-v4 Group, In accordance with the discussion at Memphis, I've updated <draft-ietf-dhc-agent-options-00.txt> to have only two agent-supplied options, and to encode them as "sub-options" of a single "Relay Agent Information" option. I'll make a separate draft for the "Agent subnet mask" option, since that requires more discussion. I'm not sure what the draft update procedures of the group are. I'd like to just submit this "00.1" draft to the mailing list for comment. After comments are incoporated, I'll send it to the I-D directory as "-01". This draft also clarifies what to do when the options already exist, and specifies that the Router Information Option must not be in the overloaded fields (since doing so makes it MUCH harder for a server to reconstruct the "original" packet for DHCP authentication purposes). This draft should resolve all of the significant issues raised at Memphis. I'm hoping that after a couple of weeks, I can incorporate comments on the list, and then release a -01 draft for "working group last call" on the list, i.e. a further 30-day period after which Ralph can forward to IESG. The 00.1 draft is attached (12 pages). -mike ------------------------------------------------------------------------ Michael W. Patrick Motorola ISG/NSD 20 Cabot Rd, MS M4-30 firstname.lastname@example.org (508) 261-5707 Mansfield MA 02048 DHC Working Grop Michael Patrick <draft-ietf-dhc-agent-options-00.1.txt> Motorola ISG May 1, 1997 DHCP Relay Agent Information Option Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more user hosts. It is advantageous to use DHCP to assign user host IP addresses in this environment, but a number of security and scaling problems arise with such "public" DHCP use. This draft calls for the definition of a "DHCP Relay Agent Information" option that is appended to a DHCP packet forwarded from a client to a server by a relay agent. The Server may or may not use the information in the the Relay Agent Information option; in either case, it echoes back the option verbatim in server-to-client replies. The "Relay Agent Information" option contains sub-options that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit and a "remote ID" which provides a trusted identifier for the remote high-speed modem. Expires November 1997 [Page 1] Table of Contents 1 Introduction........................................... 2 1.1 High-Speed Circuit Switched Data Networks.............. 2 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4 2.0 Relay Agent Information Option......................... 6 2.1 Agent Operation........................................ 7 2.2 Server Operation....................................... 8 3.0 Relay Agent Information Suboptions..................... 9 3.1 Agent Circuit ID....................................... 9 3.2 Agent Remote ID........................................ 10 4.0 Issues Resolved........................................ 10 5.0 References............................................. 12 6.0 Glossary............................................... 12 7.0 Author's Address....................................... 12 Revision History Rev Date Description --- -------- ----------- -00.1 05/01/97 Updated per March 97 IETF review: Organize as one DHCP option with sub-options. Clarify operation when option already present. Move Agent Subnet Mask option to separate document. -00 12/11/96 Original 1 Introduction 1.1 High-Speed Circuit Switched Data Networks Public Access to the Internet is usually via a circuit switched data network. Today, this is primarily implemented with dial-up modems connecting to a Remote Access Server. But higher speed circuit access networks also include ISDN, ATM, Frame Relay, and Cable Data Networks. All of these networks can be characterized as a "star" topology where multiple users connect to a "circuit access unit" via switched or permanent circuits. With dial-up modems, only a single host PC attempts to connect to the Expires November 1997 [Page 2] central point. The PPP protocol is widely used to assign IP addresses to be used by the single host PC. The newer high-speed circuit technologies, however, frequently provide a LAN interface (especially Ethernet) to one or more host PCs. It is desirable to support centralized assignment of the IP addresses of host computers connecting on such circuits via DHCP. The DHCP server can be, but usually is not, co-implemented with the centralized circuit concentration access device. The DHCP server is often connected as a separate server on the "Central LAN" to which the central access device (or devices) attach. A common physical model for high-speed Internet circuit access is shown in Figure 1, below. +---------------+ | Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A LAN | | Access | Lan |- Host B | | Unit 1 | |- Host C |-----| |-- | | |(relay agent) |... +---------+ | +---------------+ | DHCP |--| | Server | | +---------+ | | | +---------------+ +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D | Other | | | Access | Lan | Servers |--|-----| Unit 2 | | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E | DNS) | | |(relay agent) |... Lan | | +---------------+ +---------+ Figure 1: DHCP High Speed Circuit Access Model Note that in this model, the "modem" connects to a LAN at the user site, rather than to a single host. Multiple hosts are implemented at this site. Although it is certainly possible to implement a full IP router at the user site, this requires a relatively expensive piece of equipment (compared to typical modem costs). Furthermore, a Expires November 1997 [Page 3] router requires an IP address not only for every host, but for the router itself. Finally, a user-side router requires a dedicated Logical IP Subnet (LIS) for each user. While this model is appropriate for relatively small corporate networking environments, it is not appropriate for large, public accessed networks. In this scenario, it is advantageous to implement an IP networking model that does not allocate an IP address for the modem (or other networking equipment device at the user site), and especially not an entire LIS for the user side LAN. 1.2 DHCP Relay Agent in the Circuit Access Unit It is desirable to use DHCP to assign the IP addresses for public high-speed circuit access. A number of circuit access units (e.g. RAS's, cable modem termination systems, ADSL access units, etc) connect to a LAN (or local internet) to which is attached a DHCP server. For scaling and security reasons, it is advantageous to implement a "router hop" at the circuit access unit, much like high-capacity RAS's do today. The circuit access equipment acts as both a router to the circuits and as the DHCP relay agent. The advantages of co-locating the DHCP relay agent with the circuit access equipment are: 1. DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DCHP reply broadcast onto thousands of access circuits; 2. The same mechanism used to identify the remote connection of the circuit (e.g. a user ID requested by a Remote Access Server acting as the circuit access equipment) may be used as a host identifier by DHCP, and used for parameter assignment. This includes centralized assignment of IP addresses to hosts. This provides a secure remote ID from a trusted source -- the relay agent. A number of issues arise when forwarding DHCP requests from hosts connecting publicly accessed high-speed circuits with LAN connections at the host. Many of these are security issues arising from DHCP client requests from untrusted sources. Expires November 1997 [Page 4] - How does the relay agent know to which circuit to forward replies? - How does the system prevent DHCP IP exhaustion attacks? This is when an attacker requests all available IP addresses from a DHCP server by sending requests with fabricated client MAC addresses. - How can an IP address or LIS be permanently assigned to a particular user or modem? - How does one prevent "spoofing" of client identifer fields used to assign IP addresses? - How does one prevent denial of service by "spoofing" other client's MAC addresses? All of these issues may be addressed by having the circuit access equipment, which is a trusted component, add information to DHCP client requests that it forwards to the DHCP server. Expires November 1997 [Page 5] 2.0 Relay Agent Information Option This document defines a new DHCP Option called the Relay Agent Information Option. It is a "container" option for specific agent- supplied sub-options. The format of the Relay Agent Information option is: Code Len Agent Information Field +------+------+------+------+------+------+--...-+------+ | 82 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner: SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 1 | N | s1 | s2 | s3 | s4 | | sN | +------+------+------+------+------+------+--...-+------+ SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 2 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ No "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. Expires November 1997 [Page 6] Sub-option codes shall be assigned by IANA. The initial assignment shall be as follows: DHCP Agent Sub-Option Descrption Sub-option Code --------------- ---------------------- 1 Agent Circuit ID Sub-option 2 Agent Remote ID Sub-option Future drafts may define additional Relay Agent Information sub- options. 2.1 Agent Operation A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last DHCP agent option in the DHCP options field of any recognized DHCP packet forwarded from a client to a server. Such additions shall be made for only those packets recognized as DHCP; BOOTP-only packets shall not be affected. Relay agents receiving a DHCP packet with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count. Relay agents supporting the Relay Agent Information option SHOULD have separate configurables for each sub-option to control whether it is added to client-to-server packets. Relay agents SHOULD have a configurable for the maximum size of the DHCP packet to be created after appending the Agent Information option. Packets which, after appending the Relay Agent Information option, would exceed this configured maximum size shall be forwarded WITHOUT adding the Agent Information option. An error counter SHOULD be incremented in this case. In the absence of this configurable, the agent SHALL NOT exceed a size of 576 bytes for the IP MTU containing the modified DHCP packet. The default value of the configurable shall be 576 bytes. The Relay Agent Information option echoed by a server SHOULD be removed by the agent when forwarding a server-to-client response back to the client. The agent MAY choose to not remove the option when, for example, the Relay Agent Information field is not the last option Expires November 1997 [Page 7] in the server-to-client response. The agent SHALL NOT add an "Option Overload" option to the packet or use the "file" or "sname" fields for adding Relay Agent Information option. It SHALL NOT parse or remove Relay Agent Information options that may appear in the sname or file fields of a server-to-client packet forwarded through the agent. The operation of relay agents for specific sub-options is specified with that sub-option. 2.2 Server Operation DHCP servers unaware of the Relay Agent Information option SHOULD ignore the option upon receive and SHOULD not echo it back on responses. This is the specified server behaviour for unknown options. DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Servers SHALL NOT place the echoed Relay Agent Information option in the overloaded sname or file fields. If a server is unable to copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Information Field, and SHOULD increment an error counter for the situation. Servers using the DHCP Authentication option SHALL exclude the entirety of the Relay Agent Information option (including Code, Length, and Information fields) from the MAC authentication code calculation. The operation of DHCP servers for specific sub-options is specified with that sub-option. Expires November 1997 [Page 8] 3.0 Relay Agent Information Sub-options 3.1 Agent Circuit ID Sub-option This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit from which a DHCP client-to-server packet was received. It is intended for use by agents in relaying DHCP responses back to the proper circuit. Possible uses of this field include - Router interface number - Switching Hub port number - Remote Access Server port number - Frame Relay DLCI - ATM virtual circuit number - Cable Data virtual circuit number The format of the Agent Circuit ID may be further standardized by IETF working groups responsible for IP communication on that type of circuit. In the absence of such standardization, the format may proprietary to the relay agent vendor. Servers MAY use the information for IP and other parameter assignment policies, but care should be taken due to the potential proprietary format. The DHCP server SHOULD report the Agent Circuit ID value of current leases in statistical reports (including its MIB) and in logs. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value that identifies the relay agent. SubOpt Len Circuit ID +------+------+------+------+------+------+------+------+-- | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... +------+------+------+------+------+------+------+------+-- Expires November 1997 [Page 9] 3.2 Agent Remote ID Sub-option This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance: -- a "caller ID" telephone number for dial-up connection -- a "user name" prompted for by a Remote Access Server -- a remote caller ATM address -- a "modem ID" of a cable data modem -- the remote IP address of a point-to-point link -- a remote X.25 address for X.25 connections The format of the Agent Remote ID will depend on the type of circuit connected to the relay agent, and further specification of this field may be standardized by the IETF working groups responsible for IP communications on those circuit types. The only requirement is that the remote ID be administered as globally unique. DHCP servers MAY use this option to select parameters specific to particular users, hosts, or subscriber modems. The relay agent MAY use this field in addition to or instead of the Agent Circuit ID field to select the circuit on which to forward the DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this value in any reports or MIBs associated with a particular client. SubOpt Len Agent Remote ID +------+------+------+------+------+------+------+------+-- | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... +------+------+------+------+------+------+------+------+-- 4.0 Issues Resolved Broadcast Forwarding The circuit access equipment forwards the normally broadcasted DHCP response only on the circuit indicated in the Agent Circuit ID. Expires November 1997 [Page 10] DHCP Address Exhaustion In general, the DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client MAC address, client remote ID) The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID. Static Assignment The DHCP server may use the remote ID to select the IP address to be assigned. It may permit static assignment of IP addresses to particular remote IDs, and disallow an address request from an unauthorized remote ID. IP Spoofing The circuit access device may associate the IP address assigned by a DHCP server in a forwarded DHCP Ack packet with the circuit to which it was forwarded. The circuit access device MAY prevent forwarding of IP packets with source IP addresses -other than- those it has associated with the receiving circuit. This prevents simple IP spoofing attacks on the Central Lan, and IP spoofing of other hosts. Client Identifer Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifer field need not be used by the DHCP server. MAC Address Spoofing By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker on a different remote ID. Expires November 1997 [Page 11] 5.0 References  Droms, R. "Dynamic Host Configuration Protocol", RFC 1531  Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor Extension" RFC 1533. 6.0 Glossary IANA Internet Assigned Numbers Authority LIS Logical IP Subnet MAC Message Authentication Code RAS Remote Access Server 7.0 Author's Address Michael Patrick Motorola Information Systems Group 20 Cabot Blvd., MS M4-30 Mansfield, MA 02048 Phone: (508) 261-5707 Email: email@example.com Expires November 1997 [Page 12]