1. HIP-Based NAT Traversal in P2P-Environments
Ari Keränen NomadicLab, Ericsson Research
Supervisor: prof. Jörg Ott

2. Outline Background NAT Traversal Using HIP Measurement results
Network Address Translation (NAT)
NAT Traversal
Host Identity Protocol (HIP)
NAT Traversal Using HIP
implementation of a NAT traversal library
Measurement results
Findings & Conclusions

3. Network Address Translation
NAT can transparently change a network internal, private address to a public address
a new mapping is dynamically created when the first packet for a connection passes the NAT
return traffic can use the same mapping to the other direction
allows normally only outbound connections
often use TCP/UDP ports for multiplexing
NAT
src:
dst:
src:
NAT’s public address:

4. NAT Types
Mapping and filtering behavior varies between NAT implementations
Mapping
if the destination address and/or port changes, will the source public address at the NAT change
Filtering
which source addresses and/or ports on the external side of NAT are allowed to use the mapping

5. NAT Types Endpoint independent filtering
any host using any port in the external side can use the mapping the NAT has created
Address (and port) dependent filtering
only packets from the same destination address (and port) that created the mapping are accepted
Endpoint independent mapping
NAT uses the same mapping (i.e., public address and port) for packets even if the destination address or port changes
Address (and port) dependent mapping
NAT mapping is changed if the destination address (or port) is changed

6. NAT Traversal A way to make the responder behind a NAT reachable
Needed especially in P2P environments since a peer is likely behind a NAT
compare to client-server model, where servers are normally in the public, globally routable network
Can be done using hole punching
responder sends a packet to a (STUN) server and learns the NAT mapping from the response
the initiator may be able to use that mapping
depending on the type of the NATs

7. Interactive Connectivity Establishment
A robust NAT traversal solution
Combines hole punching with a set of optimizations and methodology
works also in scenarios where simple hole punching does not work
Both endpoints probe for connectivity using multiple (all) possible address candidates
relayed route as the last resort
controlling hosts decides when to stop tests and which path to use

8. Host Identity Protocol
A new namespace and a layer between transport and IP layers
transport layer connections bound to host identity
Enables natural host mobility and multihoming
IP address changes invisible to upper layers
transport layer connections survive address changes

9. Host Identity Protocol
Connection established using a four-way handshake; the HIP base exchange
proof of identity, IPsec setup, DoS attack protection
Legacy applications can use HIP transparently
presentation of the host identity (Host Identity Tag) looks like a normal IPv6 address
Problems with NATs
HIP is normally run directly on top of IP
simple UDP encapsulation works if the responder is not behind a NAT

10. NAT Traversal Using HIP
Use ICE for traversing the NATs
ICE candidates sent in the HIP base exchange
base exchange through a relay or a P2P overlay network
Single NAT traversal solution for all applications
no need for application specific solutions

11. Implementation Implemented ICE library
3+1 Internet-Drafts
ICE: draft-ietf-mmusic-ice-19
STUN: draft-ietf-behave-rfc3489bis-15
TURN: draft-ietf-behave-turn-07
(draft-rosenberg-mmusic-ice-nonsip-00)
Tested the library using various NAT types
is ICE able to create a path
how much traffic is generated

12. Measurement Scenarios
Two hosts behind different NATs
NAT types can be changed (filtering behavior + Linux NAT)
STUN/TURN server in the public network
ICE connectivity checks run between the two hosts

13. Measurement Results
ICE is able to create a working path in all the scenarios
outperforms simple hole punching
Best path depends on the scenario
Linux-Linux NAT scenario requires a relay
port dependent filtering with Linux NAT needs a relay depending on timing of the checks
all other scenarios work with direct path
some variation in the amount of messages

14. Measurement Results EI: Endpoint-Independent AD: Address-Dependent
PD: Address and Port-Dependent
L: Linux

15. Findings The default timer values for non-RTP ICE are suboptimal
connectivity checks can take multiple seconds even in common NAT scenarios
can be fixed relatively easily
Good local stopping criteria/algorithm is essential for performance of ICE

16. Conclusions ICE is a good solution for HIP P2P NAT traversal
works with all tested scenarios (and likely with many others)
minor changes to basic ICE are useful
The solution increases overhead
but not substantially compared to other options

17. That’s all folks!
Questions?