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

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

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.1 dst: 130.233.240.9 src: 198.76.28.1 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

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

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 EI: Endpoint-Independent AD: Address-Dependent PD: Address and Port-Dependent L: 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?