Custom SocketFactory for UDT - NAT Traversal

[Peter Firmstone <ji...@zeus.net.au>]

 From the UDT website http://udt.sourceforge.net


          UDT: Breaking the Data Transfer Bottleneck

    UDT is a reliable UDP based application level data transport
    protocol for distributed data intensive applications over wide area
    high-speed networks. UDT uses UDP to transfer bulk data with its own
    reliability control and congestion control mechanisms. The new
    protocol can transfer data at a much higher speed than TCP does. UDT
    is also a highly configurable framework that can accommodate various
    congestion control algorithms.

The main attraction for me, is by using existing UDP channels, it's much 
easier to traverse firewalls.  UDP is a connectionless protocol.   
Additional performance may be obtained by using UDT in preference to TCP 
over wide area networks when NAT traversal isn't required.

NAT is used to share a public IP address among a number of privately 
addressed network computers.

Computer (A) behind a NAT can send data to the internet, the NAT re 
writes packet headers, a remote computer (B) can respond, the response 
packets are returned to computer (A) by the NAT.

If a River installation resides on a box in a private network behind a 
firewall and exports a service, and a proxy for this service is at some 
point obtained by a client residing outside the the private network, 
then that remote client cannot contact the service, unless a port is 
opened on the firewall and redirects packets to the service.

To cut a long story short, a service needs a port opened on a firewall, 
providing a way for external clients to contact it.

This can be done in the following ways:

   1. Configuring the firewall manually.
   2. NAT-PMP (If supported by NAT gateway)
      http://tools.ietf.org/html/draft-cheshire-nat-pmp-03
   3. UPnP IGD (If supported by NAT gateway)
   4. STUN http://tools.ietf.org/html/rfc5389

The limitation with NAT-PMP and UPnP is, they must be supported and 
enabled on a router but cannot be used for multi layer router network 
topographies.

The STUN protocol allows a network node residing behind a firewall to 
discover it's public port on a firewall and to keep it open by 
connecting to a public STUN server.  Publicly accessible STUN servers 
are available on the internet.  STUN doesn't succeed in all cases. 

Publicly accessible TURN servers, available on the internet, provide a 
method of relaying packets when STUN doesn't work.

Work on NAT Traversal is more mature and less complex for UDP than TCP, 
see http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-14#appendix-A

It should be recognised that any connection obtained using these methods 
is not secure, STUN could misinform a client of it's public address to 
perform a substitution attack, a TURN server could perform a man in the 
middle attack.  These network connections should only be used with 
secure Endpoints, utilising cryptographic authentication.

A ServerSocketFactory could be designed to perform the necessary steps 
to open a firewall port, discover public address, port and keep the 
connection open.

Cheers,

Peter.