1. P2P SIP Tutorial Part 3: Advanced P2P SIP and NAT Traversal Henry Sinnreich Alan Johnston March 17, 2008

5. Overlay Example Peer A Peer B 3. Admitting Peer acts as Rendezvous to establish Connection between Joining Peer and B 4. B acts as Rendezvous to establish connection between Joining Peer and A. Peer A 4. B acts as Rendezvous to establish connection between Joining Peer and A. Bootstrap Server Joining Peer 1. Joining Peer connects to Bootstrap Server to join the overlay Admitting Peer 2. Bootstrap Server acts as Rendezvous to establish connection between Joining Peer and Admitting Peer Peer B 3. Admitting Peer acts as Rendezvous to establish Connection between Joining Peer and B Peer A 4. B acts as Rendezvous to establish connection between Joining Peer and A.

6. Call forwarding in an overlay example Peer A is not present and has calls forwarded to a TN Caller Outside Overlay Peer C 2. Peer C routes the INVITE towards Peer A Peer B 3. INVITE request lands at Peer B which is the “closest” to the missing Peer A. 4. Peer B provides call forwarding information back to Peer C. Forwarded TN Outside Overlay 5. Peer C proxies the INVITE to Forwarded TN or redirects Caller to Forwarded TN. SIP RTP 1. Outside Caller calls Peer A and sends INVITE which is routed into the Overlay. SIP

7. Voicemail in an overlay example Peer A is not present and has voicemail provided by another peer. Caller Outside Overlay 2. Peer C routes the INVITE towards Peer A Peer B 3. INVITE request lands at Peer B which is the “closest” to the missing Peer A. 4. Peer B answers call, plays prompt and records voicemail message. INVITE/200 OK/ACK RTP or SRTP Peer C 1. Outside Caller calls Peer A and sends INVITE which is routed into the Overlay. SIP

8. Voicemail retrieval in an overlay example Peer B has left overlay 3. Peer A establishes media session with Peer D and retrieves voicemail message. SIP RTP or SRTP 2. Peer A contacts Peer D and receives MWI indication Peer D 1. Peer A rejoins Overlay

14. NAT traversal drives VoIP design (no SBC assumed) ISP network Residential NAT SIP UAs must connect to each other through all NATs ISP network Residential NAT NAT NAT Internet Public IP Address Realm Enterprise network NAT Residential NAT Home network Home network ISP NAT Residential NAT Home network Home network hairpin interdomain NAT Multi homed

15. Failure scenarios with NAT Ref: <draft-ietf-sipping-nat-scenarios> Client Proxy NAPT 5650 (open) (5060) SIP Request SIP Response The SIP/UDP request contains in Via or ‘received’ (added by a proxy) the IP or port of the client inside the NAT. 5060 Client Proxy NAT (5060) REGISTER/response INVITE The SIP/TCP REGISTER will work correctly, but an incoming INVITE later will attempt to use a new TCP connection to the registered entity and fail. The failure can be avoided by re-using the initial TCP connection. 8023 Client Client NAT SDP offer/exchange (RFC 3264) is attempted, but since SIP is providing the internal addresses of the client, the RTP flow fails. NAT SIP signaling RTP RTP

17. Tunneling for NAT and Firewall Traversal 1. http://www.iana.org/assignments/port-numbers 2. http://www.microsoft.com/technet/prodtechnol/exchange/2003/security.mspx 3. draft-lear-iana-no-more-well-known-ports-01.txt Examples of well known 1 (reserved) ports: 0 to1,024, or use DNS SRV 3 . Tunneling various protocols “under false name” (such as port 80) Tunneling violations are a security risk that may invite deep packet inspection But deep packet inspection by service providers may be a privacy violation Right approach: Cooperation with the IT department and ISPs to use HTTP tunneling Port numbers range from 0 to 65536 Port 80 is most often used for tunneling and should be blocked for IPSec w. Firewall 2. along with other unused ports SIP/TLS 5061 HTTP 80 DNS 53 SMTP 25 Telnet 23 File Transfer 19-21 Protocol Port Number

18. The hole punching approach B. Ford et al: “Peer-to-Peer Communication Across Network Address Translators” http://www.brynosaurus.com/pub/net/p2pnat/

19. NAT check test method Test method for UDP Ping to servers 1 and 2 OK if both report the same public IP address Srv2 reports IP to Srv3 which pings the client. OK if ping is seen by client. 2 nd UDP port to check the hairpin translation of the NAT Test method for TCP Similar, but using SYN and TCP timeouts B. Ford et al: “Peer-to-Peer Communication Across Network Address Translators” http://www.brynosaurus.com/pub/net/p2pnat/ Srv1 Srv2 Srv3 1st UDP port 2nd UDP port Client Internet NAT Private Network X

