`(12) Patent Application Publication (10) Pub. No.: US 2006/0031407 A1
`Dispensa et al.
`(43) Pub. Date:
`Feb. 9, 2006
`
`US 20060031407A1
`
`(54) SYSTEMAND METHOD FOR REMOTE
`NETWORKACCESS
`
`(76) Inventors: Steve Dispensa, Leawood, KS (US);
`Matt Miller, Overland Park, KS (US);
`Wayne Schroeder, Lenexa, KS (US);
`Jason Sloderbeck, Overland Park, KS
`(US)
`
`Correspondence Address:
`LEE & HAYES PLLC
`421 W RIVERSIDEAVENUE SUTE 500
`SPOKANE, WA 992.01
`
`(21) Appl. No.:
`
`10/737,200
`
`(22) Filed:
`
`Dec. 15, 2003
`
`Related U.S. Application Data
`
`(60) Provisional application No. 60/433,059, filed on Dec.
`13, 2002.
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06F 15/16
`(52) U.S. Cl. .............................................................. 709/219
`
`(57)
`
`ABSTRACT
`
`Systems and methods for remote network acceSS are pro
`vided. The described methods may be implemented in a
`computer-readable-medium and executed on a processing
`device. Software modules resident on one or more networks
`Servers and one or more client computing devices cooperate
`to provide the client computing device(s) with remote net
`work access.
`
`210a
`
`210b
`
`210c
`
`PSEC
`Concentrator
`
`220
`
`
`
`
`
`PSEC
`Concentrator
`
`
`
`
`
`250
`
`PSEC
`Concentrator
`
`244
`
`Network
`Resource
`
`Network
`Resource
`
`Network
`Resource
`
`Network
`Resource
`
`256
`
`Target Network
`
`Target Network
`
`
`
`1
`
`APPLE 1022
`
`
`
`Patent Application Publication
`
`Feb. 9, 2006 Sheet 1 of 6
`
`US 2006/0031407 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`|-Z.…...|…|…}\,: 99?][gº] -!!!!!!! !---------------------~~~~
`
`
`
`
`
`2
`
`
`
`Patent Application Publication Feb. 9, 2006 Sheet 2 of 6
`
`US 2006/0031407 A1
`
`21Ob
`
`21 Oc
`
`PSEC
`ConCentrator
`
`220
`
`
`
`
`
`
`
`
`
`PSEC
`Concentrator
`
`240
`
`IPSEC
`Concentrator
`
`250
`
`244
`
`
`
`Network
`Resource
`
`Network
`Resource
`
`246 254
`
`
`
`NetWork
`Resource
`
`Network
`Resource
`
`256
`
`Target Network
`
`Target Network
`
`3
`
`
`
`Patent Application Publication Feb. 9, 2006 Sheet 3 of 6
`
`US 2006/0031407 A1
`
`310C
`
`312
`
`
`
`320
`
`WebTop Server
`
`IPSEC
`ConCentrator
`
`314
`
`
`
`340
`
`344
`
`IPSEC
`Concentrator
`
`350
`
`
`
`
`
`
`
`IPSEC
`Concentrator
`
`NetWork
`ReSource
`
`Network
`ReSource
`
`346
`354
`
`NetWork
`Resource
`
`
`
`Network
`Resource
`
`Target Network
`
`Target Network
`
`4
`
`
`
`Patent Application Publication Feb. 9, 2006 Sheet 4 of 6
`
`US 2006/0031407 A1
`
`410a
`
`
`
`410C
`
`440
`
`444
`
`456
`
`Target Network
`
`5
`
`
`
`Patent Application Publication Feb. 9, 2006 Sheet 5 of 6
`
`US 2006/0031407 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`System Memory. 134
`
`Software Modules
`
`User Interface Module
`
`510
`
`514
`
`WTP ProtoCO MOdule
`
`518
`
`Virtual Adapter Module
`
`522
`
`Reconfiguration System Module 526
`
`Local Proxy Module
`
`5 3 O
`
`Application Tunneling Module 534
`
`Captive Portal System Module
`
`38
`5
`
`RSYNC Module
`
`
`
`5 4. 2 ---
`
`URL Rewriter Module
`
`546
`
`E-Mail Connector Module
`
`50
`5
`
`Software Updater Module
`
`5 5 4
`
`Application Distribution Module 558
`
`Network Backup Module
`
`5 6 2
`
`Applications Content Module 5
`6 4
`
`6
`
`
`
`Patent Application Publication Feb. 9, 2006 Sheet 6 of 6
`
`US 2006/0031407 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`System Memory 134
`Software Modules
`
`Administration Module
`
`WTP Protocol Module
`
`6 1 O
`
`6 1 4
`
`6 1 8
`
`Reconfiguration System Module 622
`
`Application Tunneling Module 626
`
`NAT Agent Module
`
`630
`
`Captive Portal System Module 634
`
`RSYNC Module
`
`638
`
`22, 6
`
`Central Policy Manager Module 642
`
`Network Backup Module
`
`6 4. 6
`
`E-Mail Connector Module
`
`6 5 O
`
`Software Updater Module
`
`654
`
`Application Distribution Module 65
`8
`
`
`
`7
`
`
`
`US 2006/0031407 A1
`
`Feb. 9, 2006
`
`SYSTEMAND METHOD FOR REMOTE
`NETWORKACCESS
`
`RELATED APPLICATIONS
`0001) This application claims the benefit of U.S. Provi
`sional Application No. 60/433,059, filed Dec. 13, 2003, the
`entire disclosure of which is hereby incorporated by refer
`CCC.
`
`TECHNICAL FIELD
`0002 The described subject matter relates to electronic
`computing Systems, and more particularly to Systems and
`methods for remote network access.
`
`BACKGROUND
`0.003 Consumers and businesses are increasingly
`demanding the ability to acceSS computer network resources
`from alternate locations. Usage Scenarios gaining in popu
`larity include employee access to corporate networks, Sup
`plier access to customer networks, Student access to School
`networks, and others. These networks are referred to in this
`document as “target” networks.
`0004 Traditionally, this access has been provided via
`dial-up telephone-based connections directly between the
`end user and the remote network. With the ubiquity of the
`Internet, and given the large number of advantages of using
`Internet-based connections, Virtual Private Networks
`(VPNs) have begun to be implemented to meet these needs.
`VPNs make use of encryption technologies to privately and
`Securely transport Sensitive data acroSS the public Internet.
`0005 VPNs based on World Wide Web technologies are
`relatively new to the market, and are rather primitive in their
`capabilities. Common VPN implementations enable a
`remote user to access, via a Web browser, a very limited
`Subset of resources on a target network. Usually included are
`access to intranet documents (internal websites), access to
`e-mail in a restricted form, and occasionally access to files
`stored on network file servers.
`0006 Existing VPN implementations are subject to
`Severe limitations in their usability. In particular, they are all
`restricted in the types of functionality they can provide by
`the intrinsic capabilities of common Web browsers and by
`the facilities of the Hypertext Transfer Protocol (HTTP).
`Only very basic file transferring, the display of websites, and
`the use of applications Specifically designed to run within
`the constraints of Web technology can be achieved.
`0007 Accordingly, improved systems and methods for
`providing remote network access are desirable.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0008 FIG. 1 is a schematic illustration of an exemplary
`computing device that can be utilized to implement one or
`more computing devices in accordance with the described
`embodiment;
`0009 FIG. 2 is a schematic illustration of an exemplary
`computing network in accordance with one described
`embodiment;
`0.010
`FIG. 3 is a schematic illustration of an exemplary
`computing network in accordance with another described
`embodiment;
`
`0011 FIG. 4 is a schematic illustration of an exemplary
`computing network in accordance with another described
`embodiment;
`0012 FIG. 5 is a schematic illustration of software
`modules resident in an exemplary client computer; and
`0013 FIG. 6 is a schematic illustration of software
`modules resident in an exemplary network computer.
`
`DETAILED DESCRIPTION
`
`Overview
`0014.
`Described herein are exemplary computer-based
`Systems and methods for providing remote network access.
`The methods described herein may be embodied as logic
`instructions on a computer-readable medium. When
`executed on a processor, the logic instructions cause a
`general purpose computing device to be programmed as a
`Special-purpose machine that implements the described
`methods. The processor, when configured by the logic
`instructions to execute the methods recited herein, consti
`tutes Structure for performing the described methods.
`0015. An exemplary remote network access system
`includes client Software modules and Server Software mod
`ules that interact to enable the remote computer running the
`client Software to access System resources on a network
`connected to a gateway System running the Server Software.
`The Server Software is executed on computers that are
`logically located inside the destination network. The client
`Software generally runs on an end user's computer.
`0016. The server Software includes a first group of com
`ponents for managing the network data Stream and a Second
`group of components for managing the configuration and
`system state. There are two different embodiments of the
`client software. The first embodiment implements a VPN
`Client, which creates a network interface directly to the
`destination network, causing the end user's computer to
`appear as if it were physically a part of that network. The
`Second embodiment is a browser-based method of remote
`access, in which all remote acceSS is done either within or
`via the web browser.
`0017. One exemplary implementation includes a third
`Software module, referred to herein as the Network Address
`Translation (NAT) agent, to connect remote networks to the
`server software. The NAT Agent may be installed on any
`computer at the remote network Site and automatically
`builds a VPN tunnel to the server, thereby connecting the
`remote network to that Server, and making it accessible to a
`client.
`0018 Various implementations of a remote access system
`involve some combination of clients, servers, and NAT
`agents. Servers may be placed either in a target network
`(e.g., in a De-Militarized Zone (DMZ) or another appropri
`ate place) or may be connected to the target network via an
`IPSec connection or a NAT agent. Clients, both browser
`based and VPN, then connect to the servers to the target
`network.
`An Exemplary Computing System
`0019 FIG. 1 is a schematic illustration of an exemplary
`computing device 130 that can be utilized to implement
`described embodiments. Computing device 130 can be
`
`8
`
`
`
`US 2006/0031407 A1
`
`Feb. 9, 2006
`
`utilized to implement various implementations in accor
`dance with described embodiments.
`0020 Computing device 130 includes one or more pro
`ceSSorS or processing units 132, a System memory 134, and
`a buS 136 that couples various System components including
`the system memory 134 to processors 132. The bus 136
`represents one or more of any of Several types of bus
`Structures, including a memory bus or memory controller, a
`peripheral bus, an accelerated graphics port, and a processor
`or local bus using any of a variety of bus architectures. The
`system memory 134 includes read only memory (ROM) 138
`and random access memory (RAM) 140. A basic input/
`output system (BIOS) 142, containing the basic routines that
`help to transfer information between elements within com
`puting device 130, such as during start-up, is stored in ROM
`138.
`0021 Computing device 130 further includes a hard disk
`drive 144 for reading from and writing to a hard disk (not
`shown), a magnetic disk drive 146 for reading from and
`Writing to a removable magnetic disk 148, and an optical
`disk drive 150 for reading from or writing to a removable
`optical disk 152 such as a CD ROM or other optical media.
`The hard disk drive 144, magnetic disk drive 146, and
`optical disk drive 150 are connected to the bus 136 by an
`SCSI interface 154 or some other appropriate interface. The
`drives and their associated computer-readable media provide
`nonvolatile Storage of computer-readable instructions, data
`Structures, program modules and other data for computing
`device 130. Although the exemplary environment described
`herein employs a hard disk, a removable magnetic disk 148
`and a removable optical disk 152, it should be appreciated
`by those skilled in the art that other types of computer
`readable media which can Store data that is accessible by a
`computer, Such as magnetic cassettes, flash memory cards,
`digital video disks, random access memories (RAMS), read
`only memories (ROMs), and the like, may also be used in
`the exemplary operating environment.
`0022. A number of program modules may be stored on
`the hard disk 144, magnetic disk 148, optical disk 152, ROM
`138, or RAM 140, including an operating system 158, one
`or more application programs 160, other program modules
`162, and program data 164. A user may enter commands and
`information into computing device 130 through input
`devices such as a keyboard 166 and a pointing device 168.
`Other input devices (not shown) may include a microphone,
`joystick, game pad, Satellite dish, Scanner, or the like. These
`and other input devices are connected to the processing unit
`132 through an interface 170 that is coupled to the bus 136.
`A monitor 172 or other type of display device is also
`connected to the buS 136 via an interface, Such as a video
`adapter 174. In addition to the monitor, personal computers
`typically include other peripheral output devices (not
`shown) Such as speakers and printers.
`0023 Computing device 130 commonly operates in a
`networked environment using logical connections to one or
`more remote computers, Such as a remote computer 176. The
`remote computer 176 may be another personal computer, a
`Server, a router, a network PC, a peer device or other
`common network node, and typically includes many or all of
`the elements described above relative to computing device
`130, although only a memory storage device 178 has been
`illustrated in FIG. 1. The logical connections depicted in
`
`FIG. 1 include a local area network (LAN) 180 and a wide
`area network (WAN) 182. Such networking environments
`are commonplace in offices, enterprise-wide computer net
`Works, intranets, and the Internet.
`0024. When used in a LAN networking environment,
`computing device 130 is connected to the local network 180
`through a network interface or adapter 184. When used in a
`WAN networking environment, computing device 130 typi
`cally includes a modem 186 or other means for establishing
`communications over the wide area network 182, Such as the
`Internet. The modem 186, which may be internal or external,
`is connected to the bus 136 via a serial port interface 156. In
`a networked environment, program modules depicted rela
`tive to the computing device 130, or portions thereof, may
`be stored in the remote memory storage device. It will be
`appreciated that the network connections shown are exem
`plary and other means of establishing a communications link
`between the computers may be used.
`0025 Generally, the data processors of computing device
`130 are programmed by means of instructions Stored at
`different times in the various computer-readable Storage
`media of the computer. Programs and operating Systems are
`typically distributed, for example, on floppy disks or CD
`ROMs. From there, they are installed or loaded into the
`Secondary memory of a computer. At execution, they are
`loaded at least partially into the computer's primary elec
`tronic memory. The inventions described herein includes
`these and other various types of computer-readable Storage
`media when Such media contain instructions or programs for
`implementing the Steps described below in conjunction with
`a microprocessor or other data processor. The invention also
`includes the computer itself when programmed according to
`the methods and techniques described below.
`Exemplary Network Architectures
`0026 FIGS. 2-4 are schematic diagrams of network
`architectures in which exemplary embodiments of Systems
`and methods for providing remote access to one or more
`target networks may be implemented. Operation of various
`components depicted in FIGS. 2-4 will be discussed below.
`0027. In the exemplary architecture depicted in FIG. 2,
`one or more remote access devices 210a, 210b, 210c estab
`lish a communication connection with a Point of Presence
`(POP) 220, which in turn establishes a communication
`connection with one or more target networks 240,250.
`0028) Remote access devices 210a, 210b, 210c may be
`any computer-based communication device, including a
`personal computer 210a, a personal digital assistant (PDA)
`210b, or a terminal device 210c. Remote access devices
`210a, 210b, 210c establish a communication with POP 220
`via a communication network 212. The particular form of
`communication network 212 is not critical. Communication
`network may comprise one or more direct communication
`links (e.g., a dial-up connection) between respective remote
`access devices 210a, 210b, 210c. Alternatively, communi
`cation network 212 may comprise a private data network
`Such as, e.g., an X.25 network, a local area network (LAN),
`a wide area network (WAN), or a public network Such as,
`e.g., the Internet.
`0029. In the exemplary implementation depicted in FIG.
`2, remote access devices 212a, 212b, 212c establish a
`communication connection with an Internet Protocol Secu
`
`9
`
`
`
`US 2006/0031407 A1
`
`Feb. 9, 2006
`
`rity (IPsec) concentrator 222 in POP 220. POP 220 may
`further comprise a plurality of devices that facilitate pro
`viding a communication link with target networks 240,250.
`In the exemplary implementation depicted in FIG. 2, POP
`220 comprises an access server 224, a SuperNAT 226, a
`WebTop Server 228, an MMD server 230, and a Daemon
`server 232.
`0030 POP 220 establishes a communication link
`between the IPSec concentrator 222 and one or more target
`networks 240, 250, via a communication network 214.
`Again, the particular implementation of communication
`network 214 is not important. Target networks 240, 250,
`respectively, comprise an IPsec concentrator 242, 252, that
`facilitates communication connections with one or more
`network resources 244, 246, 254, 256, respectively.
`0031. In the exemplary architecture depicted in FIG. 3,
`remote access devices 310a, 310b, 310c are configured to
`use a conventional web browser to establish remote acceSS
`to target networks 340, 350 via a POP320. Many of the
`components depicted in FIG. 3 are identical to those
`depicted in FIG. 2. For clarity and brevity, the description
`of these components will not be repeated. Remote acceSS
`devices 310a, 310b, 310c establish a connection with a
`WebTop server 322, which in turn establishes a communi
`cation connection with target networkS via an IPsec con
`centrator 324.
`0032. In the exemplary architecture depicted in FIG. 4,
`remote access devices 410a, 410b, 410c establish a com
`munication connection with remote networks 440, 450 via
`communication network 412. Many of the components
`depicted in FIG. 4 are identical to those depicted in FIG. 2.
`For clarity and brevity, the description of these components
`will not be repeated.
`Exemplary Application Programs and Data
`0033 FIG. 5 is a block diagram that shows various
`Software modules 510 resident in a computer-readable
`medium Such as, e.g., System memory 134 of the client
`computer depicted in FIG. 1. In the implementation
`depicted in FIG. 5, the client computer may implement a
`browser based remote access technique, referred to herein as
`a WebTop, or a client-VPN access method. A client com
`prises a user interface module 514, a WTP Protocol module
`518, a virtual adapter module 522, a reconfiguration system
`module 526, a local proxy module 530, an application
`tunneling module 534, a captive portal system module 538,
`an RSYNC module 542, a URL rewriter module 546, an
`email connector module 550, a software updater module,
`554, and an application distribution module 558.
`0034 FIG. 6 is a block diagram that shows various
`Software modules 610 resident in a computer-readable
`medium Such as, e.g., System memory 134 of a Server that
`interfaces with a client computer to provide a remote acceSS
`to one or more target networks. A client VPN comprises an
`administration module 614, a WTP Protocol module 618, a
`reconfiguration System module 622, a an application tun
`neling module 626, a NAT agent module 630, a captive
`portal system module 634, an RSYNC module 638, a central
`policy manager module 642, a network backup module 646,
`an e-mail connector module 650, a Software updater module,
`654, and an application distribution module 658.
`
`WTP Protocol
`0035). Overview
`0036). In exemplary implementations, clients and servers
`communicate using a Secure protocol referred to herein as
`the WTP protocol. The WTP protocol is implemented by
`WTP protocol modules 518, 618, operating on the client and
`server, respectively. The WTP protocol provides a secure,
`reliable communication connection between the client and
`the server.
`0037. When a client connects to the server, the WTP
`protocol modules 518, 618 establish a WTP connection
`between the client (either WebTop or VPN) and the server.
`This connection provides a Secure and reliable channel of
`communication between the client computer and the target
`network. In addition, the WTP protocol is used between
`Servers and NAT agents.
`0038. The WTP protocol has several unique characteris
`tics that make it Suitable for a remote acceSS application. The
`WTP protocol runs directly on Transmission Control Pro
`tocol (TCP) or User Datagram Protocol (UDP), making it
`compatible with Network Address Translation (NAT), which
`is a common requirement in remote acceSS environments.
`The WTP protocol is capable of managing communication
`connections with proxy servers, including standard HTTP
`proxies, CONNECT-based SSL proxies, and transparent
`proxies. This capability enables the WTP protocol to work
`correctly from inside corporate networks, hotels, and other
`places that implement proxy server technology.
`0039) Protocol Modes
`0040. The WTP protocol provides several modes of
`operation (e.g., UDP vs. TCP, HTTP proxy vs. CONNECT
`proxy VS. transparent proxy VS. direct, with and without
`proxy credentials, etc.). Therefore, the WTP protocol can
`implement logic to determine the most efficient connection
`method to use. If the most efficient means of communication
`is unavailable, it can automatically revert to the next
`method, and so on. In addition, the WTP protocol incorpo
`rates compression in both the client Software and the Server
`Software. Therefore, data transfer Speeds can be greatly
`improved over traditional remote access implementations.
`0041. The WTP protocol implements a secure connection
`between the client and the Server. It provides Strong authen
`tication of the end user via a user-configurable authentica
`tion method. For example, WTP can use SecuriD, RADIUS,
`or normal usernames and passwords. It protects data privacy
`by using industry-standard Advanced Encryption Standard
`(AES) encryption. It prevents “man-in-the-middle” attacks
`using digital Signature technology.
`0042. The WTP protocol has two basic modes of opera
`tion: message mode and tunnel mode. Message mode is used
`in a WebTop connection for all communication with the
`servers. When operating in message mode, WTP protocol
`module 518, 618 receives application-layer data and encap
`sulates the data directly into WTP messages. This is appro
`priate when data from applications is intercepted directly,
`before being written to the network, and without any pro
`tocol framing or headers attached.
`0043. This is always the case in WebTop connections.
`WebTop employs local proxies for the web browser and for
`any AppTunnel clients, directly capturing any application
`
`10
`
`
`
`US 2006/0031407 A1
`
`Feb. 9, 2006
`
`level protocol data that they produce. This data is then
`directly encapsulated into WTP messages and is forwarded
`to the server. The server recognizes the WTP messages as
`message-mode by information contained in the WTP head
`CS.
`0044) In message mode, the WTP server may function as
`a proxy for the client. The WTP server makes network
`connections to target network resources on behalf of the
`client. Once these connections are made, any data coming
`from the client is removed from the incoming WTP mes
`Sages and written directly to the proxy connection.
`0.045
`Return data is managed in a corresponding way.
`Incoming data on a proxy connection is encapsulated into
`WTP messages. These messages are then sent directly to the
`client, where they are unwrapped. The message's data is
`then written back to the WebTop client (i.e., either the web
`browser or an AppTunnels client).
`0046. In tunnel mode, the WTP modules implement a
`communication link that behaves much like an industry
`standard secure tunneling protocol such as IPSEC. Tunnel
`mode is responsible for the transmission of fully-formed
`network packets, complete with network header information
`and datalink protocol framing.
`0047 Tunnel mode data is captured from the virtual
`adapter module 522, which is described in greater detail
`below. When a tunnel mode packet is received from the
`virtual adapter module 522, the packet is directly encapsu
`lated in a tunnel mode WTP message and transmitted to the
`WTP Server.
`0048. The WTP server unwraps the packet, but rather
`than writing the data to a pre-built proxy connection, the
`packet is written directly to the target network. This is
`possible because the encapsulated packet is a fully-formed
`and valid network packet, complete with any addressing and
`network routing information necessary for the packet to get
`to its destination.
`0049. The target server processes the network packet as
`if it had been Sent by a directly connected computer on the
`Same local area network. Its reply packets are constructed in
`the usual way and are routed via Standard packet routing
`mechanisms.
`0050. When the WTP server eventually receives the
`return packet (and the network's routing configuration dic
`tates that it will), the packet is encapsulated directly in a
`WTP tunnel-mode message and Sent to the appropriate
`client. The client then un-wraps the packet and forwards it
`in-tact to the virtual adapter. The virtual adapter is then
`responsible for handing the packet back to the user's appli
`cation.
`0051) Security Features
`0.052 As a secure remote access protocol, the WTP
`protocol modules 518, 618 ensure user and server identities
`through strong cryptographic authentication. The WTP mod
`ules 518, 618 encrypt all data with high-strength industry
`Standard cryptography algorithms, including the Advanced
`Encryption Standard (AES) and the Rivest-Shamir-Adleman
`(RSA) algorithms. Each Session uses a unique encryption
`key, which is Securely exchanged using the Diffe-Hellman
`(DH) key exchange algorithm. Message authentication is
`
`provided, preventing modification of messages en route, as
`well as preventing the injection of fake messages into the
`data Stream.
`0053. The first step to secure remote access is set-up of a
`WTP session. In addition to being secure, the transactions
`are executed quickly and with a minimum number of Steps,
`in order to provide high performance. In an exemplary
`implementation, only two messages are required to establish
`a WTP Session.
`0054 Before initiating a connection, the WTP protocol
`module 518 on the client generates a DH value set. The first
`WTP session set-up message sent by the client to the server
`includes the client's public portion of the DH data. The WTP
`protocol module 618 on the server receives the client's DH
`data and generates corresponding data, the public portion of
`which is returned to the client in a second WTP message.
`This public data is encrypted with the server's private RSA
`key, So that it can only be decrypted by the Server's corre
`sponding public key. This provides proof of the fact that the
`Server is genuine, and prevents a man-in-the-middle attack.
`The WTP protocol module 518 on the client receives this
`data from the server, decrypts it (thereby proving the identity
`of the server), and computes the encryption key. At the end
`of this process, the client and server have established a WTP
`Session and now possess a shared encryption key. All future
`WTP transactions take place using the encrypted key.
`0055 Should re-keying be necessary (as defined by a
`maximum key lifetime or other policy), this can be accom
`plished with a re-key message of the same format as the
`initial message, followed by a signed response message.
`0056. During data transfer, encryption in WTP is done on
`a per-message basis using, e.g., the AES algorithm. How
`ever, WTP Supports adding additional algorithms. Each
`payload is encrypted using AES-192, using the encryption
`key determined by the Session Set-up.
`0057 Prior to encryption, the payload is passed through
`a padding and hashing filter that ensures the payload is
`Suitable for encryption, and provides additional obfuscation
`of the encrypted data.
`0058. During message transfer, each encrypted message
`that is received by either the client WTP protocol module
`518 or the server WTP protocol module 618 is decrypted
`using the shared encryption key. This decryption proceSS
`also serves to authenticate the message: If the message does
`not decrypt cleanly, it will not be forwarded on. Normal
`damage that can occur during network transmission will
`cause decryption failure, and the protocol drops any packets
`for which decryption fails. If decryption Succeeds, therefore,
`it may be assumed that the received packet is authentic.
`0059. In addition, any attempt to modify a packet inten
`tionally will result in a failed decryption and a dropped
`packet. Therefore, users are protected from third parties
`tampering with the data Stream. New packets that are created
`by a third party must be encrypted in order for the client or
`Server to decrypt them. However, because the third party
`will not have the correct encryption key (because DH was
`used to Securely exchange the key), the attacker's packet
`will fail to decrypt properly and will be dropped. Therefore,
`it is virtually impossible to inject a rogue packet into the data
`Stream.
`
`11
`
`
`
`US 2006/0031407 A1
`
`Feb. 9, 2006
`
`0060 Compression
`0061. To maintain adequate performance over slow com
`munication links, the current remote access System employs
`compression immediately prior to encryption, while the data
`is still amenable to compression. The WTP protocol supports
`a pluggable compression architecture, Similar to the encryp
`tion algorithm plug-in architecture. Exemplary implemen
`tations of WTP make use of the deflate compression algo
`rithm.
`Because compression is most useful on slow links,
`0.062
`the WTP protocol supports enabling and disabling compres
`Sion on a per-connection basis. The remote acceSS Software
`detects the Speed of the underlying network link and enables
`compression only on communication links having a data
`transfer rate beneath a threshold. The threshold may be fixed
`or may be adjusted dynamically as a function of network
`traffic conditions.
`
`Connection Modes
`0.063. One requirement of a remote access protocol is
`compatibility with whatever network the remote user hap
`pens to be connected to at the time. To provide compatibility
`with all sorts of network settings, the WTP protocol supports
`four different connection modes. Each connection mode
`offers the same high level of security, but they differ in their
`network compatibility and performance.
`0064.
`In networks that support it, the most efficient and
`simplest protocol mode is the Direct Connection mode. In
`this mode, WTP messages are written directly to a TCP or
`UDP socket connected between client and server. There is no
`additional protocol overhead to reduce data transfer perfor
`mance. TCP is used on unreliable connections and on
`connections with which UDP connections fail, Such as in
`networks with a low maximum transmission unit (MTU).
`0065. Because WTP protocol packets can be encapsu
`lated directly into TCP packets or UDP datagrams, the WTP
`protocol is natively compatible with any Standard network
`address translation device. The WTP protocol enhances this
`compatibility by not placing any lower-level network rout
`ing information in any high-level data structures. Therefore,
`this mode of communication will be used most commonly in
`home environments and corporate environments that do not
`require the use of a proxy server. To further enable the latter
`case, the protocol operates using the same TCP ports that
`standard web traffic uses. Many firewalls permit this sort of
`traffic in and out of the network.
`0.066
`For networks that require the user of a proxy server,
`the Second most efficient method is a direct connection
`through that proxy server to the WTP server. This is possible
`because most proxy ServerS allow the use of a proxy method
`known as CONNECT, to facilitate the use of SSL. These
`servers generally also allow for the use of WTP, as it
`operates in a similar way to native SSL. Because the proxy
`server knits together an internal WTP connection with an
`external connection, its performance is also generally good.
`0067. Some networks prevent standard SSL use alto
`gether, preferring to proxy Such data in Standard proxy
`Servers. Other networks make use of transparent proxy
`Servers, which tend to intercept direct SSL connections. In
`these networks, the WTP protocol supports an HTTP encap
`sulation mode. WTP messages a