1. Running SIP behind NAT Dr. Christian Stredicke, snom technology AG, cs@snom.de Voice Over Net, USA, April 2003

2. V1.0 2 Doing SIP without NAT was a little bit naïve… IPv4 32-bit are not enough –USA might have enough addresses, ROW does not –16 bit port address can be recycled into part of address (that’s called NAT) –Ethernet uses 48 bit which seems to be enough IPv6 –Solves the problems –Big migration headache –Who is using it? People ARE using Routers that do NAT –Increases Security –Reduce cost by sharing address

3. V1.0 3 Which information does a client has to set up for port forwarding in NAT equipment? Router needs information where to send packets in private network –Map port to private address and port –By default packets will be rejected or sent to DMZ Router needs hint for security checking –Accept packets from any destination –Accept packets only from associated host –Accept packets only from associated host and port 123.123.123.123 192.168.0.1 Router Client

4. V1.0 4 How did other applications solve the problem? HTTP, telnet, … –Using TCP DNS, others –“Digging holes”: Set up association when client sends out packet from unmapped port for 15-60 seconds –Security policy hardwired by vendor –Some offer a DNS proxy (application layer gateway) ftp –Does not work! –Inexperienced users use http instead –Some routers offer applications layer gateway Heterogeneous environment –Every vendor does it in a different way –“Digging holes” is common denominator

5. V1.0 5 Application layer gateways (ALG) solve the problem in the business area Business customers have different requirements than home users –Many phones –Want to run proxies, media servers, application servers behind their firewall –These applications probably will not have UPnP or STUN Therefore, firewalls will probably include SIP-aware ALG Commercial products e.g. from Cisco, Intertex, Ingate, Jasomi, …

6. V1.0 6 STUN uses the digging hole trick to set up port associations Initialization procedure checks environment –Goal: Check if STUN is needed –Type of NAT does actually not really matter because user is not interested in failure reason SIP port kept alive by sending packets every 15-60 s RTP ports are allocated dynamically when starting a call –Otherwise keep-alive traffic would be double –RTCP port can not be allocated because next port allocation is unlikely –Long ringing and putting caller on hold is problematic (no port refresh during this time)

7. V1.0 7 TURN works in symmetrical NAT environment, but has too many problems Set up a “mirror” in the public Internet –Forward all packets to the “hole” Scalability –TURN server becomes “media server” –Every call generates about 50 packets per second Delay –Sending packets over media server increases transport delay significantly –E.g. local call in Tokyo when TURN server is in Frankfurt

8. V1.0 8 The “almost” problem: STUN works fine in 90 % of the cases Programmer: “I am almost finished” –Translation: “I solved the simple problems, and I don’t yet have a clue what the hard problems are” Some routers do not run STUN without user interaction –Stateful inspection –Trying to be smart –Users must set up DMZ 10 % support calls are intolerable STUN can only be „gap-filler“ –“Best Effort” –No support Need clear indication if VoIP will work –Clear technical specification under which circumstances customers can expect setup to work –UPnP is good candidate for this

9. V1.0 9 UPnP is the right approach. Generic protocol to allocate ports on router –Works with SIP, can be used with other applications as well –Can be integrated with firewalls –Not too hard to implement Microsoft Messenger uses UPnP –“De facto standard” –Many DSL router vendors offer UPnP now Problem: Old Equipment –Software Updates! –Use STUN –Maybe use TURN, even if call duration is terrible –Instruct customers to set up ports manually

10. V1.0 10 How does port forwarding in UPnP work? Find the Internet access device –Broadcast messages (no user setup required) –Download the description of the UPnP device via http Retrieve the public IP address from the router Set up port mapping explicitly –http requests using XML (SOAP) attachments Other commands also available –UPnP is much more than setting up port forwarding on routers

11. V1.0 11 With the increasing availability of UPnP, most home customers can be addressed UPnP STUN UPnP STUN Beginning of 2003End of 2003 Software Updates New Equipment

12. V1.0 12 Calling phones in the same network requires ancillary information* 1a) Phone A sends to public address of B 1b) Router will not forward packet, call will fail 2) A knows B is in the same NAT and sends packet to private address instead * If no ALG is involved

13. V1.0 13 Ancillary information must be placed in contact URI and in SDP INVITE sip:info1@snomag.de SIP/2.0 Via: SIP/2.0/UDP 218.230.0.59:5060;branch=z9hG4bK-6rms4e9tmtsz Max-Forwards: 70 From: ;tag=16z5zw9lqt To: Call-ID: 0000a4f95f24-zzt41v6ulesj@218.230.0.59 CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 311 v=0 o=root 19211 19211 IN IP4 218.230.0.59 s=SIP Call c=IN IP4 218.230.0.59 t=0 0 m=audio 10004 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=srcadr:192.168.0.4:10004 218.230.0.59:10004

