IPSEC Working Group                          Baiju V. Patel,
   INTERNET-DRAFT                              Intel Corporation
   draft-ietf-ipsec-dhcp-01.txt                December 29, 1998
  
  
           Dynamic configuration of IPSEC VPN host using DHCP
  
  
   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 made obsolete
   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".
  
   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.
  
   A revision of this draft document will be submitted to the RFC
   editor as a Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested.  This
   document will expire February 1998. Distribution of this draft is
   unlimited.
  
  
  
   1.  Introduction
  
  
   IPSEC [2] is a protocol suite defined by IETF working group on IP
   security to secure communication at the network layer between
   communicating peers. Among many applications enabled by IPSEC, an
   interesting and useful application is connect a remote host (e.g.,
   roaming user) to the intranet through SNG (or secure network
   gateway) using IPSEC tunnels. A remote host on the public internet
   would connect to a secure network gateway and then establish an
   IPSEC tunnel between itself and SNG. All the traffic between the
   remote host and the intranet will be carried over the IPSEC tunnel
   via SNG as shown in the figure.
  
  
  
  
  
  
  
  
  
  
   Patel                                                          1
  
               draft-ietf-ipsec-dhcp-01.txt      12/29/98
  
  
   ---------------    |----------|    |---------|   |----------|
   | Remote Host |----|Internet  |----|SNG      |---| Intranet |
   ---------------    |----------|    |----------   |----------|
                                                          |
                 |<--IPSEC Tunnel ---->                   |
                                                    |-------------|
                                                    | DHCP Server |
                                                    |-------------|
  
  
   A typical configuration of the remote host in this application would
   use two addresses: 1) an interface to connect to the Internet
   (internet interface), and 2) a virtual interface to connect to the
   intranet (intranet interface). The IP address of the Internet and
   intranet interfaces are used in the outer and inner headers of the
   IPSEC respectively. The mechanisms for automatic configuration of
   the remote host's address for the Internet interface are well
   defined; i.e., PPP IP control protocol (IPCP) and DHCP. The
   mechanisms for auto-configuration of the intranet are standardized.
   The two obvious choices for auto-configuration of the intranet
   interface are: 1) use DHCP [3], 2) define a DOI to be used with
   ISAKMP/Oakley to implement functionality similar to PPP IP Control
   protocol[4]. In this draft, we propose to standardize on the use of
   DHCP protocol as a mechanisms for configuration of the intranet
   interface of a IPSEC tunnel for the following reasons.
   1) PPP IP Control protocol is fairly limiting because it primarily
      focuses on assigning IP address and does not provide all the
      necessary configuration parameters.
   2) Defining a new DOI for this purpose unnecessarily makes
      ISAKMP/Oakley protocols and negotiations complex.
   3) DHCP based mechanisms are already in place and well understood.
   4) DHCP protocol provides most of the necessary configuration
      parameters and allows vendor extensions when necessary.
  
   This draft outlines the details of how DHCP protocol can be used to
   auto-configure the intranet interface of an IPSEC tunnel. The
   details of DHCP protocol are provided in  . The details of IPSEC
   protocol are provided in  and the references included in those
   documents.
  
  
  . Outline of the protocol
  
  
  2.1. Notations
  
   The key words, MUST, SHOULD, MAY etc. are defined in [1]. The IPSEC
   related concepts and notations are defined in [2] and DHCP related
   notations are defined in [3].
  
  
  
  2.2. The protocol overview
  
   The protocol described here assumes that the remote host already has
   internet connectivity and the internet interface is appropriately
  
  
   Patel                                                             2
  
               draft-ietf-ipsec-dhcp-01.txt      12/29/98
  
   configured using PPP or DHCP protocols, or using out of band
   mechanisms (i.e., static configuration). The remote host also has
   the knowledge of the SNG.
  
   The protocol for auto-configuration of the intranet interface of
   IPSEC tunnel mode consists of three steps:
  
   1) The remote host establishes a DHCP SA. The DHCP SA is an IPSEC
      tunnel mode SA established to protect initial DHCP traffic
      between the Secure Network Gateway (SNG) and the remote host.
   2) Execute DHCP protocol between the remote hosts intranet interface
      and the SNG. This traffic is protected using the DHCP SA
      established in step 1. Therefore, all the DHCP packets between
      the SNG and the remote host are tunneled using DHCP SA
      established in step 1. At the end of the DHCP protocol, the
      remote host is configured with address obtained by it and other
      relevant parameters (e.g., DNS server name). The DHCP SA SHOULD
      be deleted at this point since future DHCP messages will be
      carried over VPN tunnel.
   3) Establish a VPN SA between the remote host and the SNG. The VPN
      SA is a tunnel mode SA. Note that this is a quick mode exchange.
  
   At the end of step 3, the remote host is ready to communicate with
   the intranet using IPSEC tunnel. All the IP traffic (including
   future DHCP messages) between the remote host, and the intranet are
   now tunneled over VPN SA. In many cases, DHCP SA and VPN SA may be
   the same.
  
  
  
  2.3. Detailed operation
  
  
   Once the Internet interface of the remote host is already
   configured, and the connectivity exists between the internet
   interface of the remote host and the SNG, exchanges of the following
   messages complete the configuration of the intranet interface and
   the IPSEC tunnel. The security parameters used for different SA's is
   based on the security requirements between the remote host and the
   SNG and therefore, is not subject of this document. The mechanisms
   described here work best when VPN is implemented using virtual
   interface (called intranet interface in this document). Thus, the
   objective is to get intranet interface configured using DHCP
   protocol.
  
   The exchanges are:
   1) The intranet interface generates DHCP DISCOVER message and sends
      it to the intranet interface. The chaddr field of the DHCP
      message should include a unique identifier to that gateway.
      Therefore, it can be IPSEC identity of the client (as specified
      in the IPSEC architecture document, and in DOI), or any other
      information that is unique to the client. Note that this field
      not interpreted by the gateway or DHCP server, but is used by the
      gateway (bootp relay agent) to forward DHCP reply to the
  
  
  
   Patel                                                             3
  
               draft-ietf-ipsec-dhcp-01.txt      12/29/98
  
      appropriate tunnel. The client must use the same chaddr field in
      all subsequent messages of the same DHCP exchange.
   2) Since there is traffic on the intranet interface, and intranet
      interface is not configured yet, an IPSEC tunnel over the
      Internet interface needs to be established (DHCP SA) for the
      intranet interface. Remark: the DHCP SA may be established before
      of after receiving DHCP DISCOVER message from the intranet
      interface.
        - Establish a Phase 1 ISAKMP/Oakley SA between the Internet
        interface and the SNG.
        - Establish DHCP SA using phase 2 (quick mode) of
        ISAKMP/Oakley. The key lifetime for the DHCP SA SHOULD be in
        order of minutes since it is only used at the beginning of DHCP
        protocol. All the future DHCP communication, including DHCP
        INFORM, DHCP RENEW and DHCP Terminate use VPN SA. The IDUi
        payload for the quick mode SHOULD use address 0.0.0.0.
        - Setup the routing tables such that all the traffic from
        intranet interface is forwarded over the IPSEC tunnel based on
        DHCP SA. At this point, a filtering table may also be
        established to drop all non-DHCP traffic. Similarly, all the
        packets received over the Internet interface based on IPSEC
        tunnel using DHCP SA are to be forwarded to the intranet
        interface.
   3) The DHCP DISCOVER message is tunneled to SNG using DHCP SA. The
      SNG must store the chaddr field of the DHCP DISCOVER message and
      the information (possibly interface) over which the DHCP DISCOVER
      message was received in a table.
   4) The SNG sends back DHCP RESPONSE message over IPSEC tunnel based
      on DHCP SA.
     - If the SNG itself is a DHCP server, it can generate the DHCP
     response message.
     - If the SNG is not the DHCP server, it MUST relay the DHCP
     DISCOVER message to a DHCP server and forward the response. The
     SNG MUST forward the replay back to the DHCP/VPN client over the
     tunnel associated with the DHCP DISCOVER message.
   5) The Internet Interface forwards the DHCP response message to the
      intranet interface after IPSEC processing.
   6) The Intranet Interface sends out DHCP REQUEST message.
   7) The DHCP REQUEST message is tunneled to the wall by the Internet
      Interface using DHCP SA.
   8) The SNG tunnels DHCP ACK message to the Internet Interface of the
      remote host.
   9) The Internet interface of the remote host forwards DHCP ACK
      message to the intranet Interface.
   At this point, the intranet interface has all the parameters
   supplied by the DHCP protocol to complete its configuration. The
   internet interface can establishes a IPSEC tunnel mode SA for VPN
   (VPN SA) with the SNG. Note that IDui of the quick mode message
   should be the virtual address of the intranet interface (as obtained
   earlier using DHCP). DHCP SA SHOULD now be deleted, and associated
   routing information must be discarded. All the future IP traffic,
   including DHCP TERMINATE, RENEW, and INFORM messages MAY use VPN
   traffic for communication to the intranet and the SNG.
  
  
   Patel                                                             4
  
               draft-ietf-ipsec-dhcp-01.txt      12/29/98
  
  
  2.4. DHCP Considerations
  
   Since the SNG needs to keep track of interfaces over with the DHCP
   protocol messages are to be communicated. The DHCP client MUST
   supply client identifier option with its DNS name or the IP address
   of its Internet Interface concatenated with the interface name. The
   interface name is an ASCII null terminated string.
  
  
  
   3.  Security Considerations
  
  
   This protocol is secured using IPSEC.
  
  
  
   4.  References
  
  
   [1].  Bradner, S, "Key words for use in RFCs to Indicate
  
  Requirement Levels", RFC 2119, Harvard University, March 1997.
  
  
   [2].  S. Kent and R. Atkinson, Security architecture for Internet
  
  Protocol, RFC 2401
  
  
   [3].  R. Droms, "Dynamic Host Configuration Protocol", RFC 2131.
  
  
   [4].  G. McGregor, The PPP Internet Protocol Control Protocol
  
  (IPCP), RFC 1172.
  
  
   5.  Acknowledgments
  
  
   This draft has been enriched by comments from John Richardson and
   Prakash Iyer of Intel, Gurdeep Pall and Peter Ford of Microsoft, and
   Scott Kelley of Red Creek Communications.
  
  
   6.  Author's Addresses
  
  
   Baiju V. Patel
   Intel Corp, JF3-206
   2511 NE 25th Ave
   Hillsboro, OR 97124
   Phone: 503 264 2422
   Email: baiju.v.patel@intel.com
  
  
  
  
  
  
  
  
  
  
  
  
   Patel                                                             5