HIP-Based NAT Traversal in
P2P-Environments
Ari Keränen
NomadicLab, Ericsson Research
Supervisor: prof. Jörg Ott
Outline
• Background
– Network Address Translation (NAT)
– NAT Traversal
– Host Identity Protocol (HIP)
• NAT Traversal Using HIP
– implementation of a NAT traversal library
• Measurement results
• Findings & Conclusions
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
src: 10.0.0.1
dst: 130.233.240.9
src: 198.76.28.1
dst: 130.233.240.9
NAT
NAT’s public address:198.76.28.1
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
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
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
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
Host Identity Protocol
• A new namespace and a
layer between transport
and IP layers
Process
Transport layer
<HI, port> pairs
Host identity layer
Host identifiers
– 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
Internetworking layer
IP addresses
Link (network) layer
Link layer addresses
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
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
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
Measurement Scenarios
• Two hosts behind
different NATs
STUN/TURN server
– NAT types can be
changed (filtering
behavior + Linux NAT)
• STUN/TURN server in
the public network
• ICE connectivity
checks run between
the two hosts
Network
NAT
NAT
PC
PC
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
Measurement Results
Average amount of messages sent during ICE connectivity checks
20
15
EI:
AD:
PD:
L:
Endpoint-Independent
Address-Dependent
Address and Port-Dependent
Linux
Initiator
Responder
10
5
NAT scenario
L
L-L
PD D
-P
PD
D
-A
PD
I
-E
PD
I
-L
AD D
-P
AD
D
-A
AD
-E
AD
D
I
-L
EI
D
-P
EI
-A
EI
-E
EI
0
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
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
That’s all folks!
Questions?