14. V1.0 14 Alternatively, we could use a “no router” as additional path element REGISTER sip:bla.com SIP/2.0 Path: Contact:... When it receives a message this could look like this: INVITE sip:62.12.245.32:54456;nr=1 SIP/2.0 Route:... SIP/2.0 200 Wonderful Record-Route: Contact:

15. V1.0 15 NAT2NAT3 NAT1 Multi-tier NAT with STUN requires a STUN server between the tiers and in the public Internet 192.168.0.1 192.168.0.2 10.0.0.310.0.0.2 10.0.0.1 123.123.123.123 A has three identities: 1. 192.168.0.2:5060 2. 10.0.0.2:1234 3. 123.123.123.123:5678 B has three identities: 1. 192.168.0.2:5060 2. 10.0.0.3:1234 3. 123.123.123.123:5679 STUN Phone APhone B When using STUN, a STUN server is required between the layers

16. V1.0 16 NAT2 NAT1 Multi-tier NAT with UPnP would require a access to all involved UPnP routers 192.168.0.1 192.168.0.2 10.0.0.2 123.123.123.123 Phone A Normal UPnP Access and Detection Somehow we have to bypass the first router

17. V1.0 17 How should a phone boot up? Try UPnP Use UPnP Try to Register Use STUNUse Given Identity UPnP available No response (5 seconds) or not available No problem: either public address, ALG or total private environment Registrar complains about private address This step can be done even without STUN, as the registrar returns the response quick

18. V1.0 18 Is UPnP secure? A possible man-in-the-middle attack scenario… 1. A opens RTP forwarding port Phone BPhone A 2. B retrieves forwarding table 3. B rearranges port forwarding 4. B receives all RTP from the IAD and forwards it to A (after recording it) Same attack can be done with signaling Can be solved with TLS and SRTP

19. V1.0 19 Security is ok for home networks, but for business networks some enhancements are needed How much security needs a home? –Son listens to call of daughter –Son listens to call of father doing telephone banking –Son using Ethereal, son is listening on the door STUN is also not secure –ARP attacks can also redirect the packet flow (however that’s not so easy) Attacks from the outside –Orphan bindings may give access to private devices –Devices should be able to deal with this anyway Security enhancements in UPnP Version 2 Businesses should use ALG which takes care about it

20. V1.0 20 To make UPnP more reliable, clients need to allocate bandwidth Don’t allocate bandwidth “just in case” –Allocating ports at startup is easy and can set scheduling priorities –But when too many VoIP calls are done, all of them suffer Ask for bandwidth before a call starts –Sending busy is better than having stuttering calls –Phone needs to know when bandwidth is available again so that call completion can be indicated –Notification when bandwidth is available Could be added to current allocation requests –Bandwidth indication –Insufficient bandwidth as denial reason

21. V1.0 21 Some words about the current UPnP V2 specification process “Lessons Learned” clearly on the agenda –Moderated discussion –Results be expected not before end of this year QoS scope too narrow for VoIP –QoS only within the UPnP network –Focus on delivering video at home –UPnP edge devices must serve as QoS gateways –No improvement for VoIP calls outside the home network Security profile still tuned at home requirements –Seems to be still no option for business

22. V1.0 22 Conclusion: Tell the customer what he should do about NAT If you can, use an ALG –Works will all SIP-compliant equipment –Most expensive solution, but complete functionality Else if you can, use UPnP –Works with all SIP- and UPnP-compliant equipment –“MS Messenger” solution, routers for 65 $ available –Problems making calls within the private network Else if you dare, use STUN –Works with all SIP- and STUN-compliant equipment if the routers are not inspecting packets –Could become support-headache –Also problems in the private network If you also want to support the rest, think about TURN –Works with all SIP-, STUN/TURN-compliant equipment and the 99% of the NAT routers

23. sip:info@snomag.de

24. © 2003 snom technology Aktiengesellschaft Written by: Dr. Christian Stredicke Version: 1.0 The author has made his best effort to prepare this document. The content is based upon latest information whenever possible. The author makes no representation or warranties of any kind with regard to the completeness or accuracy of the contents herein and accept no liability of any kind including but not limited to performance, merchantability, fitness for any particular purpose, or any losses or damages of any kind caused or alleged to be caused directly or indirectly from this document. For more information, mail info@snom.de, Pascalstr. 10E, 10587 Berlin, Germany.

25. V1.0 25 In cases when NAT is symmetrical, TURN could be a solution 123.123.123.123 192.168.0.1 Router Client STUN/TURN Server 124.124.124.124 1. Allocate Request/Response 2. Activate Request/Response 3. SIP/Media