20. NAT support for UDP and TCP hole punching http://www.brynosaurus.com/pub/net/p2pnat/ 380 data points w. NAT from 68 vendors (13%) 37/286 (64%) 184/286 (24%) 80/335 (82%) 310/380 All Vendors (100%) 1/1 (67%) 2/3 (50%) 3/6 (78%) 7/9 FreeBSD (8%) 2/24 (67%) 16/24 (12%) 3/25 (81%) 26/32 Linux (90%) 28/31 (52%) 16/31 (34%) 11/32 (94%) 31/33 Windows OS-based NAT (0%) 0/6 (83%) 5/6 (14%) 1/7 (100%) 7/7 3Com (0%) 0/7 (0%) 0/7 (13%) 1/8 (78%) 7/9 ZyXEL (22%) 2/9 (89%) 8/9 (30%) 3/10 (100%) 12/12 SMC (29%) 2/7 (86%) 6/7 (33%) 3/9 (100%) 12/12 Cisco (0%) 0/11 (100%) 11/11 (7%) 1/14 (100%) 14/14 Belkin (0%) 0/7 (29%) 2/7 (25%) 3/12 (12%) 2/17 Draytek (11%) 2/19 (47%) 9/19 (52%) 11/21 (76%) 16/21 D-Link (0%) 0/30 (63%) 19/30 (9%) 3/35 (84%) 31/37 Netgear (8%) 3/38 (87%) 33/38 (12%) 5/42 (98%) 45/46 Linksys NAT Hardware Hairpin Punching Hairpin Punching Hole Hole TCP UDP

23. Symmetric response routing Ref: RFC 3581: “Symmetric Response Routing” 10.1.1.1:4540 192.0.2.1:9988 INVITE INVITE 200 OK 200 OK INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff UA NAT Proxy UA NAT Proxy UA NAT Proxy

25. STUN usages I-D.nat-control-stun-usage Discovering, Querying, and Controlling Firewalls and NATs 4 I-D.ietf-behave-nat-behavior-discovery NAT Behavior Discovery 3 I-D.ietf-sip-outbound Client-initiated connections for SIP 2 I-D.ietf-mmusic-ice Interactive Connectivity Establishment (ICE) 1

26. NAT behavior discovery using STUN http://ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-01.txt See if the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS do not match Detecting generic ALGs … that hunt and rewrite IP addresses PADDING only applies to UDP datagrams and can not be used with XOR-RESPONSE-ADDRESS (problem) Fragment handling No hairpin for fragments or discard The client then sends a STUN Binding Request to this mapped address from a different port. If the client receives its own request, the NAT hairpins OK NAT hairpinning Whether it is behind a NAT that supports hairpinning of connections Timed tests using a 2 nd STUN address to check if an existing binding that hasn't had traffic sent on it is still open after time T Binding lifetime Keepalive messages must be sent across the connection to preserve it Tests request responses from the alternate address and port of the STUN server; a precondition to these tests is that no binding be established to the alternate address and port NAT filtering Independent filtering, address dependent filtering, or address and port dependent filtering Binding requests to alternate STUN transport addresses. UDP, TCP, TCP/TLS NAT mapping type Independent, address dependent, or port dependent mapping

27. Discovery, query and control of NAT and FW http://ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-05.txt Multilevel NAT discovery, if NAT has embedded STUN server STUN client NAT A NAT B STUN server 1 st binding request-response Learn NAT B 2nd binding request-response Learn NAT A and it is the last 3rd binding request-response Hairpining reduces the keepalive traffic outside (does not work for UDP fragments). Improves ICE.

29. Interactive Connectivity Establishment (ICE) scenario Send candidates to remote agent draft-ietf-mmusic-ice-17 SIP signaling Agent L SIP Srvr NAT Agent R NAT Relayed Candidate Sever Reflexive Candidate Host Candidate STUN Srvr Internet

30. Traversal Using Relays around NAT (TURN) draft-ietf-behave-turn-04.txt Only for address/port dependent “bad” NATs – relays are expensive (BW) and add delay to voice (over) simplified call flow has 24 messages STUN Client STUN/TURN Relay External Client Client requesting allocations Internal remote transport address Internal local transport address External local transport address Internal remote transport address Internal 5-tuple External 5-tuple binding binding binding NAT

32. HIP base exchange with a rendezvous server “ HIP Rendezvous Extension” I-D: draft-ietf-hip-rvs by J.Laganier and L. Eggert RVS I R I1 I1 R1 I2 R2

34. Summary of IETF NAT traversal for SIP and RTP C. Boulton: “NAT Scenarios” I-D STUN keep alive messages Timers in NAT close the bindings Timers in NAT ICE Symmetric RTP doesn’t work TURN relay STUN doesn’t work with IP address/port depending mapping RFC 3489bis: STUN UA doesn’t know address outside of NAT RFC 3605: Extension to SDP for explicit RTCP port negotiation using new attribute “a=rtcp” RTCP port=RTP port+1 breaks down when NAT ports are occupied “ Symmetric RTP is Helpful” Inbound and outbound IP addresses are different RTP/RTCP Media Transport Connection Reuse “sip-outbound” SIP/TCP fails in reverse direction through NAT. Keepalives. RFC 3581: Change to Via with “rport” Symmetric Response SIP/UDP: Via shows internal address behind NAT SIP Signaling Solutions Problem Category Consumer UA profile Primary UA profile

36. NAT Traversal research has the latest insight NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity by. S Guha et al. http://www.sigcomm.org/sigcomm2004/workshop_papers/fdna02-guha1.pdf NUTSS Tutorial http://www.csie.ntu.edu.tw/~acpang/course/voip_2005/report/419_2.pdf The state of the art NAT issues

37. Questions and discussion