Complete Computing *
`
`Vipul Gupta, Gabriel Montenegro and Jeff Rulifson
`
`Technology Development Group
`Sun Microsystcms, inc.
`901 San Antonio Road, MS UMPKJE-QM
`Palo Alto, California 94303
`Email: {ygnpto, gab, jcflr}@cng.sun.com
`
`Abstract. Our objective is to en able nomadic and mobile computing, as
`well as telecommuting, small-office, and branch‘oflice computing. 'I‘hese
`areas have been dealt with extensively in the literature. However, they
`have been treated as separate problem spaces and current solutions focus
`on solving specific problems in one area. while ignoring — or even exacer-
`bating -— those in another area. These problem spaces must be vieWed as
`being closely related, and must be addressed in a coherent fashion.
`We call this unified vision and architecture Complete Computing.
`
`1 Vision
`
`As people navigate or relocate throughout the ocean of information that sur-
`rounds them [Figure 1), they wish to maintain logical availability of some sub-
`set of their computing environment. We use the term computing environment
`to include both a user’s applications (6.9. document editor) and data [6.9. files,
`mail, etc.). Maintaining this logical availability may require a combination of
`several mechanisms including caching, replication, redirection, repackaging or
`even prediction.
`
`A mobile client is able to connect using a variety of schemes (serial, LAN,
`wireless, WAN, through firewalls [5], etc) and is adept at operating in discon—
`nected mode. This flexibility gives its user the illusion that information is always
`close at hand, and that it. follows him or her and presents itself for consumption
`independently of the client’s physical or logical location. An important corollary
`is that this network model supports both user and terminal mobility, because
`the objective is for the information to be available to the user at all times —
`though perhaps in varying degrees depending on prevalent networking and en-
`vironmental conditions.
`
`In this paper, the term Mobile Computing represents the ambitious objective
`of retaining a user’s static computing environment [including all existing con-
`nections), even while the user and his portable cleVice are moving. It attempts to
`
`* This work was partly funded by the Ministry of International Trade and Industry
`of Japan through the Advanced Software Enrichment Project of the Information
`Technology Promotion Agency.
`
`0001
`
`EX. 1006
`
`Apple V. MPH Techs. Oy
`IPR2019-00821
`
`Ex. 1006
`Apple v. MPH Techs. Oy
`IPR2019-00821
`
`0001
`
`

`

`1?5
`
`shield the user from the effects of physical or topological movement throughout
`the networking fabric.
`In some instances, preserving a user’s computing environment during move-
`ment may not. be necessary. Instead it may be sufficient to ensure that the user ’5
`computing environment can be recreated wherever the user moves. This may
`require rainitiating network connections and / or reestablishing session state. We
`use the term Nomadic Competing for these situations.
`Remote Computing or Branch Oflicc Computing have similar requirements to
`the previous two, in that they involve access to a user’s private computing envi-
`ronment (e.g. firewall-protected corporate resources) across a potentially hostile
`— or at least untrusted - public network. Nevertheless, the static — hence, stable
`— nature of this kind of computing translates into better resource availability
`and richer services.
`
`Finally, Small-Oflicc/Eome-Oflice Computing assumes there are no private
`user environments beyond those available locally. The objective is to enable
`small, independent work groups. Since they do not belong to a parent organi-
`zation, they lack assistance from system administrators and technical support
`personnel. Therefore, ease of use is of utmost importance. HOWever, there is still
`a need for rich networking and application support.
`The diverse areas mentioned above have been dealt with extensively in the
`literature but not as a cohesive whole. Our objective is to enable all of these
`forms of computing using a common set of tools and solutions. We call this
`unified vision and architecture Complete Computing.
`By designing similar mechanisms for all these areas, we wish to prevent fur-
`ther fragmentation of proposed solutions. Our vision of complete computing has
`technology implications in several areas; hardware and software platforms, data
`persistence, caching and synchronization, configuration and management, appli-
`cations, services, networking, and security.
`
`In this paper we focus primarily on networking and the concomitant secu-
`rity issues. We identify the outstanding technical challenges, review proposed
`solutions, and discuss their applicability in different situations.
`
`2 Elements of a Solution
`
`For the following discussion, a mobile user is one who needs to access informa-
`tion and applications ”on the road”, i.e. from different locations (or even while
`changing locations) and under varying conditions. Access may be read—only or
`read-write and the access device may be personal (6.9. a portable, personal note-
`book or PDA) or communal (my. a kiOsk at an airport).
`
`2.1 Challenges of Mobility
`
`Mobility imposes certain fundamental constraints which affect all aspects of
`computing.
`
`0002
`
`0002
`
`

`

