WO2007053029A1

WO2007053029A1 - A system and method for establishing a connection between a client in a first network and a web service server in another network

Info

Publication number: WO2007053029A1
Application number: PCT/NO2006/000381
Authority: WO
Inventors: Thanh Van Do; Thuan Van Do; Ivar JØRSTAD
Original assignee: Telenor Asa
Priority date: 2005-10-31
Filing date: 2006-10-30
Publication date: 2007-05-10
Also published as: NO20055084D0; NO20055084L

Abstract

A system and method for a system for establishing communication between a client in a first network and a web service server in a second network, each network being protected by a Network Address Translator and a firewall . The solution includes a client proxy in the first network, a server proxy in the second network, and a Rendezvous server external to both the first and second networks. The client is adapted to establish a connection to the web service server through the Rendezvous server, that subsequently relay a global accessible IP address and port number of the client to the web service server and a global accessible IP address and port number of the web service server to the client, whereupon the client and web service server establish a direct connection there between using said addresses .

Description

A SYSTEM AND METHOD FOR ESTABLISHING A CONNECTION BETWEEN A CLIENT IN A FIRST NETWORK AND A WEB SERVICE SERVER IN ANOTHER NETWORK

Field of the invention

The present invention relates to communication in TCP/IP networks, and in particular to accessing network servers located behind Network Address Translation (NAT) routers and firewalls.

Technical background

The problem area of NAT and firewall traversal is a classical one, and is relevant to most services running on most service platform in the Internet. However, this invention provides a specific solution to this problem for XML Web Services.

Fig. 1 illustrates the problem. Client software on a device on one Local Area Network (LAN) wishes to initiate communication with server software on a device (computer) on another LAN. Although the client-server paradigm is referred to here, the problem is equally relevant to the peer-to-peer paradigm of distributed systems.

Network A is behind a combined NAT router and firewall (henceforth referred to as Middlebox A) which has assigned to it a global IP address 193.212.1.11 on its external network interface. Since Middlebox A is also part of the LAN, it has been assigned the local address 192.168.1.1 on its internal network interface, which is the gateway address for all hosts on the LAN to access the Internet. All hosts on the LAN (Network A) have been assigned IP addresses in the range 192.168.1.2-254 (one of the ranges reserved for LANs) .

Network B is behind another NAT router and firewall (henceforth referred to as Middlebox B) which has assigned to it a global IP address of 80.203.108.251. It has been assigned the local address 10.0.0.1 on its internal network interface, and all other hosts on the LAN (Network B) have been assigned IP addresses in the range 10.0.0.2-254

(another range reserved for LAN usage) .

Assume that a Web Service client (WS_C) on the device in Network A wants to connect to a Web Service server (WS₃) on the computer in Network B. A TCP connection request must then be sent to the only externally known address in

Network B, which is 80.203.108.251. Web Services usually operate over HTTP on port 80, so the request (a TCP SYN packet] ) will be sent to the endpoint address designated by the tuple <80.203.108.251 : 80>. The following steps describe the process and the possible outcomes:

1. A TCP SYN packet (TCP connection request) is received by Middlebox B, and it appears to be originating from Middlebox A.

2. A firewall usually blocks all incoming packets that are not related to existing connections initiated from the network behind the firewall. The incoming TCP connection request does not belong to an existing ongoing connection/session. It is also not associated with any other packet going out of Middlebox B. It is thus dropped by the firewall, and the client will fail to connect to the server.

3. Assume that the firewall is configured to allow incoming, unrelated packets to pass. The NAT router should now redirect the packet to the correct host on Network B (10.0.0.2). But since this packet is sent to either a random TCP port, or on a port chosen exclusively by the originating host in Network A (in our case the standard HTTP port 80 is used) , the NAT router does not know where to forward the packet. There could be a vast number of hosts connected to Network B, but the correct Web Service server is only running on one of these.

4. On networks with servers that should be globally accessible using local IP addresses, 3) above is solved by manually specifying rules in the NAT router (e.g., all incoming traffic on port 80 on Middlebox B should be routed to the WWW server, which has IP address 10.0.0.2) .

