17
`
`# #
`
`Fields are laid out in the following manner:
`srcaddrornet= 1ocalsPI= peeraddr= peerSPI==
`#
`realsrcaddr= loca1addr= key:
`
`# The following entry sets up a tunnel between hosts
`behind SW1
`
`# and hosts behind SW2.
`src=l72.16.o.0 localSPI=666 peer=192.16B.100.5
`pee:-SPI=777 \
`rea1srcaddr=l92 . 168 . 100 . S loca1addIs=0 . 0 . 0 . 0
`
`key=0xdead.beeffadebabe
`
`Hypothetical SW2 Config.Fi1e
`
`Fields are laid out in the following manner:
`srcaddrornet= loca1SPI= peeraddr= peerSPI=
`realsz-caddr= 1ocaladdr= key:
`
`# The following entry sets up a tunnel between hosts
`behind SW1 and
`
`# hosts behind SW2.
`
`src=172.17.0.0 1ocalSPI=777 peer=192.168.20.1
`pee:-SPI=-666 \
`realsrcaddr=192 . 168 .20 . 1 localaddr=0 . 0.0 - 0 \
`key=0xdead.beeffadebahe
`
`\V1th this setup, all trafiic is encrypted using one key, no matter who is
`
`talldng to whom. For example, traffic from H2 to H] as well as trafific fi'om H3
`
`to H1 will be encrypted with one key. Although this setup is small and simple, it
`
`may not be enough.
`
`What happens if H2 cannot trust H3? In this case, the administrator can
`
`set up security associations at the host level. In this case, we have to rely on the
`
`SP1 field of the SA, since the receiving firewall cannot tell from the datagram
`
`header which host behind the sending firewall sent the packet. Since the SP1 is
`
`stored in IPSEC datagrams, we can do a lookup to obtain its value. Below are
`
`the sample configuration files for both firewalls again, but this time. each host
`
`combination communicates with a different key, Moreover, H2 excludes H3
`
`from communications with H], and H3 excludes H2 in the same way.
`
`288
`
`

`
`18
`
`# Hypothetical SW1 Config File
`
`# #
`
`Fields are laid out in the following manner:
`srcaddrornet= lcca1SPI= peeraddr- peerSPI=
`#
`realsrcaddr= localaddr= key=
`
`# The following entry sets up a secure link between H2
`and H1
`
`src=172.l6.0.2 loca1SPI=666 peer=192.168.lO0.5
`
`peerSPI=777 \
`rea1srcaddr=192.168.100.5
`
`localaddrs=178.17.128.7l \
`key=0xOa0a0a0a0aOa0a0a
`
`# The following entry sets up a secure link between H3
`and H1
`
`src=172.16.0.1 localSPI=555 peer=192.168.100.5
`
`peerSPI=888 \
`realsrcaddr=192.16B.100.5
`lcca1addrs=178.17.l28.71 \
`key=ox0b0b0b0bob0bobob
`
`Hypothetical SW2 Config File
`
`Fields are laid out in the following manner:
`srcaddrornet= loca1SPI= peeraddr= peerSPI=
`realsrcaddr= localaddra key=
`
`# The following entry sets up a secure link between H2
`and H1
`
`src=172.17.128.71 loca1SPI=777 peer-l92.l68.20.1
`peerSPI=666 \
`rea1srcaddr=192.168.20.1 localaddrs=172.16.o.2 \
`
`key=Ox0aOa0a0aOa0a0aOa
`
`# The following entry sets up a secure link Between H3
`and H1
`
`src=172.17.l28.71 localSPI=888 peer=192.168.2o.l
`peerSPI=555 \
`realsrcaddr=192.168.2o.1 localaddrs=172.16.0.1 \
`
`key= OxObObObObObOb0bOb
`
`Figure 4 is a block diagram showing in more detail one embodiment of
`
`an IPSEC-enabled application level gateway firewall 18. Application level
`
`gateway firewall 18 provides access control checking of both encrypted and
`
`289
`
`

`
`l9
`
`unencrypted messages in a more secure environment due to its network-
`
`separated architecture. Network separation divides a system into a set of
`
`independent regions or burbs, with a domain and a protocol stack assigned to
`
`each burb. Each protocol stack 40:: has its own independent set of data
`
`structures, including routing information and protocol information. A given
`
`socket will be bound to a single protocol stack at creation time and no data can
`
`pass between protocol stacks 40 without going through proxy space. A proxy 50
`
`therefore acts as the go-between for transfers between domains. Because of this,
`
`a malicious attacker who gains control of one of the regions is prevented from
`
`being able to compromise processes executing in other regions. Network
`
`separation and its application to an application level gateway is described in
`
`“SYSTEM AND METHOD FOR ACHIEVING NETWORK SEPARATION”,
`
`U.S. Application No. 08/599,232, filed February 9, 1996 by Gooderum et al.
`
`In the system shown in Figure 4, the in-bound and out-bound datagram
`
`processing of a security association continues to follow the conventions defined
`
`by the network separation model. Thus all datagrams received on or sent to a
`
`given burb remain in that burb once decrypted. In one such embodiment SADB
`
`socket 78 has been defined to have the type ‘sadb’. Each proxy 50 that requires
`
`access to SADB socket 78 to execute its query as to whether the received
`
`message was encrypted must have create permission to the sadb type.
`
`The following is list of specific requirements that a system such as is
`
`shown in Figure 4 must provide. Many of the requirements were discussed in
`
`the informari on provided earlier in this document.
`
`1.
`
`Firewall applications may query the IPSEC subsystem to determine if
`
`traffic with a given address is guaranteed to be encrypted.
`
`Receipt of an unencrypted datagram from an address that has a SA results
`
`in the datagram being dropped and an audit message being generated.
`
`On receipt of encrypted protocol datagrams the SADB searches will be
`
`done using the SP1 as the primary key. The source address will a
`
`secondary key. The SA returned by the search will be the SA which
`
`matches the SP1 exactly and has the longest match with the address.
`
`290
`
`

`
`20
`
`A search of the SADB for a SPI that finds an entry that is marked as SA
`
`for a dynamic IP will not consider the address in the search process.
`
`A search of the SADB for 2. SP1 that finds an entry thatis marked as a SA
`
`for a tunnel mode connection will to consider the address if it is (0.0.0.0)
`
`i.e INADDR.
`
`On receipt of a non-IPSEC datagram the SADB will be searched for an
`entry that matches the src address. If :1 SA is found the datagram will be
`
`dropped and an audit message sent.
`SADB searches on output will be done using the DST address as key. If
`
`more than one SA entry in the SADB has that address the first one with
`
`the maximum address match will be returned.
`
`The SADB must be structured so that searches are fast regardless if the
`
`search is done by SP1 or by address.
`
`The SADB must provide support for connections to a site with a fixed
`
`SP1 but changing IP address. SA entries for such connections will be
`
`referred to as Dynamic Address Sites, or just Dynamic entries.
`
`When a dynamic entry is found by a SP] search, the current datagram’s
`
`SRC address, which is required to ensure that the return datagrams are
`
`properly encrypted, will be recorded in the SA only afier the AH
`checking has passed successfully. (This is because ifthe address is
`
`recorded before AH passes then an attacker can cause return packets of
`
`an outgoing connection to be transmitted in the clear.)
`
`A failure of an AH check on a dynamic entry results in an audit message.
`
`In an embodiment where the firewall requires that all connections use
`
`both AH and ESP, on receipt the order should be AH first ESP second.
`
`The processing structure on both input and output should try to minimize
`
`the number of SADB required loolcups.
`
`Returning to Figure 4, in one embodiment firewall l 8 includes a crypto
`
`engine interface 80 used to encrypt an IPSEC payload. Crypto engine interface
`
`80 may be connected to a sofiware encryption engine 82 or to a hardware
`
`291
`
`

