Ralph Niederberger, Research Center Jülich, Egon Grünter, Research Center Jülich

Dynamic Firewall 4: Grid UDP Hole Punching

NAT traversal through UDP hole punching is a method for establishing bidirectional UDP communications between Internet hosts in private networks using NAT. It takes advantage of firewalls that simulate connections for UDP traffic.

As a prerequisite to use UDP hole punching the local firewall has to allow outbound TCP and UDP connections, it has to simulate connections for UDP data transfers and a relaying server has to be installed.

The relaying server is a central part of this concept. Each client connects to the relaying server using a persistent TCP connection. Simultaneously the relaying server recognizes the public IP addresses of the clients.

The connection is established in several steps. The initiator (client A) sends a TCP segment to the relaying server C containing the information that the client A wants to talk to client B using a UDP port, e.g. 4711. The server notifies client B that client A has the public IP address x.x.x.x and that it expects a UDP connection on port 4711. Client B sends the preferred UDP port, e.g. 8822 to the relaying server and simultaneously it sends a UDP datagram from source port 8822 to destination port 4711 to client A.

Client B’s local firewall forwards the UDP datagram, stores a connection entry and the dynamic access rule which allows responses to traverse the firewall into its internal data base. In this phase Client A’s local firewall rejects the packet but this does not matter at all. The relaying server C informs client A via the existing TCP connection between A and C that client B is accessible on IP address y.y.y.y and UDP port 8822.

Client A now sends a UDP datagram from source port 4711 to 8822. Client A’s local firewall now creates the dynamic entry. However, the dynamic entry in B’s local firewall is still active and valid, so that the UDP datagram from A to B passes the firewall. Now the communication channel is established although the static ruleset of each firewall would normally deny inbound connections according to the parameters of the protocol headers.

The concept of UDP hole punching can easily be extended to be used in Grid environments Gup06. The relaying server is changed to a relaying service which is located inside client B’s domain. It listens on a well defined TCP port and waits for user connections. At connect time, the remote user and the server that hosts the relaying service may authenticate each other using X.509 certificates. If the TCP connection between the participants has been established UDP data transfers can take place as described in the UDP hole punching concept above.

The advantage of a relaying service is obvious. The relay server C and client B could be the same host without using an outside relaying server which is not administrated by one of the involved organizations. Mutual authentication between client and server is necessary only once at connect time. Once the TCP connection is established the data transfers are allowed to start. Even more there are no problems resulting from NAT. Any server accessible from the public network is exempted from the NAT algorithm and the server only sees the public IP address of the client.

Often it is useful to transfer data using multiple parallel connections. The client has to indicate how many connections should be used in parallel. It allocates the sockets and sends the port numbers to the server. The server reads the information and tries to initiate the maximum number of UDP connections available by sending small UDP datagrams to the client. This may depend on the system load. The server sends the local UDP port numbers to the client and the client starts the data transfers.

A new challenge arises from encrypted UDP data traffic. One approach to encrypt the data could be a simple symmetric algorithm. Because the TCP connection between client and server is secured via X.509 certificates the exchange of a shared secret could be done via this channel.

The second challenge results from specific requirements of Grid applications. Data transfers should be fast and reliable. Because UDP has no three-way-handshake and no acknowledgement it is faster than TCP, but UDP is not reliable. Each UDP datagram is an instance of its own and the application has to make sure that all the data has arrived. In fact this means that Grid applications have to be changed. They have to use UDP and need an instance to implement reliability.

This can be accomplished by the UDP-based Data Transfer Protocol (UDT) Udt06.

UDT is available as open source and distributed under the LGPL. It is designed and implemented by the National Center for Data Mining at the University of Illinois at Chicago. A first internet draft has been released in August 2004. The latest stable release including documentation can be downloaded from Sourceforge.

UDT uses UDP as transport protocol but it guarantees reliability through an upper layer. Of course Grid applications have to be modified also, but the effort is very small because an API using UDT can be provided. Only interfaces of subroutines allocating sockets have to be changed.

UDT is available as open source and distributed under the LGPL. It is designed and implemented by the National Center for Data Mining at the University of Illinois at Chicago. A first internet draft has been released in August 2004. The latest stable release including documentation can be downloaded from Sourceforge Udt06.

The general concept of Grid UDP hole punching can be described as follows:

The Grid client application at host A connects to the server host B using a predefined port number e.g. 4711 via A’s local firewall and the remote firewall at B’s location (#1). The specified port has to be opened at each firewall for every host which provides this relay service. After mutual authentication using X.509 certificates or any other method used by Grid middleware has been performed successfully, data exchange using dynamic ports can take place.

Client A and Server B exchange securely authentication and authorization information as well as key information for a later secure communication with the required service on this host (any grid application, AGA) (#2).

Figure: UDP hole punching in Grid environments

The relaying service informs the AGA service on host B that host A wants to connect to service AGA via e.g. UDP port 32666 (#3). AGA looks for a free port number e.g. 35678. Then AGA sends a UDP packet to host A at port 32666 and uses as source port 35678 (#4). The packet traverses host B’s firewall because outgoing UDP packets are allowed, but gets rejected at host A’s firewall. Nevertheless, host B’s firewall assumes an UDP stream between A/32666 and B/35678.

After the first UDP datagram has been sent from host B to host A, host B’s AGA now informs host B’s relaying service about the port to be used as destination by A (#5). The relaying service informs host A via the open TCP connection that AGA is waiting for UDP communication at port 35678 (#6).

Now host A connects to service AGA on host B with the agreed UDP port 35678 and uses as source port 32666 (#7). Hosts A and B are now able to use the UDP-based Data Transfer protocol (UDT) via the established communication path (also #7). The firewall has been opened securely and dynamically without any firewall modifications.

The security impact of Grid UDP hole punching depends directly on the secure implementation of the relaying service. If authentication and authorization of remote users/processes has been programmed with standard and up to date security tools, then the dynamic firewall rules can be created because access rights to the service have been assigned by the administrator of the service. The described concept of Grid UDP hole punching can be seen as a further step in providing solutions for Grid applications dealing with existing firewalls. It can be easily used by most of the Grid applications known today to overcome time delays until “real” dynamic configurable firewalls are available on the market.

Guh06 Grünter,E. , Meier,M., Niederberger, R., Petri,F. – Dynamic Configuration of Firewalls Using UDP hole Punching, internal technical report FZJ-ZAM-IB-2006-13, http://www.fz-juelich.de/zam/files/docs/ib/ib-06/ib-2006-13.pdf, Jülich, Germany, August 2006

Udt06 Y. Gu - UDT: UDP-based data transfer library - Version 3, http://www.cs.uic.edu/_ygu1/, May 2006

Attachments:

hole_punch_5.jpg [UDPHolePunching/hole_punch_5.jpg]