[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
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]