`
`21
`
`encryption engine 84. Engines 82 and 84 perform the actual encryption function
`using, for example, DES-CBC. In addition, sofiware encryption engine 82 may
`
`include the keyed MD5 algorithm used for AH.
`in one embodiment, crypto engine interface 80 is a utility which provides
`
`5
`
`10
`
`a consistent interface between the software and hardware encryption engines. As
`shown in Figure 4, in one such embodiment interface 80 only supports the use of
`the use of hardware cryptographic engine 84 for IPSEC ESP processing. The
`significant design issue that interface 80 must deal with is that use of a hardware
`encryption engine requires that the processing be down in disjoint steps
`operating in different interrupt contexts as engine 84 completes the various
`
`processing steps.
`The required information is stored in a request structure that is bound to
`
`the IP datagram being processed. The request is of type crypto___request__t.
`
`This structure is quite large and definitely does not contain a minimum state set.
`
`15
`
`In addition to the definition of the request data structure, this software
`
`implementing interface 80 provides two fimctions which isolate the decision of
`which cryptographic engine to use. The crypt_des_encryp1: function is for
`
`use by the IP output processing to encrypt a datagram. The
`crypt_des_decrypt function is for use by the IP input processing to
`
`decrypt a datagram. If hardware encryption engine 84 is present and other
`hardware usage criteria are met the request is enqueued on a hardware processing
`
`queue and a return code indicating that the cryptographic processing is in
`progress is returned. If software engine 82 is used, the return code indicates that
`the cryptographic processing is complete. In the former case, theeontinuation of
`the IP processing is delayed until afier hardware encryption is done. Otherwise
`
`25
`
`it is completed as immediately in the same processing stream.
`
`There are two software cryptographic engines 82 provided in the IPSEC
`
`software. One provides the MD5 algorithm used by the IPSEC AH processing,
`
`and the other provides the DES algorithm used by the IPSEC ESP processing.
`
`30
`
`This sofiware can be obtained from the US Government [PSEC implementation.
`
`292
`
`

`
`22
`
`In one embodiment hardware cryptographic engine 84 is provided by a
`Cylinlt SafeNode processing board. The interface to this hardware card is
`provided by the Cylink device driver. A significant aspect ofthe Cylink card
`that plays a major part in the design of the IPSEC Cylink driver is that the card
`functions much like a low level subroutine interface and requires software
`support to initiate each processing step. Thus to encrypt or decrypt an individual
`datagram there are a minimum of two steps, one to set the DES initialization
`vector and one to do the encryption. Since the IP processing can not suspend
`
`itself and wait while the hardware completes and then be rescheduled by the
`hardware interrupt handler, in one embodiment a finite state machine is used to
`tie sequences of hardware processing elements together. In one such
`embodiment the interrupt handler looks at the current state, executes a defined
`
`afier state function, transitions to the state and then executes that state’ s start
`
`function.
`
`One function, cyl_enqueue_request, is used to initiate either an
`
`encrypt or a decrypt action. This function is designed to be called by
`cryptographic engine interface 80. All ofthe information required to initiate the
`processing as well as the function to be performed after the encryption operation
`is completed is provided in the request structure. This function will enqueue the
`request on the hardware request queue and start the hardware processing if
`necessary.
`
`A system 30 which can be used for firewall-towrorkstation encryption is
`shown in Figure 5. In Figure 5, system 30 includes aworkstation l2
`communicating through a firewall 14 to an unprotected network 16 such as the
`Internet. System 30 also includes a workstation 32 communicating directly with
`firewall 14 through unprotected network 16. Firewall 14 is an application level
`gateway incorporating IPSEC handling as described above. (It should be noted
`that IPSEC security cannot be used to authenticate the personal identity of the
`
`sender for a firewall to firevmll transfer. When IPSEC is used, however, on a
`single user machine such as a portable personal computer, IPSEC usage should
`
`30
`
`293
`
`

`
`23
`
`be protected with 9. personal identification number (PIN). In these cases IPSEC
`can be used to help with user identification to the firewall.)
`According to the IPSEC RFC's, you can use either tunnel or transport
`mode with this embodiment based on your security needs. In certain situations,
`the communications must be sent in tunnel mode to hide unregistered addresses.
`Although specific embodiments have been illustrated and described
`herein, it will be appreciated by those of ordinary slcill in the art that any
`arrangement which is calculated to achieve the same purpose may be substituted
`for the specific embodiment shown. This application is intended to cover any
`adaptations or variations ofthe present invention. Therefore, it is intended that
`this invention be limited only by the claims and the equivalents thereof.
`
`294
`
`

`
`5
`
`10
`
`15
`
`What is claimed is:
`
`A method ofregulating the flow of messages through a firewall having a
`1.
`stack includes an Internet
`network protocol stack, wherein the network protocol
`Protocol (IP) layer, the method comprising the steps of:
`determining, at the IP layer, if a message is encrypted;
`ifthe message is not encrypted, passing the unencrypted message up the
`network protocol stack to an application level proxy; and
`if the message is encrypted, decrypting the message and passing the
`decrypted message up the network protocol stack to the application level proxy,
`wherein the step ofdecrypting the message includes the step of executing a
`
`procedure at the 1P layer to decrypt the message.
`
`2.
`
`A method of authenticating the sender of a message within a computer
`in the network protocol stack
`
`system having a network protocol stack, where
`includes an Internet Protocol (IP) layer, the method comprising the steps of:
`determining, at the IP layer, if the message is encrypted;
`if the message is encrypted, decrypting the message, wherein the step of
`decrypting the message includes the step of executing a process at the IP layer to
`
`20
`
`decrypt the message;
`passing the decrypted message up the network protocol stack to an
`
`application level proxy;
`detennining an authentication protocol appropriate for the message; and
`executing the authentication protocol to authenticate the sender of the
`
`25 message.
`
`The method according to claim 2 wherein the step of detennining an
`3.
`authentication protocol appropriate for the message includes the steps of:
`determining a source IP address associated with the message; and
`determining the authentication protocol usociated with the source IP
`
`address.
`
`295
`
`

`
`25
`
`4.
`
`The method according to claim 2 wherein the message includes security
`wherein the step of determining an authentication protocol
`
`parameters index and
`appropriate for the message includes the steps of:
`determining the authentication protocol associated with a dynamic IP
`rmining the authentication protocol includes the
`
`address, wherein the step of dete
`
`step of looking up a security assoc
`determining a current address associated with the dynamic source IP
`
`iation based on the security parameters index;
`
`address; and
`binding the current address to the security parameters index.
`
`A firewall, comprising:
`
`a first communications interface;
`
`a second communications interface;
`a network protocol stack connected to the first and the second
`communications interfaces, wherein the network protocol stack includes an
`
`Internet Protocol (IP) layer and a transport layer;
`a decryption procedure, operating at the IP layer, wherein the decryption
`edure decrypts encrypted messages received at one of said first and second
`proc
`communications interfaces and outputs decrypted messages; and
`a proxy, connected to the transport layer ofsaid network protocol stack,
`in the proxy receives decrypted messages from the decryption procedure
`s an authentication protocol based on the content of the decrypted
`
`and execute
`
`where
`
`message.
`
`A firewall, comprising:
`
`a first communications interface;
`
`a second communications interface;
`a first network protocol stack connected to the first communications
`interface, wherein the first network protocol stack includes an Internet Protocol
`
`(IP) layer and a transport layer;
`
`296
`
`

`
`26
`
`a second network protocol stack connected to the second
`cornrmmications interface, wherein the second network protocol stack includes
`
`an Internet Protocol (IP) layer and a transport layer;
`a decryption procedure, operating at the IP layer of the first network
`protocol stack, the decryption procedure receiving encrypted messages received
`by said first communications interface and outputting decrypted messages; and
`a proxy, connected to the transport layers of said first and second network
`protocol stacks, the proxy receiving decrypted messages fi-om the decryption
`procedure and executing an authentication protocol based on the content of the
`
`decrypted message.
`
`The firewall according to claim 6 wherein the firewall further includes:
`
`a third communications interface; and
`a third network protocol stack connected to the third communications
`interface and to the proxy, wherein the third network protocol stack includes an
`Internet Protocol (IP) layer and a transport layer and wherein the second and
`
`third network protocol stacks are restricted to first and second burbs,
`
`respectively.
`
`A method of establishing a virtual private network between a first and a
`8.
`second network, wherein each network includes an application level gateway
`firewall which uses a proxy operating at the application layer to process traffic
`through the firewall, wherein each firewall includes a network protocol stack and
`wherein each network protocol stack includes an Internet Protocol (IP) layer, the
`
`method comprising the steps of:
`transferring a connection request from the first network to the second
`
`network;
`determining, at the IP layer of the network protocol stack of the second
`
`network's firewall, if the connection request is encrypted;
`
`297
`
`

`
`27
`
`if the connection request is encrypted, decrypting the request, wherein the
`step of decrypting the request includes the step ofexecuting a procedure at the IP
`layer of the second network’s firewall to decrypt the message;
`passing the connection request up the network protocol stack to an
`
`application level proxy;
`determining an authentication protocol appropriate for the connection
`
`request;
`executing the authentication protocol to authenticate the connection
`
`request; and
`if the connection request is authentic, establishing an active connection
`
`between the first and second networks.
`
`The method according to claim 8 wherein the step of executing the
`9.
`authentication protocol includes the step of executing program code within the
`firewall of the second network to mimic a challenge/response protocol executing
`
`on a server internal to the second network.
`
`10.
`
`The method according to claim 8 wherein the step of executing the
`
`authentication protocol includes the step of executing program code to execute
`
`the authentication protocol in line to the session.
`
`11.
`
`The method according to claim 8 wherein the step of determining an
`
`authentication protocol includes the step of determining ifthe connection request
`arrived encrypted and selecting the authentication protocol based on whether the
`
`connection request was encrypted or not encrypted.
`
`298
`
`

`
`Pa:‘é‘f°1:
`Ofiice
`
`2.13
`
`Application No:
`Claims searched:
`
`GB 9719816.2
`1-] 1
`
`Examiner:
`Date of search:
`
`B.J.SPEAR
`21 January 1998
`
`Patents Act 1977
`
`Search Report under Section 17
`
`Databases searched:
`
`UK Patent Office collections, including GB, EP, W0 & US patent specifications, in:
`
`UK Cl (Ed.P): H4P (PPEB,PDCSA,PDCSC)
`
`Int Cl (Ed.6): H04L 9/00, 9/32, 29/06, 29/08
`
`Other:
`
`Online:WPI, INSPEC
`
`Documents considered to be relevant:
`
`Identity of document and relevant passage
`
`W097/26734A1
`
`(Raptor Systems) Whole document, eg Figs 1,3 and
`pages 6-12
`
`W097/26731Al
`
`(Raptor Systems) Whole document, eg Figs 1,3 and
`pages 7-12
`
`1,2.S,6,8
`
`W097/26735Al
`
`(Raptor Systems) Whole document, eg Figs 1,3
`and pages 4-10
`
`W097/23972A1
`
`(V-ONE Corp) Whole document, eg Figs 1,2 and
`claim 1.
`
`W097/l334OA1
`
`(Digital Secured Networks) Whole document, eg
`pages 7-13
`
`Document indicating lack of novelty or inventive step
`Document indicating lack of inventive step if combined
`with one or more other documents of same category.
`
`Member of the same patent family
`
`A Document indicating technological background and/or state of the art.
`P Document published on or after the declared priority due but before
`the filing date of this invention.
`Patent document published on or after, but with priority date earlier
`than, the filing date of this application.
`
`E
`
`An Executive Agency of the Department of Trade and Industry
`
`299
`
`

`
`Intemational Bureau
`WORLD INTELLECTUAL PROPERTY ORGANIZATION
`
`INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`‘ (51) International Patent Classification 5 =
`H04Q 1]/04, H04L 12/22
`
`—
`
`(11) International Publication Number:
`_
`_
`,
`(43) International Publication Date:
`
`W0 98/27783
`
`25 June 1998 (25.06.98)
`
`(21) International Application Number:
`
`PCT/IB97/01563
`
`(22) International Filing Date:
`
`12 December 1997 (l2.l2.97)
`
`(30) Priority Data;
`08/769,649
`
`19 December 1996 (19.12.96)
`
`US
`
`(71) Applicant (far all designated States except US): NORTHERN
`TELECOM LIMITED [CA/CA]; World Trade Center of
`Montreal, 8th floor, 380 St. Antoine Street West, Montreal,
`Quebec H2Y 3Y4 (CA).
`
`(72) Inventors; and
`(75) Inventors/Applicants (for US only): TELLO, Antonio, G.
`[US/US]; 114 Fountain Hills Drive, Garland, TX 75044
`(US). HUI, Margaret [US/US]; 9920 Forest Lane #208,
`Dallas, TX 75243 (US). HOLMES, Kim [US/US]; 5409
`Scenic Drive, Rowlett, TX 75088 (US).
`
`(74) Agents: MCCOMBS, David et al.; Haynes and Boone, L.L.P.,
`Suite 3100, 901 Main Street, Dallas, TX 75202-3789 (US).
`
`(81) Designated States: AL, AM, AT, AU, AZ, BA, BB, BG, BR,
`BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE,
`GH, HU. IL, 13, JP. KE, KG. KP. KR. KZ, LC, LK, LR,
`LS, LT, LU, LV, MD, MG, MK, MN, MW, MX, NO, NZ,
`PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TI,
`UA, UG, US, UZ, VN, YU, ZW, ARIPO patent (GH, GM,
`KE, LS, MW, SD, SZ, UG, ZW), Eurasian patent (AM, AZ,
`BY, KG, KZ, MD, RU, TJ, TM), European patent (AT, BE,
`CH, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL,
`PT, SE), OAPI patent (BF, BJ, CF, CG, CI, CM, GA, GN,
`ML, MR, NE, SN, TD, TG).
`
`Published
`
`With international search report.
`
`(54) Title: VIRTUAL PRIVATE NETWORK SERVICE PROVIDER FOR ASYNCI-IRONOUS TRANSFER MODE NETVVORK
`
`(57) Abstract
`
`A virtual private network service provider is used to transfer data over a data network to a final destination, with third—party billing.
`The method comprises the steps of: prompting the user at a data terminal to select a destination, password, and call type; sending a set—up
`message to the data network; selecting a virtual private network provider through the data network; the virtual private network provider
`giving an encryption key to the user. and then prompting the user for a password and a user identification; encrypting the password, and
`sending the user identification and the encrypted password to the virtual private network provider;
`the virtual private network provider
`decrypting the encrypted password, and verifying the password; the virtual private network provider providing an authorization code; and
`the data terminal transferring the data through the data network to the final destination, using the authorization code.
`
`300
`
`

`
`FOR THE PURPOSES’ OF INFORMATION ONLY
`
`Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT.
`Slovenia
`SI
`LS
`Lesotho
`ES
`Albania
`LT
`SK
`Lithuania
`Slovakia
`FI
`Armenia
`SN
`LU
`FR
`Austria
`Senegal
`Luxembourg
`Swaziland
`SZ
`LV
`Latvia
`GA
`Australia
`TD
`Chad
`Monaco
`MC
`GE
`Azerbaijan
`TG
`MD
`GE
`Togo
`Republic of Moldova
`Bosnia and Herzegovina
`MG
`TJ
`GH
`Barbados
`Tajikistan
`Madagascar
`TM
`Turkmenistan
`MK
`GN
`The former Yugoslav
`Belgium
`TR
`GR
`Burkina Faso
`Turkey
`Republic of Macedonia
`TT
`Mali
`HU
`Trinidad and Tobago
`Bulgaria
`Ukraine
`UA
`Benin
`[E
`Mongolia
`UG
`Mauritania
`[L
`Brazil
`Uganda
`US
`United States of America
`Malawi
`Belarus
`IS
`Uzbekistan
`Mexico
`UZ
`IT
`Canada
`Viet Nam
`VN
`JP
`Niger
`Central African Republic
`YU
`Netherlands
`KE
`Yugoslavia
`Congo
`ZW
`Zimbabwe
`KG
`Switzerland
`Norway
`New Zealand
`KP
`Cote d’Ivoirc
`Poland
`Cameroon
`China
`Portugal
`Romania
`Cuba
`Russian Federation
`Czech Republic
`Sudan
`Germany
`Sweden
`Denmark
`Estonia
`Singapore
`
`Spain
`Finland
`France
`Gabon
`United Kingdom
`Georgia
`Ghana
`Guinea
`Greece
`Hungary
`Ireland
`Israel
`Iceland
`Italy
`Japan
`Kenya
`Kyrgyzstan
`Democratic People's
`Republic of Korea
`Republic of Korea
`Kazakstan
`Saint Lucia
`Liechtenstein
`Sri Lanka
`Liberia
`
`KR
`KZ
`LC
`LI
`LK
`LR
`
`ML
`MN
`MR
`MW
`MX
`NE
`NL
`NO
`NZ
`PL
`PT
`RO
`RU
`
`SE
`SG
`
`301
`
`

`
`W0 98I27783
`
`PCT/IB97/01563
`
`VIRTUAL PRIVATE NETWORK SERVICE PROVIDER
`FOR ASYNCHRONOUS TRANSFER MODE NETWORK
`
`Technical Field
`
`The invention relates generally to asynchronous transfer mode (“ATM”)
`
`networks and virtual private networks (“VPN”), such as those ofi'ered by MCI
`
`and Sprint, and, more particularly, to a method of using a VPN to transfer
`
`data over a data network, with third-party billing.
`
`Background of the Invention
`For example, local
`Telephone service provide__rs ofi'er third-party
`and long distance telephone companies ofl'er calling cards for third party
`
`billing.
`
`VPNs exist to provide the sense of a private network among a
`
`company’s locations. The lines/trunks of a VPN are actually shared among
`
`several companies, to reduce costs, yet to each company the VPN appears to
`be that company’s own private network. However, a user at a remote data
`terrninal, such as a portable computer in a hotel room, can not immediately
`charge his company for the access time to a data net, such as the Internet.
`Instead, his access time is charged to his hotel room, and so he must pay the
`
`inflated rates that hotels charge for phone service.
`
`What is needed is a VPN service provider that offers remote access for
`
`users belonging to a VPN, user authorizations to prevent delinquent access
`
`into the VPN, and convenient third-party billing.
`
`Summary of the Invention
`The present invention, accordingly, provides a system and method for
`using a VPN service provider to transfer data over a data network to a final
`destination, with third-party billing. The method comprises the steps of:
`prompting the user at a data terminal to select a destination, password, and
`call type; selecting a VPN through the data network; giving an encryption key
`to the user, and then prompting the user for a password and a user
`identification; verifying the password, and providing an authorization code to
`
`-1-
`
`CONFIRMATION COPY
`
`302
`
`

`
`W0 98l27783
`
`PCT/[B97/01563
`
`the user; and allowing the user to transfer the data through the data network
`
`to the final destination, using the authorization code.
`
`In another feature of the invention, the method further comprises
`
`negotiating for more bandwidth for the user, and including within the
`
`authorization code a grant of additional bandwidth.
`
`In another feature of the invention, the method further comprises
`
`encrypting the user’s password, and sending the user identification and the
`
`encrypted password to the VPN service provider.
`
`In another feature of the invention, the method further comprises a
`
`step of sending a set-up message to the data network.
`
`In another feature of the invention, the method further comprises a
`
`step of the VPN service provider decrypting the encrypted password.
`
`A technical advantage achieved with the invention is that it shifts or
`
`defers costs from an end user to a bulk purchaser of data network services.
`
`Another technical advantage achieved with the invention is that it permits
`
`end users mobility while attaining a virtual appearance on a corporate
`
`intranet.
`
`Brief Description of the Drawings
`
`Fig. 1 is a system block diagram of a VPN service provider of the
`
`present invention.
`
`Fig. 2 is a flow chart depicting the method of the present invention, as
`
`implemented by application software on a user terminal.
`
`Fig. 3 is the initial screen display of the user interface of the
`
`application software.
`
`Figs. 4A and 4B are call flow diagrams, illustrating the preferred
`
`sequence of steps of the method of the present invention.
`
`Figs. 5A, 5B, 5C, 5D, 5E, and 5F comprise a flow chart depicting the
`
`method of the present invention, as implemented by switching control point
`
`software.
`
`303
`
`

`
`W0 98/27783
`
`PCT/IB97/01563
`
`Description of the Preferred Embodiment
`
`In Fig. 1, the VPN service provider system of the present invention is
`
`designated generally by a reference numeral 10. The VPN service provider
`
`system 10 includes a VPN 12. The VPN 12 may be a corporate, government,
`
`association, or other organizatioifs telephone/data line ‘network. The VPN
`
`service provider system 10 also includes access lines 13 from the VPN 12 to a
`
`data network 14, such as the Internet, or an ATM network. The VPN service
`
`provider system 10 also includes access lines 16 from the data network 14 to a
`
`long distance phone company 1§, such as AT&T, MCI, or Sprint. The VPN
`service provider system 10 also ‘includes access lines 20 from the data network
`14 to a called party 22, such as, for example, American Express reservations
`
`service. The VPN service provider system 10 also includes access lines 24
`
`from the data network 14 to a remote user terminal 26, such as a portable
`
`computer in a hotel room. The user terminal 26 includes user application
`
`software 28, which provides the interface for the user to enter the number to
`
`be called, the user identification number, and the users authorization code.
`
`The VPN service provider system 10 also includes VPN service provider
`
`software 30, located in a switching control point (SCP) device 32, Which, in the
`
`preferred embodiment may be physically located anywhere. The SCP 32
`
`connects to the data network 14 via access lines 36. One possible physical
`
`location for the SCP 32 is on the premises of a local phone company central
`
`switch building 34. However, even when located within the building 34, the
`
`SCP 32 connects to the local phone company switches via the data network
`
`14. The local phone company switches connect to the data network 14 via
`
`access lines 38.
`
`In an alternate embodiment, the VPN service provider software 30 and
`
`the SCP device 32 may be located on the premises of an independent provider
`
`of local phone service, or on the premises of an independent VPN service
`
`provider.
`
`304
`
`

`
`WO 98/27783
`
`PCT/[B97/01563
`
`Referring now to Fig. 2, the application software 28 begins the data
`
`transfer process in step 50.
`
`In step 52, the user is presented with a screen
`
`display.
`
`Referring now to Fig. 3, a screen display 100 displays the following
`
`information requests: whether the call is a direct call 102 or a VPN call 104,
`
`the number the user desires to call 106, the VPN user ID 108, and the user
`
`password 110. The user is also presented with the option to make the call
`
`112, or to quit 114.
`
`Referring back to Fig. 2, in step 54 the user terminal sends to the SCP
`
`32 the information captm'ed through the graphical user interface (“GUI”) in
`
`step 52 within a user network interface (“UNI”) setup message. In step 56 the
`
`user terminal 26 waits for a connect message from the SCP 32.
`
`In step 58 the
`
`user terminal 26 determines if a connection was made.
`
`If no connection was
`
`made, then in step 60 the user application software 28 displays an error
`
`message to the user, and returns to step 50 to begin again the data transfer
`
`process.
`
`If a connection was made, then in step 62 the user terminal 26 sends
`
`the VPN user ID to the SCP 82.
`
`In step 64 the user terminal 26 waits for an
`
`encryption key from the SC}? 32.
`
`In step 66, havincr received the encryption
`
`key from the SCP 32, the user application software 28 encrypts the user’s
`
`password, and sends it to the SCP 32. In step 68 the user terminal 26 waits
`
`for authentication of the user. In step 70 the user application software 28
`
`determines if the SCP 32 authorizes the user to make the call.
`
`If the user is not authorized, then in step 72 the user terminal 26
`
`displays an error message, terminates the connection, blanks the screen
`
`display 100, and returns to step 50 to begin again the data transfer process.
`
`If the user is authorized, then in step 74 the VPN service provider software 30
`
`sets up the billing, and authorizes it.
`
`In step 76 the user terminal 26 sends a
`
`“release”, meaning to terminate or disconnect the connection, to the SCP 32.
`
`In step 78 the user terminal 26 sends a setup message to the number listed by
`
`-4-
`
`305
`
`

`
`WO 98/27783
`
`PCT/IB97/01563
`
`the user as the “number to call”, that is, to the final destination. In step 80
`
`the user terminal 26 waits for a connection.
`
`In step 82.the user terminal 26
`
`determines if a connection was made.
`
`If a connection to the final destination was not made, then the user
`
`application software 28 returns to step 72, in which step the user terminal 26
`
`displays an error message, terminates the connection, blanks the