One document matched: draft-ietf-ipsec-dhcp-00.txt
IPSEC Working Group Baiju V. Patel,
INTERNET-DRAFT Intel Corporation
draft-ietf-ipsec-dhcp-00.txt September, 1997
Dynamic remote host configuration over IPSEC 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 is a protocol suite defined by IETF working group on IP
security to secure communication at the network layer between
communicating peers. This protocol is comprised of three primary
elements: 1) ISAKMP/Oakley[2], 2) IPSEC AH [4]and 3) IPSEC ESP [5].
ISAKMP/Oakley is the key management protocol while AH and ESP are
used to protect IP traffic. Both AH and ESP can be used in tunnel or
transport mode. Among many applications enabled by IPSEC tunnel and
transport modes, an interesting and useful application is connect a
remote host (e.g., roaming user) to the intranet through firewall
(or secure network gateway) using IPSEC tunnels.
Patel 1
draft-ietf-ipsec-tunnel-DHCP-00.txt 11/21/97
--------------- |----------| |---------| |----------|
| Remote Host |----|Internet |----|Firewall |---| Intranet |
--------------- |----------| |---------- |----------|
|
|
|-------------|
| 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 [7], 2) define a DOI to be used with
ISAKMP/Oakley to implement functionality similar to PPP IP Control
protocol[6]. 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.
2. 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][3] and DHCP
related notations are defined in [7].
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-tunnel-DHCP-00.txt 11/21/97
configured through out of band mechanisms, or using PPP or DHCP
protocols. The remote host also has the knowledge of the firewall.
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 firewall and the remote host.
2) Execute DHCP protocol between the remote hosts intranet interface
and the firewall. This traffic is protected using the DHCP SA
established in step 1. Therefore, all the DHCP packets between
the firewall 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).
3) Establish a VPN SA between the remote host and the firewall. The
VNP SA is a tunnel mode SA.
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 firewall, 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 firewall and therefore, is not subject of this
document.
The exchanges are:
1) The intranet interface generates DHCP DISCOVER message and sends
it to the Internet interface.
2) The Internet interface establishes the DHCP SA. 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 firewall.
@
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.
3) The Internet Interface tunnels the DHCP DISCOVER message to the
firewall.
Patel 3
draft-ietf-ipsec-tunnel-DHCP-00.txt 11/21/97
4) The firewall sends back an IPSEC tunneled DHCP RESPONSE message
to the internet interface of the remote host using DHCP SA.
@
If the firewall itself is a DHCP server, it can generate the DHCP
response message.
@
If the firewall is not the DHCP server, it MUST relay the DHCP
DISCOVER message to a DHCP server and forward the response.
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 firewall 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 firewall. All the future IP traffic, including
DHCP TERMINATE, RENEW, and INFORM messages MAY use VPN traffic for
communication to the intranet and the firewall.
2.4. DHCP Considerations
Since the firewall 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].
Maughhan, D., Schertler, M., Schneider, M., and Turner, J.,
"Internet Security Association and Key Management Protocol
(ISAKMP)", version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}.
[3].
D. Harkins, D. Carrel, "The resolution of ISAKMP with
Oakley", Internet Draft, <draft-ietf-ipsec-isakmp-oakley-04.txt>,
July 1997.
[4].
S. Kent, "IP Authentication Header", draft-ietf-ipsec-auth-
header-02.txt.
Patel 4
draft-ietf-ipsec-tunnel-DHCP-00.txt 11/21/97
[5].
S. Kent, " IP Encapsulating Security Payload (ESP)", draft-
ietf-ipsec-esp-v2-01.txt.
[6].
G. McGregor, "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332.
[7].
R. Droms, "Dynamic Host Configuration Protocol", RFC 2131.
5. Acknowledgments
This draft has been enriched by comments from John Richardson of
Intel and Gurdeep Pall and Peter Ford of Microsoft.
6. Author's Addresses
Baiju V. Patel
Intel Corp
2511 NE 25th Ave
Hillsboro, OR 97124
Phone: 503 264 2422
Email: baiju@mailbox.jf.intel.com
Patel 5
| PAFTECH AB 2003-2026 | 2026-04-23 22:24:19 |