P2P NAT and firewall traversal investigations


Introduction paper: NAT Traversal Techniques and Peer-to-Peer Applications from Zhou Hu

Some excerpts:

The main reason of NAT’s birth is the short-term solution of IPv4 address depletion. In Client-Server network, NATed environment is not a big problem for private addressed clients since they almost always get service by initiating connections with dedicated servers on public addressed Internet.
Peer-to-Peer network is different with Client-Server network.In Peer-to-Peer network peers have equal positions without classification of client and server and peers are directly connected by other peers. They act both as client and server simultaneously. In NATed environment, general firewall/NAT role does not allow incoming connection to private addressed hosts unless private hosts initiate the connection at first or NAT is specifically configured. The built-in privacy and security benefits of NAT are private addressed hosts hiding. On the other hand, this is a trouble because it is hard to locate and communicate with the private hosts behind a NAT gateway. How two private addressed hosts behind NATs could get to know each other in the very beginning of the Peer-to-Peer communication?


Diverse NAT Traversal Techniques offer a variety of NAT devices with transparent traversal abilities to keep the end-to-end connection virtually. Some of them are NAT gateway optimized and plugged techniques such as Universal Plug and Play (UPnP), Application Lever Gateway (ALG). Some of them are fall-back (make use of Client-Server model) approaches, by which they use a relay server or introducer server on either side of NAT gateway or both sides, such as STUN and TCP/UDP hole punching. TU hole punching is the most robust and practical NAT traversal technique. It makes use of a rendezvous server as an introducer for clients behind NAT to get know each other’s host endpoints (IP address and TU port).

Common techniques:

  • Universal Plug and Play (UPnP)
  • Simple Traversal UDP Through Network Address Translators (STUN), STUNT
  • Application Level Gateway (ALG)
  • UDP/TCP hole punching

Simple Traversal UDP Through Network Address Translators (STUN)

The advantage of STUN is it does not require any changes on NAT devices. Clients could learn NAT devices automatically. On the other side, STUN is just a short term solution. It does not work with symmetric NAT which is commonly used by large corporate users. IETF proposes TURN to solve this problem. STUN requires client application upgraded to support STUN and an additional STUN server residing in public Internet. Those reasons make STUN deployment slow and unpopular.

Application Level Gateway (ALG)

Application Level Gateway always resides in NAT/Firewall devices to modify payload transparently thus work together with NAT to offer transparent routing for packets.
ALG commonly requires replacement or modification of NAT/Firewall device and configuration. This restricts the deployment of ALG technology

UDP and TCP hole punching

UDP and TCP hold punching is general purpose, robust technique to establish peer-to-peer communication in Peer-to-Peer network. This technique does not require the application to know the topology of network and presence of NAT devices. It does not modify NAT/Firewall configuration. The main idea of hole-punching is to have a relaying server which could be reached by clients both or either behind NAT.


Relaying always works
as long as both clients can connect to the server.
Its disadvantages are that
it consumes the server’s processing power and network bandwidth,
and communication latency between the peering clients
is likely increased even if the server is well-connected.
since there is no more efficient technique
that works reliably on all existing NATs,
relaying is a useful fall-back strategy
if maximum robustness is desired.
The TURN protocol
defines a method of implementing relaying
in a relatively secure fashion.

Existing framework

There is several projects aiming at solving the NAT traversal issue:

  • NATTrav: no Java source code available, TCP only, hole punching
  • STUNT: most reliable hole-punching solution (reliablility > 85%), hole punching
  • JXTA: too complex just for NAT problem, TCP only, relay
  • Skype: has almost solved the problem, but no source code is available, hole punching + relay


Some interesting links:

Attacking disk encryption

Ed Felten and his colleagues showed that disk encryption, the standard approach to protecting
sensitive data on laptops, can be defeated by relatively simple methods. Their attack was demonstrated on popular disk encryption programs like BitLocker (comes with Windows Vista), FileVault (comes with MacOS X) or dm-crypt (used under Linux).

Some excerpts:

The root of the problem lies in an unexpected property of today’s
DRAM memories … Virtually everybody, including experts, will tell you
that DRAM contents are lost when you turn off the power. But this isn’t

Our research shows that data in DRAM actually fades out
gradually over a period of seconds to minutes, enabling an attacker to
read the full contents of memory by cutting power and then rebooting
into a malicious operating system … If you cool the DRAM chips, for
example by spraying inverted cans of “canned air” dusting spray on
them, the chips will retain their contents for much longer.

is deadly for disk encryption products because they rely on keeping
master decryption keys in DRAM. This was thought to be safe because the
operating system would keep any malicious programs from accessing the
keys in memory, and there was no way to get rid of the operating system
without cutting power to the machine, which “everybody knew” would
cause the keys to be erased.

Our results show that an attacker
can cut power to the computer, then power it back up and boot a
malicious operating system (from, say, a thumb drive) that copies the
contents of memory … search through the captured memory contents,
find any crypto keys that might be there, and use them to start
decrypting hard disk contents.

There seems to be no easy fix for
these problems. Fundamentally, disk encryption programs now have
nowhere safe to store their keys.

More details here and here

In a related post, he also explains how to attack laptops when they are in sleep mode.