INTERNET-DRAFT Vipul Gupta
SUN Microsystems, Inc
Jun 7, 1999
Secure, Remote Access over the Internet using IPSec
<draft-gupta-ipsec-remote-access-02.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.
This memo draws upon several ideas from [Dora97,Mosk98] and would not
have been possible without the contributions of the IETF working
groups on IP Security (IPSec) and Network Address Translation (NAT).
Gupta Secure Remote Access [Page 1]
INTERNET-DRAFT Expires December, 1999 June 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 December, 1999 June 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 December, 1999 June 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 December, 1999 June 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.
3. Operation Details:
The basic operation is illustrated in the following diagram. Detailed
security considerations are presented later.
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
Gupta Secure Remote Access [Page 5]
INTERNET-DRAFT Expires December, 1999 June 1999
(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 (that only implements Main mode with Pre-shared keys
for authentication in Phase I) 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 Phase I combinations, such as Main mode with
digital signatures or Aggressive mode with pre-shared keys, are
better suited for the situation at hand.
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".
Gupta Secure Remote Access [Page 6]
INTERNET-DRAFT Expires December, 1999 June 1999
(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
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). However, early experience indicates that
enough applications can be supported to make this a useful
alternative. The second approach is more general but
requires additional mechanisms so remote hosts can acquire
temporary internal addresses and other configuration
information. The next section explores two possible
alternatives for acquiring such information.
Gupta Secure Remote Access [Page 7]
INTERNET-DRAFT Expires December, 1999 June 1999
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 [Pate98] and [PeAP98].
4.1 The ISAKMP Configuration Method
The internet draft [PeAP98] 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
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
Gupta Secure Remote Access [Page 8]
INTERNET-DRAFT Expires December, 1999 June 1999
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 [Pate98] 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]
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:
Neither approach has a clear advantage over the other. 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
Gupta Secure Remote Access [Page 9]
INTERNET-DRAFT Expires December, 1999 June 1999
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.
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
Gupta Secure Remote Access [Page 10]
INTERNET-DRAFT Expires December, 1999 June 1999
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 a 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. This provision is necessary to minimize the chance
of a security breach if the remote host is stolen. Some
implementations may decide to store this information in encrypted
form protected by a password. Others may store sensitive information
on removable media like smartcards.
5. 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 may be manually
configured or learned as part of the key negotiation process
[PeAP98]. DNS traffic (including internal host names) will be
automatically protected like any other traffic to/from the protected
network.
This note does not address how a remote host discovers the IPSec
gateway guarding its protected network. This information may be
supplied by the remote user (our testbed uses manual configuration).
If the protected network does not use private addresses, the
gateway's IP address may be published through DNS [Atki97].
6. Acknowledgments
The author would like to thank Naganand Doraswamy, Gabriel
Montenegro, and Pyda Srisuresh for their feedback on an early version
of this document.
Gupta Secure Remote Access [Page 11]
INTERNET-DRAFT Expires December, 1999 June 1999
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.
References
[Atki97] R. Atkinson, "Key Exchange Delegation Record for the
DNS", RFC 2230, Nov. 1997.
[Aziz98] A. Aziz, Personal communication. A writeup describing
a vulnerability in the use of passwords over HTTPS is
available at
http://playground.sun.com/~vgupta/browser-attack.html
[Dora97] N. Doraswamy, "Implementation of Virtual Private
Networks (VPNs) with IP Security", Internet draft <draft-
ietf-ipsec-vpn-00.txt>, work in progress, Mar. 1997 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/.
Gupta Secure Remote Access [Page 12]
INTERNET-DRAFT Expires December, 1999 June 1999
[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.
[Mosk98] R. G. Moskowitz, "Network Address Translation issues
with IPsec", Internet draft <draft-moskowitz-net66-vpn-
00.txt>, work in progress, Feb. 1998 or its successor.
[Pate98] B. V. Patel, "Dynamic Configuration of IPSEC VPN host
using DHCP", Internet draft <draft-ietf-ipsec-dhcp-01.txt>,
work in progress, Dec. 1998 or its successor.
[PeAP98] R. Pereira, S. Anand and B. Patel, "The ISAKMP
Configuration Method", Internet draft <draft-ietf-ipsec-
isakmp-mode-cfg-04.txt>, work in progress, May. 1998 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: (650) 786 3614
Fax: (650) 786 6445
EMail: vipul.gupta@eng.sun.com
Gupta Secure Remote Access [Page 13]
INTERNET-DRAFT Expires December, 1999 June 1999
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.
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.
Gupta Secure Remote Access [Page 14]
INTERNET-DRAFT Expires December, 1999 June 1999
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:
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|
+-----------+-----------+--------+--------------------
Gupta Secure Remote Access [Page 15]
INTERNET-DRAFT Expires December, 1999 June 1999
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.
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 |
+---------+-----------------
Gupta Secure Remote Access [Page 16]
INTERNET-DRAFT Expires December, 1999 June 1999
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)
+-----------+-----------+--------+--------------------
|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
Gupta Secure Remote Access [Page 17]
INTERNET-DRAFT Expires December, 1999 June 1999
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
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 18]