[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 3046

DHC  Working Grop                                      Michael Patrick
<draft-ietf-dhc-agent-options-01.txt>                  Motorola ISG
                                                       June 6, 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 December 1997                                           [Page 1]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


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
           ---  --------           -----------
           -01  06/06/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
   central point.  The PPP protocol is widely used to assign IP
   addresses to be used by the single host PC.



Expires December 1997                                           [Page 2]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


   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
   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



Expires December 1997                                           [Page 3]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


   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:

   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;

   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.  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 December 1997                                           [Page 4]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


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.


   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



Expires December 1997                                           [Page 5]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


   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
   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.







Expires December 1997                                           [Page 6]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


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 December 1997                                           [Page 7]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


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 December 1997                                           [Page 8]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


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.

   DHCP Address Exhaustion

      In general, the DHCP server may be extended to maintain a database
      with the "triplet" of



Expires December 1997                                           [Page 9]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997




                  (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.

5.0 References

        [1]     Droms, R. "Dynamic Host Configuration Protocol", RFC 1531

        [2]     Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor Extension"
                RFC 1533.






Expires December 1997                                          [Page 10]


<draft-ietf-dhc-agent-options-01.txt>                  February 11, 1997


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: mpatrick@dma.isg.mot.com

































Expires December 1997                                          [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/