Network Working Group J. O'Hara
Expires May 20th, 1997 New Oak Communications
Internet Draft November 20, 1997
Configuration of Tunnel Mode Ipsec Endpoint Parameters
<draft-ohara-ipsecparam-00.txt>
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 and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as ``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 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
This document describes the assignment of configuration
parameters to IPsec tunnel mode client endpoints. Single user
computers that are connecting into corporations via Internet
Service Providers, ISP's, using Tunnel mode IPsec may need to
have configuration information supplied to them, such as inner
ip address, DNS server addresses, WINS server addresses, etc.
This document describes a method utilized by New Oak
Communications to pass these parameters between it's Extranet
Access Switch and it's IPsec client software.
TABLE OF CONTENTS
STATUS OF THIS MEMO...........................................1
ABSTRACT......................................................1
1. INTRODUCTION...............................................2
2. IP ADDRESS ASSIGNMENT METHOD...............................2
3. DNS AND WINS ADDRESS ASSIGNMENT............................3
O'Hara [Page 1]
Internet Draft - Tunneled Ipsec Endpoint Parameters Page 2
4. SECURITY CONSIDERATIONS....................................4
5. REFERENCES.................................................4
6. AUTHOR'S ADDRESS...........................................5
1. Introduction
Traditional use of Tunnel Mode IPsec has been focused at
firewall to firewall connections with state configured at
each end. This is well suited for branch office routing, but
is less appropriate for internet remote access, where a
single user system, such as a home computer or laptop is
connected to an Internet Service Provider's Point of Presence,
POP. In this model the end system will have it's IP configuration
initially configured through IPCP in the dial up case or via
DHCP in the case of a cable modem or ADSL. It is desirable
for the IPsec tunnel parameters and policy to be downloaded to
the end user's system in similar, but secure manner.
Tunnel mode IPsec is well suited to allow traveling or home users
the opportunity to tunnel directly from their systems into
corporate sites. In doing so the user would first connect to a
ISP's POP. Then the user would initiate a connection with a
access server on the edge of their network that would serve
as the other end of the IPsec tunnel.
Establishment of a secure tunnel hides the corporation's network
topology and allows the end users system to operate just as if it
were an internal system. The end users system will need to
be assigned a new end node address for use inside the IPsec tunnel
and other addresses such as those of DNS and WINS servers. In this
draft the terms "end node" read as a home or traveling user's PC,
and "access server" as the device that exists between the corporate
Intranet and the Internet terminates IPsec tunnel connections.
This document assumes that the reader is familiar with the related
documents "The resolution of ISAKMP with Oakley" [Hark97], and
"Dynamic Host Configuration Protocol, RFC 2131" [Drom97], that
provide important background for this specification.
In this document, the key words "MAY", "MUST", "recommended",
"required", and "SHOULD", are to be interpreted as described in
[RFC-2119].
O'Hara [Page 2]
Internet Draft - Tunneled IPsec Endpoint Parameters Page 3
2. IP ADDRESS ASSIGNMENT
Assignment of a Inner IP address is accomplished by using the access
server supplied Proxy ID responder, IDur, supplied by the initiator
(server) as part of the Quick Mode exchange undertaken in
ISAKMP phase 2. To utilize the proxy ID's in this way requires that
the phase 2 initiator is the server and that the responder (the end
node) accepts that address as it's inner, or tunneled address.
ISAKMP usage [Hark97] and [Pip97] describe the 2 stage process
for establishment of a Security Association, SA. Phase 1 establishes
a secure connection for SA negotiation. During Phase 2 this
negotiation is accomplished within the authenticated and protected
channel constructed in phase 1. Phase 2 is characterized by 1 or more
Quick mode exchanges.
When the end node initiates the IPsec tunnel it will be the Phase 1
initiator. During Phase 2 the access server MUST be the initiator, as
shown below.
Quick Mode is defined as follows from [Hark97]:
Initiator (server) Responder (end node)
-------------------- ----------------------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDui, IDur ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDui, IDur ]
HDR*, HASH(3) -->
Where the contents of IDui are specified as follows:
Identification Type for IDui and IDur will be: ID_IPV4_ADDR 1
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
Summary:
By reversing the Phase 1 and Phase 2 initiator roles and using the
supplied IDur as the tunneled source address the problem of how to
supply a remote user a tunneled, inner address can be resolved. This
reversal of roles is within the scope of the draft [Hark97] and
provides secure assigment method protected by the ISAKMP SA.
O'Hara [Page 3]
Internet Draft - Tunneled IPsec Endpoint Parameters Page 4
3. DNS and WINS ADDRESS ASSIGNMENT
When the end node has received its tunnelled address and the IPsec
tunnel has been established, the end node may require the addresses
for DNS and WINS servers inside the corporate network. To obtain
these addresses, the end node uses the Dynamic Host Configuration
Protocol (DHCP) [Drom97] as follows:
The end node sends a tunnelled unicast DHCPINFORM message under the
protection of the just-established IPsec SA. The source address
inside the tunnel is the IPv4 address received from the server
in IDur (as described in section 2), while the destination address
is the server's IPv4 address on the corporate network, as provided
in IDui. The "ciaddr" field in the DHCPINFORM message MUST be the
same as the end node's source address inside the tunnel. If the
end node requires DNS server configuration, the end node SHOULD
provide DHCP option 55 (Parameter Request List) as specified in
RFC 2132, and include DHCP option 6 (Domain Name Server option)
in the list. If the end node requires WINS server configuration,
it SHOULD provide a parameter request list that includes DHCP option
44 (NetBIOS over TCP/IP Server option).
The server responds by sending a tunnelled unicast DHCPACK message
to the end node's tunnelled address. The DHCPACK MAY include one
or more DNS servers, provided by DHCP option 6, and MAY include one
or more WINS servers, provided by DHCP option 44.
4. Security Considerations
Protection of corporate network topology is of concern and it
should be observed that tunnel addresses assigned with this
method are transmitted under the protection of the ISAKMP SA,
while the DNS and WINS server addresses are protected by the IPsec
SAs. Thus, the information is no more (and no less) secure than
the SAs themselves.
5. References
[Alex97] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC2119, March 1997.
O'Hara [Page 4]
Internet Draft - Tunneled IPsec Endpoint Parameters Page 5
Expires May 20th, 1997
[Drom97] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Bucknell University, March 1997.
[Hark97] Harkins, D., Carrel, D., "The resolution of ISAKMP with
Oakley", draft-ietf-ipsec-isakmp-oakley-04.txt.
[MSST96] 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}.
[Orm96] Orman, H., "The Oakley Key Determination Protocol", version
1, TR97-92, Department of Computer Science Technical Report,
University of Arizona.
[Pip97] Piper, D., "The Internet IP Security Domain Of Interpretation
for ISAKMP", version 5, draft-ietf-ipsec-ipsec-doi-05.txt.
6. Author's Address
John O'Hara
New Oak Communications, Inc.
125 Nagog Park
Acton, Massachusetts, 01720
johara@newoak.com
(978) 266 1011 voice
O'Hara [Page 5]