5. However, it is desirable that only traffic originating from the owner of Network B is passed through the NAT router/firewall and to the destination host (e.g. to prevent hacker attempts) . A static rule as described in 4) above would forward all TCP traffic to the specific port, originating from any host to the host with IP address 10.0.0.2.

6. It is usually possible to allow traffic from a particular sub-net or specific host to pass through the firewall, but then again, the host in Network A might be changing IP address every now and then (if no behind a NAT router) or Middlebox A may be changing IP address now and then. This is particularly true when the user is nomadic and roams from network to network (e.g. cellular networks and WLAN networks).

5 Known solutions

Manual configuration

Today, the most commonly employed solution to solving the specified problem is to manually configure the firewall and NAT router (Middlebox B in Figure 1) to allow incoming o connections not related to an ongoing session, and to manually specify rules on how to route this traffic to hosts on the LAN. A NAT router can be configured to route all TCP traffic with destination port 25 to the SMTP server on the LAN, whereas all TCP traffic with destination port 80 is routed to the HTTP server.

Manual configuration is too cumbersome for the ordinary, novice user. Manual configuration can thus be adequate in enterprise networks and similar, but if services should reside in e.g. the home network, other, more user friendly, solutions are required. To summarise:

- Not user-friendly; requires technically skilled people to perform such configuration

- Manual configuration does not cope with nomadic users that roam between different networks

- Not integrated with service platforms; need configuration for each service platform

Universal Plug and Play (UPnP)

Another solution is proposed by the Universal Plug and Play (UPnP) standard [1] . This is a protocol that allows network devices to specify requirements and to automatically configure each other. One example could be a server application telling the NAT router to route incoming traffic on port 80 to a specific host on the LAN. The advantage of this protocol is that it allows very flexible solutions, e.g., a NAT router can temporarily route specific traffic to a specified host, and at one point in time be ordered to discontinue this behaviour.

This solution is illustrated in Fig. 2. However, this solution has some shortcomings : Malicious code could be installed on a computer in the home network and communicate with UPnP enabled equipment like a NAT router. Thus, it could potentially allow external users to hijack the home network. To summarise:

- Security is of major concern with this solution - Requires equipment that supports UPnP

ICT technicians generally advice against enabling UPnP functionality in devices that support the protocol, due to the possibility of serious security breaches.

Globally Accessible relay Proxy

