INTERNET-DRAFT Vipul Gupta
SUN Microsystems, Inc
June 17, 1998
Secure, Remote Access over the Internet using IPSec
<draft-gupta-ipsec-remote-access-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 view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (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).
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
Gupta Secure Remote Access [Page 1]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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
[i-Planet] already offers a commercial product based on this
approach. The product offers access to e-mail and files from any
Java- and HTTPS-enabled web browser. The proxy server is
authenticated through SSL's certificate exchange mechanism and one-
time passwords are used to authenticate the user.
Note that if IPSec capable devices were to become as pervasive as
HTTPS- and Java-capable devices today, it would be possible to
Gupta Secure Remote Access [Page 2]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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 Better bandwidth utilization. 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).
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
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.
Gupta Secure Remote Access [Page 3]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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
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
Gupta Secure Remote Access [Page 4]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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.
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
(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. 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
Gupta Secure Remote Access [Page 5]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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
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-
Gupta Secure Remote Access [Page 6]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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 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 "ISAKMP Configuration Method"
proposed within the IPSec working group addresses this need
[PeAP98].
4. 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
Gupta Secure Remote Access [Page 7]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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) and all
traffic from the remote host should be directed to the protected
network. That is, communication between the remote host and the
general Internet (e.g. the CNN website or the Intuit stock server)
may be directed through G. This indirection is likely to have an
adverse impact on performance but should strengthen security. Some
situations may require exceptions to this rule, e.g. 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.
Setting up an IPSec tunnel between the protected network and a remote
host must require its authorized user to type in a password. This
provision is necessary to minimize the chance of a security breach if
the remote host is stolen.
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 8]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
References
[Atki97] R. Atkinson, "Key Exchange Delegation Record for the
DNS", RFC 2230, Nov. 1997.
[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)",
Internet draft <draft-ietf-ipsec-isakmp-oakley-07.txt>,
work in progress, Mar. 1998 or its successor.
[HLFT94] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, Oct. 1994.
[iPass] See http://www.ipass.com/.
[iPlanet] See http://www.i-planet.com/.
[KeAk98a] S. Kent and R. Atkinson, "Security Architecture for the
Internet Protocol", Internet draft <draft-ietf-ipsec-arch-
sec-04.txt>, work in progress, Mar. 1998 or its successor.
[KeAk98b] S. Kent and R. Atkinson, "IP Authentication Header",
Internet draft <draft-ietf-ipsec-auth-header-05.txt>,
work in progress, Mar. 1998 or its successor.
[KeAk98c] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet draft <draft-ietf-ipsec-esp-v2-
04.txt>, work in progress, Mar. 1998 or its successor.
[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.
[PeAP98] R. Pereira, S. Anand and B. Patel, "The ISAKMP
Configuration Method", Internet draft <draft-ietf-ipsec-
isakmp-mode-cfg-03.txt>, work in progress, Apr. 1998 or
its successor.
[SrEg98] P. Srisuresh and K. Egevang, "The IP Network Address
Translator (NAT)", Internet draft <draft-rfced-info-srisuresh
-05.txt>, work in progress, Feb. 1998 or its successor.
Gupta Secure Remote Access [Page 9]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
[VHRK98] A. Valencia et al., "Layer Two Tunneling Protocol
(L2TP)", Internet draft <draft-ietf-pppext-l2tp-10.txt>,
work in progress, Mar. 1998 or its successor.
[YlKS97] T. Ylonen, T. Kivinen, M, Saarinen, "SSH Protocol
Architecture", Internet draft <draft-ietf-secsh-archi
tecture-01.txt> work in progress, Mar. 1997 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
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.
Gupta Secure Remote Access [Page 10]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
<------ 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:
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:
Gupta Secure Remote Access [Page 11]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
<------ 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.
The remote host generates traffic for the protected network using
R_i as source and tunnels it to G.
Gupta Secure Remote Access [Page 12]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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 13]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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 14]
INTERNET-DRAFT Expires Dec 22, 1998 June 1998
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 15]