Making SIP NAT Friendly Jonathan Rosenberg dynamicsoft

Problem Statement Long time until we have ubiquitously deployed –IPv6 –Midcom enabled NAT –ALGs No commercial SIP ALGs today Many deployment scenarios, you can’t just “upgrade the NAT”, when we need SIP –Especially when the NAT is in the consumers home and the provider wants SIP Solution is to make protocols NAT friendly

NAT Friendly Guidelines Draft-ietf-nat-app-guide-04.txt Some basic ideas in there –Don’t put IP addresses in protocols –Client origination of connections Unfortunately, SIP predates these guidelines So, lets see how to apply them to SIP via small extensions

Basic concepts Find ways to ignore IP addresses in SIP/SDP wherever possible –Get the information from the transport connections themselves Find ways to make a peer to peer application look like client server –One side initiates –Can send data back and forth Don’t rely on DNS, since many clients won’t have domain names

Our assumptions NATs let packets out, both UDP and TCP If packet comes from {A,B} to {C,D}, {A,B} is bound to {X,Y} Packet forwarded with source {X,Y} Packets from {C,D}, to {X,Y}, are natted to {A,B} – ONLY packets from {C,D} –Most restrictive case for UDP UDP binding maintained as long as there is activity in either direction for many seconds to a minute

Reference Model UAC A UAS B NAT proxy

First problem: SIP UAC to proxy SIP over UDP is not NAT friendly –Uses port number from Via header SIP over TCP is NAT friendly –Send response to existing connection Recommendation: –UAC should use TCP to proxy for sending messages –Keep persistent connection to minimize setup delay

Second problem: proxy to UAS Proxy to UAS routing is through registrations Registration has Contact header containing address to send to –Not NAT friendly –Address is wrong –No NAT binding for it Solution –Registration sent over TCP connection to proxy –That connection used for incoming INVITEs –UAS listens on connection –But: contact header will not point to this connection!

Contact Cookie Special contact value which tells registrar “register my contact using the IP address and port where the register came from” –Register comes from persistent TCP connection to server –Causes calls to be routed to UAS through NAT! Want to be explicit –Call forward service Contact “cookie” –Special URL

Solves many other problems Multi-homed hosts –VPN interface to private network –Registrar on public network and private –Need to pick the right interface for each registration –Client can’t easily tell which interface to pick! –Let server figure it out Can’t tell my address –Many hosts can’t determine their IP address Java Applets –Can’t write SIP UA as Java applet today –Why? Can’t communicate anywhere but server –If registrar = server, can connect to server, and now receive incoming invites on that connection!

Hard part: RTP Current RTP is unidirectional –A indicates IP/port to receive from B –B indicates IP/port to receive from A –If either is behind NAT, media won’t flow to them Solution: make RTP look like client-server protocol –A indicates IP/port to receive from B –B sends to A, A sends back to B using source IP/port of RTP –Basically, only need IP address from ONE of the participants – the “server”

Symmetric RTP Conceptually, this is symmetric RTP Connection oriented Problem: who initiates connection to whom? –Same problem for media over TCP –Need to define active and passive participants Work already in mmusic to do just that –Draft-ietf-mmusic-sdp- comedia-00.txt –All we need is to define new keyword for this

Handles two of three cases A behind NAT, B not –A initiates RTP connection to B –B tries to connect to A, but since A provided private address, fails –B receives RTP packet from A –B sends RTP packets to source address of packet from A –A->B connection used B behind NAT, A not –B initiates RTPconnection to A –A tries to connect to B, but since B provided private address, fails –A receives RTP packet from B –A sends RTP packets to source address of packet from B –B->A connection used

What about third case? Both behind NAT is hard Many solutions possible Baseline solution: RTP translator outside of NAT –Both users connect to translator AB NAT RTP trans

How does translator get there? Proxies on both sides know whether their users are behind NAT –Via header doesn’t match source IP/port –Requires client to place listen interface into Via header Socket connect must happen before via added A’s proxy modifies SDP to indicate active if A is behind NAT If B’s proxy gets INVITE with active SDP, and B is behind NAT, problem!

How does translator get there? When there’s a problem –B’s proxy allocates translator –Modifies SDP address in INVITE to point to translator –Modifies SDP address in 200 to point to translator –A and B connect to translator –Translator sends media back to A and B over those connections Other solutions are possible No solutions are possible without this ability to send packets back to source address through binding!

Symmetric RTP Solves other problems too Java applets –Same problem as before SOCKS –SIP/RTP/SDP applications can now be socksified!! Reduces number of bindings needed in NATs –1 per call instead of 2 Works with firewalls that allow outbound connection oriented UDP Generally, anything that assumes client- server connection oriented traffic –Many things

So, what needs to be done? Framework document that describes concepts in light of existing NAT and midcom work SIP extension –Contact cookie –Anything else possibly needed SDP Usage –Add token to comedia draft –Describe symmetric RTP conventions