HIP-Based NAT Traversal in P2P-Environments

Ari KeränenNomadicLab, 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

NAT

src: 10.0.0.1dst: 130.233.240.9

src: 198.76.28.1dst: 130.233.240.9

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– 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

Transport layer

Host identity layer

Internetworking layer

Link (network) layer

Process

<HI, port> pairs

Host identifiers

IP addresses

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– 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

PC

NAT

NAT

STUN/TURN server

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

0

5

10

15

20

Mes

sage

cou

nt

NAT scenario

Average amount of messages sent during ICE connectivity checks

InitiatorResponderEI: Endpoint-Independent

AD: Address-DependentPD: Address and Port-DependentL: Linux

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?