INTERNET-DRAFT Vipul Gupta
SUN Microsystems, Inc
Oct 22, 1999
Secure Remote Access over the Internet using IPSec
<draft-gupta-ipsec-remote-access-03.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and 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 inapproporiate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 (Australia), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes the use of IPSec [KeAt98a-c] for secure access to
protected networks by authorized users connected to the Internet. An
example target scenario is a corporate employee on the road accessing
resources on his company's Intranet. It addresses firewall traversal,
user authentication, data confidentiality and the use of private
address spaces (the latter impacts routing and name lookups). A
comparison to other mechanisms such as those based on Layer-2
tunneling or session layer security, is also included.
Gupta Secure Remote Access [Page 1]
INTERNET-DRAFT Expires April, 1999 Oct 1999
1. Introduction:
Traditionally, corporate employees have accessed their protected
networks remotely by dialing into their company's modem pools. More
recently, mechanisms that use the Internet (rather than the Public
Switched Telephone Network (PSTN)) for their transport are gaining
popularity since they offer significant savings in infrastructure
costs and toll charges along with greater flexibility. Clearly,
security is an important concern in this situation. Strong
cryptographic mechanisms are required to ensure that only authorized
users gain access to company resources and sensitive information is
hidden from eavesdroppers. Internet based remote access mechanisms
must deal with several issues such as firewall traversal, tunneling,
private address spaces, and access control.
This note describes how IPSec may be used to address these issues.
The use of IPSec is motivated by the thought of enabling "full"
network access for remote users. For situations where access to
specific applications is sufficient, SSL (in the form of HTTPS) due
to its wide availability may provide a better alternative (see
Related Work).
1.1 Related Work:
An HTTPS-based approach to remote access:
This approach utilizes application-specific proxies at the protected
network's periphery (within the Demilitarized zone (DMZ)). The proxy
(aka application gateway) replaces direct communication between a
remote client and an internal server with two separate connections:
(i) a client-proxy connection, and (ii) a proxy-server connection.
Confidentiality and authentication requirements are met by using SSL
as the underlying transport for client-proxy communication. The
remote client can be an applet downloaded from the proxy host and the
two may communicate using a proprietary protocol without introducing
interoperability problems. The proxy-server communication uses well
established protocols (such as IMAP, SMTP, HTTP, telnet, NFS) so no
changes are required on the server.
A major advantage of this architecture is that the near-ubiquity of
Java- and SSL-capable browsers eliminates the need to carry a
personal device. In this sense, this approach supports "user
mobility" and not just "device mobility". A salesperson can walk up
to an Internet kiosk at an airport (or a public computer in a hotel
lobby) and use its browser to gain secure access to specific
applications on his or her corporate network. At least one vendor
already offers a commercial product based on this approach. The
product offers access to e-mail and files from any Java- and HTTPS-
Gupta Secure Remote Access [Page 2]
INTERNET-DRAFT Expires April, 1999 Oct 1999
enabled web browser. The proxy server is authenticated through SSL's
certificate exchange mechanism and one-time passwords are used to
authenticate the user. Due to a peculiarity in the major browsers
today, this approach is vulnerable to a password/session stealing
attack when used by naive users in a kiosk-style setting [Aziz98]
(this is not meant as a criticism of the general HTTPS-based
approach).
Note that if IPSec capable devices were to become as pervasive as
HTTPS- and Java-capable devices today, it would be possible to
support user mobility with "full" network access using the mechanisms
described in this draft.
Layer-2 Tunneling:
Tunneling refers to the practice of enclosing one packet within
another. This may be necessary, for example, to carry datagrams
belonging to one network protocol across a network based on a
different protocol. PPTP, L2F and L2TP [VHRK98] tunnel Layer-2 (link
layer) PPP packets across various transport media. By leveraging
PPP's multi-protocol support, they allow even non-IP traffic (e.g.
IPX or Appletalk) to be carried across the Internet between a remote
client and its private network.
The use of L2TP across the Internet results in a rather interesting
situation: Layer-3 packets (e.g. IP, IPX) are encapsulated in Layer-2
packets (PPP) which are encapsulated in Layer-4 packets (UDP) which
are themselves encapsulated in IP. GRE [HLFT94] rather than L2TP
seems more appropriate for this situation. With GRE, a non-IP,
layer-3 packet (e.g. IPX) can be directly encapsulated within IP.
This approach has the following advantages over Layer-2 tunneling:
o Running protocol X over PPP over UDP (as with L2TP across the
Internet) is less efficient than running protocol X directly
over IP (here X may be IP, IPX and so on). While suitable header
compression techniques may alleviate the problem of bandwidth
underutilization due to extra headers, they increase the already
higher processing burden resulting from additional protocols.
o Greater reliability. With layer-two tunneling, each end point
maintains a PPP state machine (including timers and
retransmission logic) across a `simulated serial line''. Unlike
a real serial line, end points of the simulated line are often
separated by large distances and/or many hops with only best
effort delivery. As such, the PPP connections are prone to
timeouts and frequent resets.
It is worth noting that tunneling protocols (including GRE) by
Gupta Secure Remote Access [Page 3]
INTERNET-DRAFT Expires April, 1999 Oct 1999
themselves do not directly address data security. Instead, they rely
on IPSec for services such as per-packet integrity, source
authentication, and confidentiality when tunneling packets through
the Internet. Since an increasing number of clients are adopting
TCP/IP as their native networking protocol and others (such as IPX or
Appletalk) can be carried across the Internet using GRE, it is
interesting to explore how far IPSec alone (compared to L2TP + IPSec)
will go towards solving the remote access problem.
2. Remote Access Model:
This draft focuses on the simplest, and perhaps the most common,
case: a mobile host connected to the general Internet attempting to
access resources within a firewall-protected network. It does not
address multiple firewall traversal, especially when those firewalls
belong to different administrative domains (for example, company A's
employee accessing its network from inside company B's network).
Allowing an untrusted foreign host to connect to a protected network
raises security concerns (such as the possibility of passive
snooping) beyond the scope of this draft. Some organizations provide
visitors with direct network connections to the Internet. In these
situations, even though a visitor is physically inside a foreign
organization; from a network topology perspective, he is on the
Internet outside the protected networks of his home and foreign
organizations.
Mechanisms described here accommodate the use of private addresses
within the protected network. These addresses are not advertised to
the general Internet (even when they are globally unique). Packets
sent to private addresses from the Internet reach only as far as the
routing backbone where they elicit an "ICMP destination unreachable"
message and are dropped. Quite often, routers within the protected
network are similarly unaware of external addresses.
We assume that hosts within the protected network trust each other
(this assumption is typical of most Intranets) and IPSec is deployed
"end-to-edge", that is, IPSec protection extends from the protected
network's periphery all the way to the mobile host. It is certainly
possible to deploy IPSec only between the corporate network and an
ISP ("edge-to-edge"). While the former requires IPSec software on the
portable device, it offers some significant advantages:
- End-users are able to access protected network resources
irrespective of the ISP used to "get on to the Internet".
Many ISPs today are members of global roaming consortia
[iPass, GRIC]. Their customers can connect to the Internet
from most major cities world-wide for the price of a local
phone call and without having to maintain multiple ISP
Gupta Secure Remote Access [Page 4]
INTERNET-DRAFT Expires April, 1999 Oct 1999
accounts. In order to fully realize the benefits of this
development, it is imperative that a remote access scheme
be independent of the user's ISP.
- Corporations do not need to establish trusted relationships
with ISPs; they only need to trust their own employees. A
corporation may be willing to trust an ISP based in the
same country but may not be willing to trust an ISP based
in another country even if the two ISPs are members of a
roaming consortium. One can also think of several situations
where an employee may connect to the Internet through a
"provider" that has no prior agreements with the user's
corporation. Examples of such internet providers include
universities or temporary terminal rooms provided at
academic and industry conferences, e.g. the IETF terminal
room. These "internet providers" are unlikely to entertain the
idea of signing a special service agreement with every
corporation whose employee may utilize their service.
Making security a private matter between the corporate network
and the employee also allows for interesting new service
provider models in the future. One possibility is the
establishment of "pay-as-you-go" connectivity slots at
public places like airport terminals. By swiping their
credit cards or paying cash, users would be able to
gain high speed (a megabit or more per second) access to
the Internet. Once on the Internet, they'd be able to
utilize mechanisms described in this memo to establish
a secure, virtual presence on their office network.
As IPSec standards mature, we expect client operating systems to
bundle this functionality, greatly alleviating the challenge of
deploying IPSec at the user's end. Almost all major operating system
vendors have announced plans to include IPSec in their OS offering
within the year (as of Oct 1999).
3. Operation Details:
The basic operation is illustrated in the following diagram. Detailed
security considerations are presented later.
Gupta Secure Remote Access [Page 5]
INTERNET-DRAFT Expires April, 1999 Oct 1999
I N T E R N E T | P R O T E C T E D N E T
|
|
(a) G_e IPSec G_i (b)
Remote --------> ------gateway------- ------> Internal
computer (R) <------- (G) <------ host (H)
connected (d) | (c)
via an ISP- |
assigned |
address, R_e
(a),(d) = This traffic is protected by an IPSec tunnel. R_e
and G_e appear as src/dst for this traffic.
(b),(c) = This traffic is in the clear but external address
R_e does not appear either as source or destination.
Figure 1: Operational overview.
In Figure 1, R is an IPSec-capable remote host connected to the
Internet using an ISP-assigned address R_e. G is an IPSec gateway at
the boundary of the protected network such that its "external" IP
address G_e is reachable from the Internet. H denotes an internal
host/server with which R wishes to communicate.
The remote host negotiates a tunnel-mode IPSec security association
with the IPSec gateway. This may be accomplished using IKE [HaCa98]
or any other means as long as it does not preclude the remote host
using a dynamically assigned address. Note that a minimally-compliant
IKE implementation (which only implements Main mode with Pre-shared
keys for Phase I authentication) cannot be used on a remote host with
a dynamically assigned address. The IKE responder (gateway) needs to
look up the initaitor's (mobile node's) pre-shared key before it can
decrypt the latter's third main mode message (fifth overall in Phase
I). Since the initiator's identity is contained in the encrypted
message, only its IP address is available for lookup and must be
predictable. Other options, such as Main mode with digital
signatures/RSA encryption and Aggressive mode, can accomodate IKE
peers with dynamically assigned addresses.
Agressive mode is vulnerale to a denial-of-service (DOS) attack since
it requires the receiver to perform a costly Diffie-Hellman
computation before the sender has been authenticated. The use of
digital signatures or RSA encryption with Main mode requires that
certificates be issued and distributed to IKE entities. Deploying a
PKI in a closed system (like the one targetted here) requires only a
modest effort which is well worth the extra security offered by
certificate-based schemes over passphrase/password based mechanisms.
Gupta Secure Remote Access [Page 6]
INTERNET-DRAFT Expires April, 1999 Oct 1999
Still, some may view the effort as prohibitive. A new Phase I
exchange, called Base Mode [DaBi99] has been proposed for deployment
situations that need preshared-key based authentication but where the
DOS vulnerability of Aggressive mode is considered unacceptable. This
is achieved by sacrificing identity protection available with Main
mode.
Private addresses within the protected network are accommodated by:
(a) Using a bi-directional IPSec tunnel between R_e and G_e so
internal addresses (e.g. H) are hidden from routers on the
Internet, and
(b) Mapping the remote host to an "internal presence" so that
routers and hosts within the protected network perceive all
communication as originating from and terminating at an
internal address.
[Note: This part is unnecessary if external addresses are
allowed within the private network and outgoing
packets to these addresses are routed to G (perhaps
through default routing). Applications such as NFS
use IP addresses for access control and internal NFS
servers may have to be reconfigured to respond to
external addresses.]
There are two ways to map a remote host to an "internal
presence".
(i) Network Address and Port Translation (NAPT)
After verifying an incoming packet's source,
decrypting its payload and removing the tunnel
header, the IPSec gateway overwrites the source
R_e with G_i. Since multiple remote hosts may be
simultaneously connected to the protected network
via G, additional state (e.g. UDP/TCP port
information or ICMP sequence numbers) is maintained
and used for demultiplexing responses returned to
G_i. It is also possible to use a range of internal
addresses (rather than G_i alone) for NAPT. Details
of the translation process are described in [SrEg98].
(ii) Dynamically assigning an internal address to the
remote host
With this approach, the remote host generates
traffic for the protected network using an internal
address (say, R_i) as source. This traffic is
Gupta Secure Remote Access [Page 7]
INTERNET-DRAFT Expires April, 1999 Oct 1999
tunneled to G using IPSec. After verifying the
incoming packet's source, decrypting its payload
and removing the tunnel header, the IPSec gateway
obtains a packet with a source address that is valid
within the protected network. This packet can be
forwarded to H without any address/port translation.
Unlike the NAPT-based approach, this one requires a
pool of internal addresses to be set aside for
remote hosts. The size of this pool must be as large
as the number of simultaneously supported remote
users (similar to what is done for conventional PPP-
based access). Within the protected network, G must
advertise reachability to these addresses.
Packet formats corresponding to these two approaches are shown in
Appendix A and Appendix B, respectively. The first approach requires
fewer infrastructure changes but NAPT can break certain applications
(see [HoSr99] and Appendix C) causing them to fail silently (and
mysteriously from a naive user's perspective). The second approach is
more general and preferable over the first even though it requires
additional mechanisms so remote hosts can acquire temporary internal
addresses and other configuration information.
4. Alternatives for Obtaining "Internal" Network Information:
Presently, there are two proposals for letting a remote host obtain
configuration information corresponding to its virtual presence on
the internal network (the Intranet in our previous example). This
section presents high-level overview of each proposal and discusses
their tradeoffs. Operational details on each proposal are available
in [PAKG99] and [PeAP99].
4.1 The ISAKMP Configuration Method
The internet draft [PeAP99] proposes a new ISAKMP exchange that may
be used to "push" or "pull" configuration information such as an IP
address, a netmask, a DNS server, a DHCP server among others. The
mechanism is extensible and can be extended to communicate arbitrary
configuration options.
With this approach, a remote host, R, connected to the Internet would
go through the following steps in establishing a secure, virtual,
presence on a private network hidden from the general Internet behind
an IPSec gateway, G.
1. R establishes a Phase I security association with G. The mode
and authentication mechanism used in this step must accommodate
Gupta Secure Remote Access [Page 8]
INTERNET-DRAFT Expires April, 1999 Oct 1999
the use of a dynamic address by R, e.g. Main mode with
pre-shared keys cannot be used for reasons explained previously
in Section 3.
2. R and G participate in an ISAKMP configuration exchange
through which R obtains an internal address, R_i, and related
parameters as necessary, e.g. an internal DNS server.
3. R initiates a Phase II (Quick Mode) exchange in which it
proposes a tunnel mode security association between R_e
and G. The client IDs used are R_i (as IDci) and N (as IDcr)
where N represents all of the addresses on the internal
network with which R wishes to communicate. N may be specified
as an address range or as a subnet since both of these are
valid ISAKMP identities. It is quite possible that neither
representation accurately captures all of the addresses
that R_i communicates with. For example, if policy determines
that R may only communicate with addresses 10.0.1.10-10.0.1.20
and 10.0.1.100-10.0.1.200 then R will need to establish
multiple Phase II SAs and use a different IDcr for each
because IKE does not support a single identity type that
can represent multiple, disjoint addresse ranges.
[NOTE: Another possibility for avoiding the need to create
multiple SAs is to use a wildcard IDcr (i.e. use ID_IPV4_ADDR
with protocol, port and address set to zero). In this case,
filtering rules can be set up at G restrict that R only
communicates with those internal hosts that are allowed by
the protected network's policy. The only drawback with this
approach is that R can no longer view IDcr as an accurate
representation of all the nodes it can communicate with
successfully.]
4. Once the appropriate set of Phase II security associations
has been established, R can exchange traffic with internal
hosts using the packet formats shown in Appendix B.
4.2 Dynamic VPN Configuration using DHCP
Another alternative which is described in [PAKG99] suggests that the
remote host reuse DHCP to obtain all necessary configuration
information. DHCP [Drom97] provides an extensible framework for
passing configuration information to hosts on a TCP/IP network.
With this approach, a remote host, R, connected to the Internet would
go through the following steps in establishing an on-demand VPN.
1. [Same as Step 1 in Section 4.1]
Gupta Secure Remote Access [Page 9]
INTERNET-DRAFT Expires April, 1999 Oct 1999
2. R uses a Phase II (Quick Mode) exchange to establish a
tunnel mode security association which would be used to
carry DHCP traffic between R and a DHCP server on the
private network.
3. R acquires an internal address R_i and related configuration
parameters through DHCP.
4a. [Same as Step 3 in Section 4.1]
4b. The DHCP security association is no longer needed and
may be destroyed at this point.
5. [Same as Step 4 in Section 4.1]
4.3 A Comparison of the two Approaches:
The DHCP approach is attractive because it reuses an existing
protocol rather than add further complexity to IKE. However, it does
require an additional Phase II exchange (in Step 2) for establishing
a DHCP security association which is discarded soon thereafter. While
the IKE configuration exchange takes one roundtrip (and involves two
messages -- REQUEST, REPLY), DHCP negotiation may require upto two
roundtrips (and four messages -- DHCPDISCOVER, DHCPOFFER, DHCPREQUEST
and DHCPACK).
The IPSec for Remote Access [IPSRA] group (this is currently not a
formal IETF working group) has not yet reached a decision as to which
of these approaches will be stadardized. Each solution is being
prototyped by one or more vendors.
5. Security Considerations:
Two requirements must be met to ensure that only authorized
individuals can access resources on the protected network:
(a) The IPSec gateway must not allow unauthorized hosts to
communicate with the protected network, and more importantly,
(b) Unauthorized users must not be able to exploit authorized
hosts to communicate with the protected network on their
behalf.
Item (a) is addressed by the strong cryptographic mechanisms built
into IPSec. Even if an unauthorized host spoofs the IP address of an
authorized host, it would not be able to get its packets past G since
IPSec authentication will fail.
Gupta Secure Remote Access [Page 10]
INTERNET-DRAFT Expires April, 1999 Oct 1999
Addressing item (b) requires that the remote host have some firewall-
like characteristics. Under no circumstances should an attacker be
able to "log into" the remote host over the network. Otherwise, he or
she will have also gained access to the protected network -- the
IPSec module has no way of distinguishing between packets sent by a
legitimate user and those sent by an attacker logged into the remote
host. As another illustration of the potential security threat,
consider a remote host, X, running an HTTP server with proxying
capability. When X is connected to the protected network using
IPSec, a malicious user on the Internet may be able to view internal
web pages by configuring X as the proxy for his or her browser. To
address this and similar threats, all non-essential networking
services (e.g. telnet, ftp, rlogin, rsh, nfs, bind, http server
functionality) must be disabled and IP forwarding must be turned off.
This process is typically OS-specific. However, on most flavors of
UNIX, a network service is disabled by commenting out the
corresponding line in /etc/inetd.conf and reinitializing the inetd
daemon (sending it a SIGHUP signal). Certain PC operating systems do
not offer this functionality to begin with.
If additional precautions are desired, IP packet filtering should be
enabled on the remote host to disallow potentially troublesome
packets (e.g. unsolicited packets like incoming TCP SYNs). At the
extreme end of this spectrum, IPSec policy at the remote host may be
configured such that it tunnels all outgoing traffic to the security
gateway and only accepts tunneled IPSec packets from the gateway. In
this situation, communication between the remote host and the general
Internet (e.g. the CNN website or the Intuit stock server) is always
directed through G (Figure 1). This indirection is likely to have an
adverse impact on performance but may be attractive to security
administrators since it gives G greater control over policy
enforcement. Some special situations may require R to exchange
traffic with another host without going through G. For example, if an
ISP uses DHCP for address allocation and lease renewals, the remote
host must be allowed to exchange DHCP traffic directly with its DHCP
server.
Any secret authenticators (such as an pre-shared key or a private
DSA/RSA key) used in IKE Phase I must not be stored in the clear on
the remote host. Unless user input is required to provide the remote
host's IKE daemon with access to this authenticator, only the device,
not the user, is authenticated. This increases the chance of a
security breach should the device be lost or stolen. User input may
take several forms. Some implementations may choose to store the
authenticator information in encrypted form protected by a password.
Others may require sensitive information be stored on removable media
like smartcards which the user could carry separately from the
portable computer. There is also interest within the IPSec community
Gupta Secure Remote Access [Page 11]
INTERNET-DRAFT Expires April, 1999 Oct 1999
to support the use of legacy mechanisms like SecureID or Enigma token
cards for user authentication [KeKA99], [PeBe99].
6. Other Issues:
In most instances, host names within the protected network would not
be known to external DNS resolvers. In such a situation, the remote
host must direct all DNS queries to an appropriate resolver within
the protected network. The resolver's IP address can be acquired as
part of the configuration process described in Section 4. DNS traffic
(including internal host names) will be automatically protected like
any other traffic to/from the protected network. When the VPN is
terminated, the DNS configuration must be changed back to use the
ISP's DNS server reachable on the general Internet.
This note assumes that the remote host knows the IP address of the
IPSec gateway guarding its protected network. This information may be
supplied by the remote user via manual configuration or obtained
automatically from DNS through A, KX or SRV records.
6. Acknowledgments
The author would like to thank Naganand Doraswamy, Scott Kelly,
Gabriel Montenegro, and Pyda Srisuresh for their feedback on previous
versions of this document.
7. Revision History
Version Date Comments
------- ---- --------
00 Jul 17, 1998 Created initial version.
01 Nov 17, 1998 Added a reference to [Aziz98] in
Section 1.1. In Section 3, added
a brief discussion on the suitability
of various IKE (Phase I) exchanges
for the remote access problem.
Added Section 7 titled "Revision
History".
02 Jun 7, 1999 Added a new section (Section 4) to
discuss available alternatives for
configuring the remote host. Added
text in Section 2 to emphasize the
importance of a trust model that does
not require trusting the Internet
service provider. Updated references.
Gupta Secure Remote Access [Page 12]
INTERNET-DRAFT Expires April, 1999 Oct 1999
03 Oct 22, 1999 Added a disussion on Base mode and
the need to authenticate users rather
than portable devices. Several
additional updates/clarifications.
References
[Atki97] R. Atkinson, "Key Exchange Delegation Record for the
DNS", RFC 2230, Nov. 1997.
[Aziz98] A. Aziz, Personal communication.
[DaBi99] Y. Dayan, S. Bitan, "IKE Base Mode", Internet draft
<draft-ietf-ipsec-ike-base-mode-00.txt>, work in progress,
Jun. 1999 or its successor.
[GRIC] See http://www.gric.com/.
[HaCa98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, Nov. 1998.
[HLFT94] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, Oct. 1994.
[HoSr99] M. Holdrege, P. Srisuresh, "Protocol Complications
with the IP Network Address Translator (NAT)", Internet
draft <draft-ietf-nat-protocol-complications-00.txt>,
work in progress, Feb. 1999 or its successor.
[iPass] See http://www.ipass.com/.
[KeKA99] S. Kelly, J. Knowles, B. Aboba, "User-level
Authentication Mechanism for IPSec", Internet draft <draft-
kelly-ipsra-userauth-00.txt>, work in progress, Oct. 1999
or its successor.
[KeAk98a] S. Kent and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, Nov. 1998.
[KeAk98b] S. Kent and R. Atkinson, "IP Authentication Header",
RFC 2401, Nov. 1998.
[KeAk98c] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, Nov. 1998.
[PAKG99] B. V. Patel, B. Aboba, S. Kelly and V. Gupta, "Dynamic
Configuration of IPSEC VPN host using DHCP", Internet draft
<draft-ietf-ipsec-dhcp-03.txt>, work in progress, Oct. 1999
Gupta Secure Remote Access [Page 13]
INTERNET-DRAFT Expires April, 1999 Oct 1999
or its successor.
[PeAP99] R. Pereira, S. Anand and B. Patel, "The ISAKMP
Configuration Method", Internet draft <draft-ietf-ipsec-
isakmp-mode-cfg-05.txt>, work in progress, Aug. 1999 or
its successor.
[PeBe99] R. Pereira, S. Beaulieu, "Extended Authentication Within
ISAKMP/Oakley", Internet draft <draft-ietf-ipsec-isakmp-
xauth-05.txt>, work in progress, Sep. 1999 or its successor.
[SrEg98] P. Srisuresh and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", Internet draft
<draft-ietf-nat-traditional-01.txt>, work in progress,
Oct. 1998 or its successor.
[VHRK98] A. Valencia et al., "Layer Two Tunneling Protocol
(L2TP)", Internet draft <draft-ietf-pppext-l2tp-15.txt>,
work in progress, May. 1999 or its successor.
[YlKS97] T. Ylonen, T. Kivinen, M, Saarinen, "SSH Protocol
Architecture", Internet draft <draft-ietf-secsh-archi
tecture-03.txt> work in progress, Feb. 1999 or its
successor.
Author's Address
Vipul Gupta
Sun Microsystems, Inc.
901 San Antonio Rd.
Palo Alto, CA 94303
Tel: +1 650 786 3614
Fax: +1 650 786 6445
EMail: vipul.gupta@sun.com
APPENDIX A: NAPT hides the remote host's external address
=========================================================
This appendix presents the packet formats for traffic labeled
(a) through (d) (Figure 1) when a NAPT-based approach is used.
The diagrams assume that a single address G_i (rather than
an address range) is used to hide external addresses. ESP with
authentication is used to secure traffic across the Internet.
For (a) and (b), the packet head is shown to the right. For (c)
and (d), the packet head is shown to the left to match the flow
in Figure 1.
Gupta Secure Remote Access [Page 14]
INTERNET-DRAFT Expires April, 1999 Oct 1999
Packet format in Step (a):
<------ Original IP ------->|<--IPSec-->|<--Outer-->|
datagram header(s) IP header
-------------------+---------+-----------+-----------+
| src=R_e | ESP | src=R_e |
| dst=H | (w/ auth) | dst=G_e |
-------------------+---------+-----------+-----------+
At gateway G, the IPSec module authenticates the source
(the packet is dropped if authentication fails) and recovers
the original datagram.
<------ Original IP ------>|
datagram
-------------------+---------+
| src=R_e |
| dst=H |
-------------------+---------+
Before this datagram is injected into the protected network, the
NAPT module within G overwrites the source with G_i. It also
adjusts all header checksums that may be affected and stores
enough state so that responses returning to G can be reverse
translated and sent to the appropriate external host. For TCP
and UDP packets, even the source port may be overwritten as part
of the NAPT operation.
Packet format in Step (b):
<------ Original IP ------>|
datagram
(after NAPT)
-------------------+---------+
| src=G_i |
| dst=H |
-------------------+---------+
Host H responds as if G had initiated this communication. The
response packet appears as shown below:
Gupta Secure Remote Access [Page 15]
INTERNET-DRAFT Expires April, 1999 Oct 1999
Packet format in Step (c)
<------ Response IP ------>
datagram
+---------+-----------------
| src=H |
| dst=G_i |
+---------+-----------------
When this response gets to G, the NAPT module performs a
reverse translation [SrEg98] and the translated packet is
shown below:
<------ Response IP ------>
datagram
+---------+-----------------
| src=H |
| dst=R_e |
+---------+-----------------
As the packet is about to be forwarded out of G's interface
facing the Internet, IPSec policy causes the datagram to undergo
security processing.
Packet format in Step (d):
<--Outer-->|<--IPSec-->|<--- Response datagram ---->|
IP header header(s) (after reverse NAPT)
+-----------+-----------+--------+--------------------
|src=G_e | ESP | src=H |
|dst=R_e | (w/ auth) | dst=R_e|
+-----------+-----------+--------+--------------------
APPENDIX B: Remote host is assigned an internal address
=======================================================
We assume that the remote host R (Figure 1) is assigned (perhaps
temporarily) an internal address R_i. Packets for R_i are routed
to G inside the protected network. ESP with authentication is used
to secure traffic across the Internet. For (a) and (b), the packet
head is shown to the right. For (c) and (d), the packet head is
shown to the left to match the flow in Figure 1.
Gupta Secure Remote Access [Page 16]
INTERNET-DRAFT Expires April, 1999 Oct 1999
The remote host generates traffic for the protected network using
R_i as source and tunnels it to G.
Packet format in Step (a):
<------ Original IP ------->|<--IPSec-->|<--Outer-->|
datagram header(s) IP header
-------------------+---------+-----------+-----------+
| src=R_i | ESP | src=R_e |
| dst=H | (w/ auth) | dst=G_e |
-------------------+---------+-----------+-----------+
At gateway G, the IPSec module processes the encapsulating
headers and recovers the original datagram. The packet is
dropped if IPSec is unable to authenticate the source. Otherwise,
the newly recovered packet is sent on its way to H without further
translation.
Packet format in Step (b):
<------ Original IP ------->|
datagram
-------------------+---------+
| src=R_i |
| dst=H |
-------------------+---------+
Host H responds as shown below:
Packet format in Step (c)
<------ Response IP ------>
datagram
+---------+-----------------
| src=H |
| dst=R_i |
+---------+-----------------
As the packet is about to be forwarded out of G's interface facing
the Internet, IPSec policy causes the datagram to undergo security
processing.
Gupta Secure Remote Access [Page 17]
INTERNET-DRAFT Expires April, 1999 Oct 1999
Packet format in Step (d):
<--Outer-->|<--IPSec-->|<--- Response datagram ---->|
IP header header(s)
+-----------+-----------+--------+--------------------
|src=G_e | ESP | src=H |
|dst=R_e | (w/ auth) | dst=R_i|
+-----------+-----------+--------+--------------------
APPENDIX C: Limitations of the NAPT-based approach
==================================================
Certain application protocols carry network address information
(IP address and/or TCP/UDP port) as part of the application payload.
Examples include: FTP, IRC, H.323, CUSeeMe, Real Audio, Real Video,
Vxtreme/Vosiac, VDOLive, VIVOActive, True Speech, RSTP, PPTP,
StreamWorks, NTT AudioLink, NTT SoftwareVision, Yamaha MIDPlug,
iChat Pager, Quake, and Diablo (for a more up to date list, see
http://dijon.nais.com/~nevo/masq/).
Performing NAPT for such applications can get complicated. Replacing
the IP address or port information in the application payload may
require adjustments to the IP packet length (and TCP sequence
numbers). Certain NAPT implementations go to great lengths to
accommodate these applications. Others, simply let them fail
silently.
On multi-homed hosts, certain UDP implementations respond with a
source address different from the address at which the original
request was sent. In Figure 1, if H were multi-homed and had such
an implementation, it could respond to an NFS mount request (a UDP
message) with source address H' even if the request were sent to H.
In this situation, G may be unable to carry out the reverse NAPT
translation (unless it ignores the source for UDP responses) and R
may not be able to use H as an NFS server.
NAPT at G works well when communication between an external host
(R) and an internal host (H) is initiated by the external host.
Packets sent by R automatically set up the appropriate NAPT mapping
at G used to route returning packets. Supporting communication
initiated by an internal host to the external mobile host (e.g.
regular X window traffic) is a little tricky. If the internal host
tries to address the mobile node at its external address, its packets
Gupta Secure Remote Access [Page 18]
INTERNET-DRAFT Expires April, 1999 Oct 1999
will be dropped by internal routers that are unaware of the external
IP address. If the internal host directs its communication at the
NAPT host (G), the absence of a NAPT mapping will make it impossible
for G to figure out which remote host should receive the packet. NAPT
implementations often support explicit mappings (aka redirection rules
[Reed]) as a workaround for this situation. However, establishing
these mappings requires knowledge of the mobile node's external IP
address and must be updated whenever the mobile node's address changes.
(Note: Tunneling X-window traffic over SSH [YlKS97] is a simpler
alternative for enabling X applications across an intervening NAPT
host.)
Gupta Secure Remote Access [Page 19]