Making SIP NAT Friendly

1. Making SIP NAT Friendly Jonathan Rosenberg dynamicsoft

2. 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

3. 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

4. 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

5. 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

6. Reference Model proxy proxy NAT NAT UAC A UAS B

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

8. 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!

9. 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 • Sip:<user>@jibufobutbmpu

10. 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! Solves many other problems

11. 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” Hard part: RTP

12. 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 Symmetric RTP

13. 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 Handles two of three cases

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

15. 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?

16. 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! How does translator get there?

17. 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 Symmetric RTP Solves other problems too

18. 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 So, what needs to be done?