`175
`
`Corporate Head Office
`
`Branch Guinea-lame Oflics
`
`
`
`
`.
`.
`.
`Seesaw com-awed Ger-GB
`
`Publ'n kioek
`stunned will!
`a JEII'B- and H'ITPS‘
`amiable browser
`
`Car-thaws 1P coverage
`Imrn call to call.
`May be
`“We“
`g with 3 Thin
`'
`6
`Server
`
`Fig. 1. An overview of the Complete Computing environment
`
`1. Portable devices, as compared to their stationary counterparts, are ” resource
`poor” (3.9. less powerful CPU, fewer [/0 devices, smaller screen], and must
`manage their resources carefully. Power management is critical for battery-
`operated devices. Screen size and keyboard (or lack thereof) may influence
`the user interface.
`
`. Network characteristics like bandwidth and latency fluctuate widely. There-
`fore, mobile systems must deal with communication uncertainty — including
`complete disconnection — and adapt gracefully to these and other changes.
`
`. Mobility requires different forms of security.
`
`(a)
`
`Network Security. Traflic may at times pass through links with ques-
`tionable security characteristics. New alternatives may he required for
`some traditional security mechanisms that use location information to
`distinguish hetWeen authorized and unauthorized users. As an example,
`many packet-filtering firewalls disallow certain kinds of traffic if it arrives
`on an interface facing the general Internet. Such firewalls may need to
`be enhanced with strong cryptographic mechanisms so legitimate traffic
`from authorized mobile users is allowed irrespective of the interface.
`
`Data and Device Security. As opposed to large, stationary devices safely
`locked up in an office, lightweight, portable devicm are frequently used
`in public places. Hence, they are prone to being destroyed, lost or stolen.
`Consequently, encryption and secure backups are used to prevent sub-
`version or loss of data.
`
`0003
`
`0003
`
`

`

`177
`
`2.2 Agile Networking
`
`is inconceivable to think that a
`it
`In today’s fast-paced information society,
`mobile user can always carry all the information he needs on the local storage
`of his personal computing device. Typically, the information of interest will be
`distributed across a multitude of other hosts connected to a network. This im-
`
`mediately highlights the need for a mobile user to attach to a network, establish
`a communication path to the desired server and exchange information under a
`variety of conditions.
`Consider a salesperson who, over the course of a few hours, uses a portable
`notebook in different networking modes — wireline LAN at his ofiice, a differ-
`ent wireline LAN in a conference room, wireless LAN at the companyr cafeteria,
`wireless WAN at the airport, and a POTS modem connection at a hotel. Typi~
`cally, each situation requires reconfiguration of the device. These configuration
`parameters may include IP address, network mask, default router, DNS server
`name, local printer, etc. In an ideal situation, most (if not all) of the necessary
`changes would be transparent to the end user and occur with minimal disrup-
`tion. Newer protocols like DHCP [7], Mobile IP [21] and 3er [24] hold great
`promise for solving this challenge.
`
`2.3 Disconnected Operation
`
`Of course, there will be periods when a mobile user may not have access to
`any network or the cost of connecting to a network may be prohibitively high
`(as in an airplane). Support for disconnected operation is imperative for such
`situations. The user should be able to cache applications and data 2 in his current
`” working set” onto local, non-volatile storage and, at a later point, reconcile any
`changes made locally against other copies on the network. While a number of
`research groups have made encouraging progress in this particular area [16],
`mature industry—wide standards are still lacking.
`
`2.4 Adaptivity
`
`We anticipate the development of several classes of mobile computing devices
`differing in their CPU power, display size, screen resolution, input devices etc.
`While these characteristics do not change during the lifetime ofa device, others
`such as network bandwidth and latency, remaining battery power, and available
`
`storage are more dynamic and applications could benefit from adapting to such
`changes. A Web brorvser could turn off automatic downloading of in—line im-
`ages when available network bandwidth drops. Such applications would benefit
`from a framework that supports adaptivity. This requires at least two essential
`components: [i] a database which contains current values of various system pa-
`rameters, and (ii) mechanisms by which applications can either poll these values
`or subscribe to events corresponding to parameter changes.
`
`2 Java, with its ability to abstract away CPU and OS-specific differences holds great
`promise for realizing a vision in which applications, not just data, can be exchanged
`freely between all kinds of devices.
`
`0004
`
`0004
`
`

`

`173
`
`2.5 Firewalls and Virtual Private Networks
`
`Corporate employees comprise a significant proportion of the mobile user com-
`munity so allowing their access to corporate resources from remote locations is
`an important requirement. At present, access over PSTN (6.9. using PF? [23]
`with PAP/CRAP) is by far the most popular choice. In the near future, remote
`access mechanisms that use the Internet (rather than PSTN) for their tranSport
`are likely to become popular. These mechanisms offer significant savings in in-
`frastructure costs and toll charges by tunneling packets between the end user
`and the corporate network through the Internet. Clearly, security is an impor-
`tant concern in this situation. Strong cryptographic mechanisms are required
`to ensure that only authorized users gain access to company resources and all
`sensitive information is hidden from eavesdroppers. Tunneling service may be
`provided at Layer 2 or Layer 3 and both avenues are being pursued within the
`lETF.
`
`Many organisations deploy firewalls between their network and the Internet.
`Firewalls use filtering rules and / or cryptographic mechanisms to selectively block
`network traffic. Internet-based remote access mechanisms must accommodate
`
`the presence of firewalls at a corporate network’s periphery. Here again, several
`efforts are underway within the IETF to address the issue of firewall traversal
`[5, 9, 18, 19]. The first internet—draft on the list [5] outlines how mobile hosts
`can establish Virtual Private Networks (VPNs) with their corporate networks
`using IP Security (IPSec) [13, 14, 15, 12, 17, ‘20]. Other proposals on the list
`add mobility support using Mobile IP and can be used to create Mobile VPNs
`(MVPNs). The additional mobility support allows transport level connections
`to be maintained across moves. The three MVPN mechanisms differ in the key—
`management protocols they use [2, 12], the requirements they impose on firewalls,
`and packet header overhead. Unlike TSP [18], the proposals described in [9,
`ll],
`19] do not require firewalls to understand Mobile IP registrations. On the other
`hand, by requiring firewalls to understand Mobile IP registrations, TSP is able
`reduce the header overhead on network traffic.
`
`2.6 Web Based Remote Access
`
`All of the above firewall traversal mechanisms are aimed at providing [P level
`access to all applications even when the mobile host is outside its corporate net-
`wurlr. For situations where accesss to specific applications is sufficient, SSL [8] due
`to its wide availability may provide a better alternative. The basic idea involves
`an application-specific proxy at the firewall. The proxy replaces direct communi-
`cation between a client applet and a server with tw0 separate connections: (i) one
`between the applet and the proxy, and (ii) another betWeen the proxy and the
`server. Communication between the applet and the proxy is secured using SSL
`as the underlying transport. Since the applet can be downloaded from the same
`host as the proxy, communication between them may use a proprietary proto-
`col without introducing interoperability problems. For instance, this proprietary
`
`0005
`
`0005
`
`

`

`179
`
`protocol may be specially tuned for low-bandwidth links. Communication be—
`tween the proxy and server still utilises regular, well established protocols, 6.9.
`IMAPv4, SMTP, HTTP, telnet, etc so no changes are required on the server side.
`A major advantage of this architecture is that the near-ubiquity of J ava- and
`SSL-capable browsers eliminates the need to carry a personal device. A salesper~
`son can walk up to any host, a kiosk or even a client’s workstation, and use its
`browser to gain secure access to specific applications on his corporate network.
`The server is authenticated through SSL’s certificate exchange mechanism and
`one~time passwords can be used to authenticate the user to the proxy host.
`Whatever mechanism is chosen for secure, Internet—based access, it is impor—
`tant that existing applications be able to benefit from it with minimal changes.
`The Java application environment supports the'notion of a socket factory which
`can be used to isolate applications from specific details of the packet processing
`required for firewall traversal.
`
`3 Lightweight Devices and Personal Mobility
`
`Our objective is to enable people to access their network resources independent
`from any of the following:
`
`1. Physical location,
`2. Internet access method,
`3. Device used.
`
`The last item will grow in importance with the deployment of internet kiosks,
`web-enabled hotel rooms, public internet terminals and similar devices. Device
`independence — besides being a desired objective -— is sometimes necessary. For
`example, the user may not have authorization to connect any device he may be
`carrying to the existing network infrastructure: one company ’s employee may be
`forced to use existing devices at another company’s premises.
`
`3.1 Minimum Set of Platform Requirements
`
`This mode of access must make very few assumptions about the underlying plat-
`form. We have arrived at the following elements which we believe are ubiquitous
`or nearly so, and enable remote access mechanisms at the transport layer and
`above.
`
`1. HTML
`
`2. HTTP and HTTP over SSL (HTTPS)
`3. Java Virtual Machine (J VM]
`
`An important consideration in arriving at this minimum set of requirements
`is that, prior to arriving at the remote site, no client software installation is
`required. Instead, any necessary client-side software is downloaded and executed
`dynamically on the JVM. Given that client platforms are notorious for their lack
`
`0006
`
`0006
`
`

`

`180
`
`of reliability, modifying the configuration in any significant manner dramatically
`increases the possibility of software conflicts, lock ups and panics. It is generally
`recognized that executing Java byte code within the confines of the JVM is very
`effective in safeguarding the client against rogue software. What is not generally
`recognized is that, by virtue of leaving drivers and kernel code untouched and
`by limiting the capabilities of the code to those allowed by the JVM, bytecode
`execution also protects the machine from its own unreliability.
`Another objective in arriving at a minimum set of platform requirements is
`that security must not be compromised. Thanks to Java‘s ability to dynamically
`download and execute code, basic SSL (HTTPS) services become the foundation
`for secure remote access mechanisms.
`
`3.2 Distributed Cryptographic Infrastructure
`
`With Java, it is possible to engage in international secure transactions and net—
`working without contravening any laWs.
`Regulations concerning cryptographic technology vary from country to coun-
`try. For example, in the US. strict export controls must be abided by. In France,
`use of cryptography by individuals is severely limited. Furthermore, governments
`may express these policies in ambiguous terms as a further deterrent to the dis-
`semination of cryptography. GiVen this confusing landscape, it is obvious that
`for international corporations — particularly those implementing virtual private
`networks on the Internet — and for security-conscious travelers, divining the set
`of regulations valid in any given situation, and complying with it is a daunting
`task. Traditionally a user installs security software onto his laptop. As this user
`travels across international borders, he may have to uninstall and subsequently
`reinstall the software. Besides being cumbersome, this negatively affects the sta-
`bility of the portable device, precisely at the time when the user is traveling and
`system administration resources are not available.
`
`Java allows the just-in-time downloading of the — potentially digitally signed
`-- cryptographic software, and its subsequent installation and execution under
`the watchful vigilance of the JVM. Having done this, the client is able to es-
`tablish secure communications with its corporation’s public server, and use it
`as a gateway into its private network. Notice that thanks to digital signatures,
`the client need not download the cryptographic software from the same machine
`that it then uses as a gateway into its network.
`For example, suppose a US. user travels to Switzerland. and then accesses
`his corporation ’s world wide web site using the trips protocol. The ensuing SSL
`negotiation selects a cipher that is common to the server and the client in order
`to encrypt the traffic. ASSuming that the remote user is a law-abiding individ-
`ual, the list of ciphers available at the client does not include strong encryption.
`For example, instead of RC4 encryption with a 128—bit key, the client may only
`have export~grade R04 encryption with a 40—bit key. Al. this point, the client
`may choose to download a stronger cipher. However, it does so from a server in
`Switzerland, completes the SSL negotiation, and is able to secure the communi-
`cations with the gateway in the US. using R04 encryption with a 128-bit key.
`
`0007
`
`0007
`
`

`

`181
`
`Since the gateway machine in the U.S. never supplies the cryptographic code,
`export restrictions do not apply. At the same time, the local cryptographic code
`server in Switzerland enforces whatever local policies may apply. Currently, the
`U.S. government does not restrict encrypted traffic with off-shore sites, it only
`restricts exporting the technology to encrypt the traffic. 3
`Of course, the local government might impose additional restrictions on the
`use of cryptography. For example, if the visitor happens to be in France, his
`client will have no preinstalled ciphers, and any attempt to download them from
`a local ”security” server would a110w the latter to impOse local regulations. The
`user might be informed that cryptography is disallowed, and that any traffic
`exchanged with the gateway for the U.S. corporation would be in cleartext. At
`this point, the gateway could impose its own policies and reject the request for
`remote access from the visitor in France. Alternatively, it could limit the remote
`
`user’s access rights for the duration of the session.
`As can be seen, these security servers take on the responsibility of enforcing
`local cryptographic policy, thus relieving the users from this onerous task. This
`constitutes a perfectly legal, distributed cryptographic infrastructure to secure
`traffic across international borders.
`
`3.3 Configurable Socket Factory and RAFT URLs
`
`There is no standard for internet remote access into corporate or private net-
`works. The task of traversing the corporate firewall may be accomplished in
`several ways: specific gateway software, 1P security (as it is being defined by
`the IETF), SSL mechanisms, HTTPS tunneling, SOCKS, etc. HOWever, none of
`the firewall traversal mechanisms will prevail completely. RAFT (Remote Ac-
`cess and Firewall Traversal) URLs recognise this fact, and provide a naming and
`encapsulation scheme that shields applications from particularities.
`RAFT URLs have the following formats:
`raflKmfl-typc)://<imcersal—poini):{<oiher—info>]
`raftgeneric-ml
`Where the different parts have this meaning:
`
`raft: This indicates that the URL that follows is a handle into a registry of
`remote access schemes.
`
`raft-type: The name given to a specific firewall traversal or remote access
`method. Raft types denote very specific methods. For example, the use of IP
`layer 3 tunnels with SKIP, using an extended mobile registration protoeol
`for dynamic tunnel set-up might be one such scheme. Another one might be
`a mechanism based on HTTPS tunneling.
`traversal-point: This is a firewall, gateway or remote access server with which
`the system must negotiate access. Discovery of the traversal point is beyond
`the scope of this note.
`
`3 However, the cipher downloaded from the Swiss site must have been implemented
`without any aid from the U.S.
`
`0008
`
`0008
`
`

`

`182
`
`other-info: This is a scheme-specific initialization string. The scheme may im—
`ply further round—trip times before access is granted. This string isjust a first
`step. It does not necesearily have to be used. The format of this parameter
`is defined by the scheme.
`generic-1111: Any possible URL as defined in [3]
`
`A RAFT URL does not designate a data object, but rather a means to negou
`tiate access through a traversal point to establish contact with private resources.
`RAFT URLs are useful because no one method of remote aceess is likely
`to dominate. RAFT enables the specific form of remote access to be abstracted
`away from the applications that need the connectivity. It now becomes a two—part
`process:
`
`1. Discovery of a RAFT URL.
`This may be accomplished, for example. by any of these methods:
`
`(a) The user visits a special web page and as part of the login process,
`authenticates itself to the gateway or firewall by any of these mechanisms:
`i. Client-side SSL authentication.
`
`ii. Hardware-assisted authentication using challenge—response schemes.
`iii. One—time passwords.
`
`The web server grants access by sending some relevant information to
`the client. A RAFT URL may be part of this information sent by the
`web server. The code that implements the mechanisms called for by the
`RAFT URL may be pre—installed on the device. Otherwise,
`the client
`may, at this time, download the code necessary to interpret and carry
`out the necessary operations for firewall traversal under the specified
`RAFT URL.
`
`(b) The appropriate RAFT URL is produced by querying a directory service
`such as LDAP, Service Location Protocol or DNS.
`(c) The possible RAFT URLs (and relevant code to execute them) are pre-
`configured into the mobile device. The system is set up for the current
`environn'ient by choosing among the possible RAFT URLs. This may
`happen direct by the user’s choosing from a menu among the possible
`RAFT URLs, or by some event notification mechanism informing the
`system.
`
`2. Once the RAFT URL is discovered, it must be used by the system to set
`its default firewall traversal mechanisms accordingly. The implementation of
`this step and its transparency to applications is, of course, highly dependent
`on the system’s software platform. As an example, a system may use the
`RAFT URL to set its socket factory appropriately. Applications built to the
`standard Java socket interface in package inverter need not be aware of the
`exact mechanisms involved.
`
`Notice that from the point of view of the applications, the socket factory
`itself does not change, rather its internal behavior does.
`
`0009
`
`0009
`
`

`

`183
`
`Introducing this abstraction allows any type of firewall traversal or remote
`access scheme to be integrated into the platform, separately from the applications
`that use the network connection.
`
`At this time, the gateway or firewall becomes a proxy so the remote client
`can access the private network.
`
`3 .4 Personal Mobility
`
`Since the mechanisms outlined above rely on very widely deployed technologies
`(Java, HTTP, SSL), they also enable personal mobility. For example, a user
`can walk up to any public Internet terminal, and after properly authenticating
`himself to the relevant gateway, gain access into his private network.
`Some words of caution are in order. This technology only secures the link
`between the client and the gateway machine. Once the data arrives at the client
`it is presented in cleartext for the user’s consumption. A trojan horse client can
`easily collect the data at this point.
`
`4 Specially Configured Devices
`
`This section examines the “road warrior” or “power user” scenario which is
`distinguished by a user’s ability to carry a specially configured portable device.
`The user is no longer bound by the constraints of communal devices, like kiosks,
`which generally ofier minimal functionality. In what follows, we present a list of
`software solutions we consider important for power users.
`Perhaps the most basic requirement of mobile users is the ability to change
`their point of attachment to the Internet with minim a1 disruption. Doing so typ-
`ically involves changing several network configuration parameters. This task can
`be greatly simplified by a piece of software we call network switcher. It allows
`users to specify multiple “network profiles” (eg. one for their office and another
`for their [SP at home) and switch to a pre—stored profile quickly and conve-
`niently. The software can also initiate DHCP and gather necessary configuration
`parameters that way rather than through pre—specified profiles.
`Whenever the IP address of a device changes, previously established transport-
`level connections are norm ally lost. Mobile [P aIIOWs a mobile device to be reach-
`able at a fixed IP address (called its home address] irrespective of its current
`point of attachment to the lnternet. Transport level connections established with
`the home address are preserved across moves. However, unlike PPP and DHCP,
`Mobile IP is a fairly new protocol and the required infrastructure (comprising
`mobility agents and client-side software] is not widely deployed.
`When a mobile host is moved to a new network, it may need to discover
`resources like network printers or HTTP proxies in its immediate vicinity. The
`Service Location Protocol (5 LP) is ideally suited to this task. In some situations,
`LDAP [25] which is more widely deployed may provide adequate functionality.
`Connecting to the Internet and finding local resources is just one part of the
`overall challenge. Mobile users should also be able to access remote resources
`
`0010
`
`0010
`
`

`

`134
`
`within firewall-protected private networks, 6.9. a corporate network. This re-
`quires setting up a secure communication channel across a public network like
`the Internet, is. a Virtual Private Network (VPN). The concept of tunneling is
`central to VPN solutions. It refers to the practice of encapsulating one protocol
`in another. This might be necessary in order to carry non-[P traffic [8.9. [PX or
`Appletalk) acr0ss the Internet, or even to carry an encrypted packet within an-
`other packet directed at an intervening firewall. Tunneling service may either be
`provided at Layer 2 or at Layer 3. Layer 2 tunneling mechanisms (may. L2'1‘P [11])
`transfer PPI’ packets (encapsulating 1P, IPX etc) across the Internet or other
`transport media. Layer 3 tunneling mechanisms, on the other hand, directly
`encapsulate network layer packets (3.9. IP, IPX) in IP. A number of Layer~3
`tunneling protocols have been proposed (TEP [4], TSP {18]) that extend the
`basic Mobile IP protocol to allow chaining of multiple tunnel segments. All of
`these tunneling proposals ([11, 4, 18]) rely on IPSec to provide confidentiality,
`integrity and authenticity when the transport medium is the Internet. Currently,
`LQTP seems to have captured the largest mindshare among VPN technologies.
`Nevertheless, we feel that Layer 3 tunneling offers a superior solution especially
`when the underlying transport is the Internet. These advantages include:
`
`— 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. [X may be IP, [PX etc)
`— Greater reliability. With layer-two tunneling, each end point maintains a
`PPP state machine (including timers and retransmission logic) across a “sim—
`ulated serial line”. Unlike a real serial line, end points of the simulated line
`are often separated by large distances and,J' or many hops with only best effort
`delivery. As such, the PPP connections are prone to timeouts and frequent
`resets.
`
`[f multi-protocol support is considered unimportant, IPSec alone can go a
`long way in solving the secure, remote access problem. From a deployment per-
`spective, it is perhaps easier to establish secure tunnels that extend from a
`corporate network’s periphery to an ISP rather than all the way to the end-user
`device. The latter requires IPSec software on the portable device but offers the
`following ad vantages:4
`
`— End—users are free to connect to their corporate network irrespective of the
`ISP used to ” get on to the Internet”.
`— Corporations do not need to establish a trust relationship with ISPs, they
`only need to trust their own employees. A corporation in 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 roam-
`
`ing consortia. One can also think of several situations where an employee
`may connect to the Internet through a ”provider” that. has no prior agree—
`ments with the user’s corporation. Examples of such ”internet providers”
`
`4 As IPSec standards mature, we expect operating system vendors to bundle this
`functionality, greatly alleviating the deployment challenge.
`
`0011
`
`0011
`
`

`

`185
`
`include universities or temporary ”terminal rooms” provided at academic
`and industry conferences.
`
`IPSec based remote access requires an IPSec—capable node within the corpo-
`rate firewall complex. Filtering and access control rules should be set up so that
`IPSec packets, and others necessary for establishing security associations, can be
`exchanged freely bet-ween this node and the general Internet. The address of this
`”IPSec gateway” must be known to external mobile hosts. The exact discovery
`mechanism is irrelevant to the subsequent discussion. Manual configuration and
`DNS lookup (ag. using KX records [1]) are just two of the possible alternatives.
`Very often, corporate networks use private addresses that are not advertised
`to the general Internet. Furthermore, internal routers are generally unaware of
`external addresses and return ”ICMP unreachable” messages for such destina-
`tions (assuming they do not use default routing). This creates the challenge of
`ensuring end-to-end delivery between a h0st with an internal address (3. g. corpo-
`rate file- or mail~server) and a best connected to the Internet using an external
`address. There are two basic approaches to this problem:
`
`1. The first approach adds Network Address Translation (NAT) functionality
`at the IPSec gateway. After authenticating arriving packets, and before in-
`jecting them into the private network, the gateway does a NAT operation,
`replacing the external source address with its own IP address [the gateway
`may he assigned a range of internal addresses). This way when an internal
`host responds, it uses a destination address that is ”valid” inside the cor-
`porate network. The response packet reaches the IPSec gateway, undergoes
`a reverse address translation, and lPSec prOcessing before it is sent to the
`remote 110st [6].
`Inserting NAT in the communication path can “break” certain applications.
`Some applications carry network address information (I? address and /or
`TCP/ UDP port) as part of the their payload and performing NAT for such
`packets can get complicated, 8.9. replacing the IP address or por