It is possible to configure a NAT router/firewall to accept incoming traffic from a specific host (i.e., well-known IP address). With such a setup (Figure 2), only one static rule is required in Middlebox B ("forward incoming traffic from host a.b.c.d to host w.x.y.z) . Also, if the host in Network A has a globally accessible IP address (thus not behind a NAT router) , triangle routing could be used, as illustrated in Figure 3.

Of biggest concerns when using the relay proxy solution, is that the proxy itself must have a lot of resources available. This is due to all the potential traffic going through this proxy, increasing as the number of users is increasing. Generally, this is not a scaleable solution. Both the requirements to CPU power and the requirements to available bandwidth increase proportionally to the number of users. In addition, the proxy must have additional responsibilities compared to a simple switch, because it must be able to authenticate users and locate the appropriate network where to traffic should be forwarded. To summarise:

- Requires a third component in a globally accessible location; someone must be responsible for and perform maintenance of this component

- The proxy must have lots of resources to cope with many users; scalability issues

- There will be an observable increase in network and processing latency, due to the traffic not going directly between the client and server hosts Summary of the invention

It is an object of the present invention to provide a solution to the problems discussed above.

The inventive solution is covered by the appended claims .

In particular, to overcome the problems described in the previous sections, a new architecture for XML Web Services has been devised. The solution allows the establishment of a direct TCP connection between a device hosting an XML Web Service client and a device hosting an XML Web Service server, and allows easy integration with existing service platforms and services. By employing this architecture, any service running on an XML Web Service platform can be made ubiquitously available from remote locations.

Benefits of the proposed solution:

- Does not require special hardware

- Does not require technical skills of the users

- Does not increase network latency

- Has a layered and flexible security model

- Is easy to integrate with existing XML Web Services platforms and services, in order to increase their availability and ubiquity

The proposed solution requires a third component in a globally accessible location, but this component does not require a lot of resources since it is only used during the connection setup phase, and not during service invocations.

Brief description of the drawings .

The invention will be described in detail in reference to the appended drawings, in which:

Fig. 1 shows one device on a LAN trying to connect to a server in another LAN, i.e. illustrating the problem which the present invention tries to solve,

Fig. 2 shows a prior art solution using a globally- accessible relay proxy to allow traffic flow between two networks behind a NAT/firewall,

Fig. 3 shows another prior art solution using a globally- accessible relay proxy and triangle routing,

Fig. 4 shows the overall architecture used in the present invention,

Fig. 5 shows a sequence diagram of the connection setup process and the first Web service invocation of the inventive solution.

Detailed description

Overall architecture

Figure 4 displays the overall architecture of this invention. The goal of the invention is to enable the direct SOAP message exchange between an arbitrary Web Service server component (WS Server) residing on a server in one network and a corresponding Web Service client (WS Client) located on a remote device that can be a stationary computer, a Personal Digital Assistant or a mobile phone. Such a message exchange is not possible because the server and the remote device are residing in different domains separated by firewalls and Network Address Translation.

Components

The solution proposes the introduction of 3 components : TravLibServer, TravLibClientProxy and TravLibServerProxy .

Rendezvous Server (TravLibServer)

This is the server that eventually enables the message exchange between the Web Service client and the Web Service server. The rendezvous functionality is realised by the TravLibserver. The TravLibServer allows the client and server to obtain each others endpoints (where an endpoint is the combination of an IP address and a port number) , and thereby to initiate a direct communication channel between the client device and the server device.

This component has the following interfaces:

Interface I_b

This is the interface on the Rendezvous Server used by the Client Proxy. It is used in the initiation phase of the communication channel between the client and the server.

The messages sent over this interface are:

enquire (service__jprovzder_id_/ cllent_endpoint[]) - This message (msg #2 in Figure 5) is used to retrieve the current endpoint address of the specified service provider (identified by service_provider_id) . The parameter service_provider_id could also contain a specification of the requested service, instead a specific service provider id. This would allow even more dynamic service discovery. The response to this message is an enquireResponse:

enqτiireResponse(service_provider_endpoint[])- This response (msg #3 in Figure 5) contains the current endpoint address (es) of the enquired service provider/service.

Interface I_c

This is the interface on the Rendezvous Server used by the Server Proxy. This interface is used for Server location update. The Server Proxy updates its location (endpoint address) to the Rendezvous Server over this interface, periodically and upon changes in endpoint address.

The message sent over this interface is:

updateEndpoin t ( service_provider_id , service__provider_endpoint [ ] ) - This message (msg #0 in Figure 5) updates the current endpoint address (es) of the specified service provider (identified by service_provider_id) . The message could also contain a list of services provided by this service provider, in order to support the dynamic service discovery mechanism mentioned in the description of the enquire () message of interface Ib-

TravIiibClientProxy

This component resides on the remote device together with the Web Service client.

This component has the following interface:

Interface I_a

This is the interface between the Web Service client and the Client Proxy (TravLibClientProxy) . Since all standard Web Services should be supported, this interface is identical to the original interface between the Web Service client and the Web Service server. This interface is equal to interface I_3', which is the interface of the Web Service server.

The messages sent over this interface are:

WSReqaest(abc) - The original Web Service request (abc) is sent locally to the TravLibClientProxy component (msg #1 in Figure 5) .

WSResponse (abc) - This (msg #11 in Figure 5) is the response to the original Web Service request (msg #1) .

TravLibServerProxy

This component resides on the server device which hosts the Web Service server. The Web Service server can be any type of server. No additional configuration is necessary for it to work in the proposed architecture. The

TravLibServerProxy contributes to the initiation of the communication channel (by using a NAT/firewall traversal protocol towards the TravLibServer) and forwards all received Web Services requests to the local Web Service container (these messages are relayed exactly as received without changes to the content) . It also forwards Web

Services responses from the Web Service container to the TravLib client proxy through the dedicated TCP connection (also relaying without changing the content of the messages) .

This component has the following interfaces:

Interface I_C'

This is the interface on the Server Proxy used by the Rendezvous Server. This interface is used for Connection intent notification. The Rendezvous Server notifies the Server Proxy when a client wants to initiate a connection towards the server.

The message sent over this interface is:

notifyCl±entIntβnt(client_endpo±nt[]) - This message (msg #4 in Figure 5) notifies a Server Proxy that a Client Proxy wants to connect. The endpoint(s) of the client are specified by the parameter client_endpoint [] .

There is also an interface common to the Client Proxy and the Server Proxy:

Interface I_d

This is the interface between the Client Proxy and the

Server Proxy, and it constitutes a symmetric TCP connection where Web Service requests, i.e. WSRequest (abc) , and responses, i.e. WSResponse ( ) , are tunneled. The mechanisms that enables this direct connection setup is described in [2] , and briefly explained it depends on both parties initiating a TCP-connect (by sending a TCP SYN packet) towards the other party, at the same time. The messages sent over this interface are:

TCP. connect () - These messages represent a standard TCP connection setup sequence, and consists of a three-way handshake mechanism according to the TCP state diagram defined in [3] .

TCP. write (WSRequest (abc) ) - This message (msg #7) tunnels the original Web Service request (WSRequest (abc) ) from the Client Proxy to the Server Proxy through the established TCP connection between these components.

TCP. write (WSResponse (abc) ) - This message (msg #10) tunnels the Web Service response (WSResponse ()) from the Server Proxy and the Client Proxy through the established TCP connection between these components.

In addition, but not required, there could be a mutual authentication phase prior to Web Service messages being tunneled over this interface (msg #6 in Figure 5) .

Methods and Message Exchanges in the Interfaces

A sequence diagram of the entire process of initiating a connection and exchanging a set of Web Service request and response messages is shown in Fig. 5. The interfaces described in the previous section are depicted above the first message to travel over each interface.

The Web Service client is a regular XML Web Service client of any arbitrary XML Web Service. The Web Service client must use a specialized library (henceforth referred to as the TravLib client library) that implements the NAT/firewall traversal protocol. This library also implements a proxy, which receives all Web Services requests locally, initiates communication with the server and forwards all Web Services requests to the server side proxy. Upon reception of corresponding Web Services responses, these are forwarded by the server proxy to the client proxy. Integration Example with Existing Web Service Client

The following code excerpt is required and sufficient to adapt and integrate a standard JSR-172 [2] compliant XML Web Service client for a J2ME enabled device into the system proposed in this invention:

TravLibClientProxy proxy = new TravLibClientProxy(PORT, TRAVLIBSERVER, USERNAME, PASSWORD, stub);

proxy.startO;

The TravLibClientProxy class instantiated in the example code implements the proxy running on the client. The parameters are:

PORT - The port on which the client proxy should listen for incoming Web Services requests on (requests from the Web Service client) .

TRAVLIBSERVER - The fully qualified host name or IP address of the TravLib Server.

USERNAME - Username for authentication purposes.

PASSWORD - Password for authentication purposes.

stub - The original JSR-172 compliant SOAP stub instance. This is required, in order to change the stubs

ENDPOINT_ADDRESS_PROPERTY to point to localhost (i.e., so that the client proxy receives the original Web Services requests) . This change of address is done by the TravLib client library.

Integration Example with Existing Web Service Server

To integrate this architecture with an existing Web Service server, it is sufficient to install the TravLibServerProxy on the device hosting the Web Service server. References

[1] Iyer, P. and Warrier, U. (2001) . "Internet Gateway Device :1 Device Template Version 1.01 For Universal Plug and Play Version 1.0", Microsoft Corporation, November 12, 2001

[2] Ford, B., Srisuresh, P. and Kegel, D. (2005). "Peer-to- peer communication across network address translators". In Proceedings of the 2005 USENIX Annual Technical Conference (Anaheim, CA) , April 2005

[3] Postel, J. (ed) . (1981) . "Transmission Control Protocol - DARPA Internet Program - Protocol Specification". IETF, available online: http://www.ietf . org/rfc/rfcO793. txt?number=793

[4] Sun Microsystems, Inc. (2003). "JSR-172: J2ME Web

Services 1.0. Final Draft". Java Community Process (JCP). Available online: http: //www. jcp. org/en/j sr/detail?id=172

Claims

C l a i m s

1. A system for establishing communication between a client in a first network and a web service server in a second network, characteri zed in that said system includes: a client proxy in the first network, a server proxy in the second network, a Rendezvous server external to both the first and second networks, the client being adapted to establish a connection to the

Rendezvous server, through the client proxy, the Rendezvous server being adapted to establish a connection to the web service server through the server proxy, the Rendezvous server further being adapted to relay a global accessible IP address and port number of the client to the web service server and relay a global accessible IP address and port number of the web service server to the client, the client and web service server being adapted to establish a direct connection there between using said addresses .

2. A system as claimed in claim 1, characterized in that the web service server being an XML web service server.

3. A Rendezvous server for use a system as claimed in claim 1, for establishing a connection between a client in a first network and a web service server in a second network, characterized in the Rendezvous server being external to both the first and second networks, the Rendezvous server being adapted to establish connections to the client and web service server, through local proxies in said networks, and exchange end-point addresses of said networks between the client and web service server.

4. A Rendezvous server as claimed in claim 4, said server including a client proxy interface (I_b) towards the client proxy, said interface (I_b) being adapted to receive a message from the client proxy requesting the global accessible IP address of the web service server, said message including the identity of said web service server or a specification of the requested service, the Rendezvous server being adapted to respond with a message including o the global accessible IP address of the web service server, and a server proxy interface (I_c) towards the server proxy, the server proxy interface (I_c) being adapted to receive messages from the server proxy with the current global accessible IP address (es) of the web service server and/or s a list of services provided by the web service server and their addresses.

5. A server proxy for use in a system as claimed in claim 1, characterized in the server proxy including a o first Rendezvous server interface (I_C') adapted to receive messages from the Rendezvous server notifying the server proxy when a client wants to initiate a connection towards the web service server, a server direct addressable interface (I_d) towards the 5 client proxy, said server direct addressable interface being a symmetric TCP connection where web service requests and responses are tunnelled, and a web server interface (I_a0 towards the web service server, said web server interface being adapted to send web 0 service requests to the web service server and receive responses from the web service server.

6. A client proxy for use in a system as claimed in claim 1, characterized in the client proxy including a 5 client interface (I_a) towards the client, said interface being adapted to receive web service requests from the client and send responses back to the client, a second Rendezvous server interface (I_b) for sending web service requests to the Rendezvous server, and a client direct addressable interface (I_dO towards the server proxy, said client direct addressable interface being a symmetric TCP connection where web service requests and responses are tunnelled.

7. A method for establishing communication between a client in a first network and a web service server in a second network, the first network including a client proxy, the second network including a server proxy, characterized in that the method includes the following steps : the client sending a web service request to the client proxy, the client proxy enquiring the network address of the web service server from a Rendezvous server external to both the first and second network, and providing its own end- point address to the Rendezvous server, the Rendezvous server providing the client with the end- point address of the web service server, the Rendezvous server providing the server proxy with the end-point address of the client, the client and the server connecting to each other using the provided network addresses, the client proxy sending the web service request to the server proxy, the server proxy sending the web service request to the web service server.

8. A method as claimed in claim 4, characterized in that subsequent traffic between the client and the web service server passing through the client proxy and web service server.