NAT and Firewall Traversal. VoIP and MultiMedia /77

Transcription

1 and Firewall Traversal VoIP and MultiMedia /77

2 Introduction Does anyone remember why we started working on IPv6? ICAN says IPv4 addresses will run out by 2011 XXXX says the same YYYY also confirms Oh, and MIT alone have more addresses than entire China! VoIP and MultiMedia /77

3 Introduction well ok but who cares about IPv4 addresses? we have s right? VoIP and MultiMedia 2011 emil.ivov@jitsi.org 3/77

4 Standard usage VoIP and MultiMedia /77

5 Less standard usage: End to end services? VoIP and MultiMedia /77

6 Introduction We need public IPs because of e2e services such as VoIP for example. Right, so do you know of any production IPv6 VoIP deployments? I don t! Through the rest of this presentation I ll try to explain why I think this is the case. VoIP and MultiMedia 2011 emil.ivov@jitsi.org 6/77

7 The basics of IP telephony A sample call network core (registrars, proxies, ) Bob Address: B Port: Pb Alice Address: A Port: Pa VoIP and MultiMedia 2011 emil.ivov@jitsi.org 7/77

8 The basics of IP telephony A sample call network core (registrars, proxies, ) Bob Address: B Port: Pb Alice Address: A Port: Pa VoIP and MultiMedia 2011 emil.ivov@jitsi.org 8/77

9 The basics of IP telephony. network core (registrars, proxies, ) MEDIA over (S)RTP Bob Address: B Port: Pb Alice Address: A Port: Pa VoIP and MultiMedia 2011 emil.ivov@jitsi.org 9/77

10 Session initialization with SIP and XMPP INVITE SIP/2.0 Via: SIP/2.0/UDP ;branch=1 From: To: Contact: Call-ID: Cseq: INVITE v=0 o=user IP s=. t=0 0 c=in IP m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 <iq from='juliet@capulet.lit/balcony' id='hs81w639' to='romeo@montague.lit/orchard' type='set'> <jingle xmlns='urn:xmpp:jingle:1' action='session-accept' initiator='romeo@montague.lit/orchard' responder='juliet@capulet.lit/balcony' sid='a73sjjvkla37jfea'> <content creator='initiator' name='voice'> <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'> <payload-type id='18' name='g729'/> </description> <transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'> <candidate component='1' generation='0' id='z7sdjb01hf' ip=' ' port='9876'/> <candidate component='2' generation='0' id='hg92lsn10b' ip=' ' port='9877'/> </transport> </content> </jingle> </iq> VoIP and MultiMedia 2011 emil.ivov@jitsi.org 10/77

11 And then s were born Call: To: B Media: Ap Call: To: B Media: Ap ERROR Alice Private Address: Ap /Firewall Address: F Bob Address: B VoIP and MultiMedia 2011 emil.ivov@jitsi.org 11/77

12 Internal host:port How do s work port : MSG: Dst: : 80 Src: : 2368 MSG: Dst: : 80 Src: : 8632 Alice Internal Address: Public Address: Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 12/77

13 Internal host:port How do s work port : MSG: Dst: : 2368 Src: : 80 MSG: Dst: : 8632 Src: : 80 Alice Internal Address: Public Address: Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 13/77

14 Internal host:port How do s work port : Endpoint-Independent Mapping Endpoint-Independent Filtering Bob Address: MSG: Dst: : 2368 Src: : 9595 Alice Internal Address: Public Address: Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 14/77

15 Basic Firewall and Traversal STUN What are my address and port? Address: F Port: Pf STUN Server Alice Address: Ap Port: Pa Address: F Bob Address: B Call: To: B Media: F:Pf STUN Server Alice Address: Ap Port: Pa Answer: To: A Media: B Bob Address: B VoIP and MultiMedia 2011 emil.ivov@jitsi.org 15/77

16 STUN Demystified RFC STUN Message Type Message Length Magic Cookie Transaction ID (96 bits) Stun Attributes " Format of STUN Message Header " VoIP and MultiMedia 2011 emil.ivov@jitsi.org 16/77

17 STUN Binding Request x0001 Message Length Magic Cookie Transaction ID (96 bits) Format of STUN Message Header " VoIP and MultiMedia 2011 emil.ivov@jitsi.org 17/77

18 STUN Attributes RFC Type Length Value (variable) Format of STUN Attributes" VoIP and MultiMedia 2011 emil.ivov@jitsi.org 18/77

19 STUN Mapped Address x0001 Length Family Port Address (32 bits or 128 bits) Format of MAPPED-ADDRESS Attribute" The address family can take on the following values: 0x01:IPv4 0x02:IPv6" VoIP and MultiMedia 2011 emil.ivov@jitsi.org 19/77

20 STUN XOR-MAPPED-ADDRESS x0020 Length x x x x x x x x Family X-Port X-Address (Variable) " Format of XOR-MAPPED-ADDRESS Attribute " The address family can take on the following values: 0x01:IPv4 0x02:IPv6" VoIP and MultiMedia 2011 emil.ivov@jitsi.org 20/77

21 STUN User Name x0006 Length Value (variable) Format of STUN User Name Attribute" VoIP and MultiMedia 2011 emil.ivov@jitsi.org 21/77

22 How do s work Address (and port) dependent filtering Internal host:port port Active connections host:port : (: 80) MSG: Dst: : 80 Src: : 2368 MSG: Dst: : 80 Src: : 8632 Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 22/77

23 How do s work Address (and port) dependent filtering Internal host:port port Active connections host:port : (: 80) MSG: Dst: : 2368 Src: : 80 MSG: Dst: : 8632 Src: : 80 Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 23/77

24 How do s work Address (and port) dependent filtering Internal host:port port Active connections host:port : (: 80) Endpoint-Independent Mapping Endpoint-Dependent Filtering Bob Address: STOP Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 24/77

25 How do s work Address (and port) dependent filtering Internal host:port port Active connections host:port : (: 80) (: 80) Bob Address: MSG: Dst: : 80 Src: : 2368 Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 25/77

26 How do s work Address (and port) dependent filtering Internal host:port port Active connections host:port : (: 80) Endpoint-Independent Mapping Endpoint-Dependent Filtering (: 80) Bob Address: MSG: Dst: : 2368 Src: : 80 Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 26/77

27 How do s work Endpoint dependent mapping Internal host:port port Active connections host:port : (: 80) MSG: Dst: : 80 Src: : 2368 MSG: Dst: : 80 Src: : 8632 Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 27/77

28 How do s work Endpoint dependent mapping Internal host:port port Active connections host:port : (: 80) MSG: Dst: : 2368 Src: : 80 MSG: Dst: : 8632 Src: : 80 Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 28/77

29 How do s work Endpoint dependent mapping Internal host:port port Active connections host:port : (: 80) : (: 80) Bob Address: MSG: Dst: : 80 Src: : 2368 Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 29/77

30 Internal host:port How do s work Endpoint dependent mapping port Active connections host:port : (: 80) : (: 80) Endpoint-Dependent Mapping Endpoint-Dependent Filtering MSG: Dst: : 2368 Src: : 80 Bob Address: Alice Internal Address: Public Address: STUN Server Address: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 30/77

31 Universal Plug and Play (UPnP) Designed for zero-configuration networking and to allow devices to: dynamically join a network and obtain an IP address announce its name advertise capabilities discover other devices and their capabilities Makes it easy to: Learn the external (public) address of an internet gateway Enumerate existing port mappings Add and remove port mappings Assign lease times to mappings Standardized as a 73-part International Standard, ISO/IEC 29341, in December, VoIP and MultiMedia 2011 emil.ivov@jitsi.org 31/77

32 Relaying Media Symmetric /Firewall F1:P1 TURN Server Address: T Port: Pt Alice Address: Ap Port: Pa Call: To: B Media: T:Pt Symmetric /Firewall F1:p2 Bob Address: B VoIP and MultiMedia 2011 emil.ivov@jitsi.org 32/77

33 Relaying Media Symmetric /Firewall F1:P1 TURN Server Address: T Port: Pt Bob Address: B Alice Address: Ap Port: Pa Symmetric /Firewall F1:p2 VoIP and MultiMedia 2011 emil.ivov@jitsi.org 33/77

34 TURN Allocate Request x0003 Message Length Magic Cookie Transaction ID (96 bits) VoIP and MultiMedia 2011 emil.ivov@jitsi.org 34/77

35 Relaying Media The SIP Way Latching /Firewall SIP Server Address: T Port: Pt Alice Address: Ap Port: Pa Bob Address: B VoIP and MultiMedia 2011 emil.ivov@jitsi.org 35/77

36 Relaying Media The SIP Way Latching /Firewall SIP Server Address: T Port: Pt Alice Address: Ap Port: Pa Bob Address: B VoIP and MultiMedia 2011 emil.ivov@jitsi.org 36/77

37 Relaying Media SIP clients behind a symmetric /firewall non-scalable expensive complex symmetric firewall Relay Server SIP clients behind a symmetric / firewall symmetric /firewall VoIP and MultiMedia 2011 emil.ivov@jitsi.org 37/77

38 Using P2P networks for Traversal p2p Custom P2P network p2p p2p symmetric firewall p2p p2p custom p2p relay clients p2p Skype among the first to implement the technique p2p P2PSIP set off to imitate Skype. No conclusive results after four years p2p symmetric firewall Jingle Nodes an interesting alternative that is worth keeping an eye on custom p2p clients VoIP and MultiMedia /77

39 Could we please have IPv6 now? ok, it s probably high time we moved to IPv6 VoIP and MultiMedia 2011 emil.ivov@jitsi.org 39/77

40 Could we please have IPv6 now? this should simplify VoIP shouldn t it? VoIP and MultiMedia 2011 emil.ivov@jitsi.org 40/77

41 VoIP and IPv6 demo version network core (registrars, proxies, ) Bob 2001:660::1 Alice 2001:660::2 VoIP and MultiMedia 2011 emil.ivov@jitsi.org 41/77

42 VoIP and IPv6 demo version network core (registrars, proxies, ) Bob 2001:660::1 Alice 2001:660::2 VoIP and MultiMedia 2011 emil.ivov@jitsi.org 42/77

43 VoIP and IPv6 demo version network core (registrars, proxies, ) MEDIA Bob 2001:660::1 Alice 2001:660::2 VoIP and MultiMedia 2011 emil.ivov@jitsi.org 43/77

44 Reality check! Reality check! VoIP and MultiMedia /77

45 Reality check! VPN Priv: Pub: Stun Relay Server Alice 2001:660:: SIP network Bob Alice s list of addresses: 2001:660:: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 45/77

46 How to avoid relaying? Interactive Connectivity Establishment (ICE) An IETF RFC brought to you by Skype s Jonathan Rosenberg VoIP and MultiMedia 2011 emil.ivov@jitsi.org 46/77

47 Address management with ICE VPN Priv: Pub: Stun Relay Server Alice SIP network Bob Please try me on any of Alice s list of addresses: the following: 2001:660::2 2001:660:: VoIP and MultiMedia emil.ivov@jitsi.org 47/77

48 Address management with ICE ERROR ERROR VPN Priv: Pub: Stun Relay Server Alice SIP network Bob ERROR Alice s list of addresses: 2001:660:: ERROR ERROR :660:: VoIP and MultiMedia 2011 emil.ivov@jitsi.org 48/77

49 Make no assumptions on: Network topologies behaviors location or presence ICE Design Goals High reliability is essential 90% is not good enough Simple topologies yield simple flows and faster establishment, complex topologies yield complex flows and slower establishment Try to minimize length of the path between clients VoIP and MultiMedia /77

50 The ICE 9-Step Program to Recovery Step 1: Allocation Step 2: Prioritization Step 3: Initiation Step 4: Allocation Step 5: Information Step 6: Verification Step 7: Coordination Step 8: Communication Step 9: Confirmation VoIP and MultiMedia /77

51 ICE Step 1: Allocation Before initiating the session, the Client Gathers Candidates Relay Relayed candidates reside on a host acting as a relay towards the agent Each candidate is a potential address for receiving traffic Three different types of candidates Host Candidates Server Reflexive Candidates Relayed Candidates Host Candidates reside on the agent itself Server Reflexive candidates are addresses residing on a VoIP and MultiMedia 2011 emil.ivov@jitsi.org 51/77

52 Using TURN to Obtain Candidates Server reflexive and relayed candidates are learned jointly by talking to a TURN server Client sends query to TURN server TURN Server :8200 Query passes through, creates bindings TURN server allocates a relayed address and also reports back source address of request to client This will be the server reflexive address Allocate Request Allocate Response reflexive= :1000 relayed= : : :500 VoIP and MultiMedia 2011 emil.ivov@jitsi.org 52/77

53 Pacing of Allocations If a client has Multiple interfaces Multiple IP address versions Multiple STUN servers Multiple media streams Multiple components This can produce a lot of allocation traffic Overload has been reported in the wild s fail to maintain bindings when created too fast For this reason, ICE paces allocations Tries to align with media rate Two problems Network congestion Overload VoIP and MultiMedia 2011 emil.ivov@jitsi.org 53/77

54 ICE Step 2: Prioritization priority = (2^24)*(type preference) +(2^8)*(local preference) +(2^0)*(256 - component ID) Type Preference Local Preference Component ID 32 bits Type-Preference: Preference for type (host, server reflexive, relayed) Usually 0 for relayed, 126 for host Local Preference: Amongst candidates of same type, preference for them If host is multihomed, preference by interface If host has multiple STUN or TURN servers, preference for that server Component ID for grouping candidates that all must work as an atomic unit This algorithm is only SHOULD strength VoIP and MultiMedia 2011 emil.ivov@jitsi.org 54/77

55 Visualization: Priority Space Interface 1 Component 1 Component 2 Host Candidates Interface 2 Server Reflexive Candidates VoIP and MultiMedia 2011 emil.ivov@jitsi.org 55/77

56 ICE Step 3: Initiation Originator sends an offer message to recipient through rendezvous server i.e., SDP offer in SIP INVITE Offer contains, for each candidate: IP address and port Component ID Foundation Transport Protocol Priority Type Related Address Username fragment and Password Offer RVz Srvr VoIP and MultiMedia /77

57 v=0 o=user IP s=. t=0 0 c=in IP m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 M=video RTP/AVP 99 a=rtpmap:99 H264/90000 VoIP and MultiMedia 2011 emil.ivov@jitsi.org 57/77

58 A Sample ICE Offer v=0 o=ice4j.org 0 0 IN IP s=c=in IP t=0 0 a=ice-pwd:3mic8j25sf8m7e583kcr15d860 a=ice-ufrag:34d7g m=audio 1029 RTP/AVP 0 a=candidate:4 1 udp a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe 2020 typ host a=candidate:2 1 udp fe80:0:0:0:21e:52ff:fec6:c65c 2020 typ host a=candidate:5 1 udp fe80:0:0:0:21e:c2ff:fe1b:2fe 2020 typ host a=candidate:1 1 udp typ host a=candidate:3 1 udp typ host a=candidate:6 1 udp typ srflx raddr rport 2020 a=candidate:4 2 udp a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe 2021 typ host a=candidate:2 2 udp fe80:0:0:0:21e:52ff:fec6:c65c 2021 typ host a=candidate:5 2 udp fe80:0:0:0:21e:c2ff:fe1b:2fe 2021 typ host a=candidate:1 2 udp typ host a=candidate:3 2 udp typ host a=candidate:6 2 udp typ srflx raddr rport 2021 m=video 1031 RTP/AVP 0 a=candidate:4 1 udp a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe 2022 typ host a=candidate:2 1 udp fe80:0:0:0:21e:52ff:fec6:c65c 2022 typ host a=candidate:5 1 udp fe80:0:0:0:21e:c2ff:fe1b:2fe 2022 typ host a=candidate:1 1 udp typ host a=candidate:3 1 udp typ host a=candidate:6 1 udp typ srflx raddr rport 2022 a=candidate:4 2 udp a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe 2023 typ host a=candidate:2 2 udp fe80:0:0:0:21e:52ff:fec6:c65c 2023 typ host a=candidate:5 2 udp fe80:0:0:0:21e:c2ff:fe1b:2fe 2023 typ host a=candidate:1 2 udp typ host a=candidate:3 2 udp typ host VoIP and MultiMedia 2011 emil.ivov@jitsi.org 58/77 a=candidate:6 2 udp typ srflx raddr rport 2023

59 ICE Step 4: Allocation Recipient party does exactly same processing as originator and obtains its candidates Recommended to not yet ring the phone (for SIP)! Allocate Request TURN Server Allocate Response VoIP and MultiMedia /77

60 ICE Step 5: Information Recipient sends response containing an answer Answer contains same information as offer did Rvz Srvr answer VoIP and MultiMedia /77

61 ICE Step 6: Verification Each agent pairs up its candidates (local) with its peers (remote) to form candidate pairs Each agent sends a connectivity check at media pacing, in pair priority order Binding Request from the local candidate to the remote candidate TURN Server 5 TURN Server 4 Upon receipt of the request the peer agent generates a response 2 Contains a mapped address indicating the source IP and port seen in the request 3 If the response is received the check has succeeded 1 VoIP and MultiMedia 2011 emil.ivov@jitsi.org 61/77

62 Authenticating STUN STUN Connectivity checks are authenticated and integrity protected Authentication is based on a username and password Offer Ufrag: AUF Password:APASS Rvz Srvr Answer Ufrag: BUF Password:BPASS Username is constructed by combining username fragments exchanged in offer and answer separated by colon Password is exchanged in offer/ answer Username and password are same for all candidates in a media stream Username: BUF:AUF Password: BPASS Stun requests Username: AUF:BUF Password: APASS VoIP and MultiMedia 2011 emil.ivov@jitsi.org 62/77

63 Pairing up Candidates O-P: Offerers Priority A-P: Answerers Priority pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P?1:0) Minimum Priority Maximum Priority 64 bits Pairs are sorted in order of decreasing pair priority Each agent will end up with the same list Last term serves as a tie breaker Min/Max results in highest priority for pair with two host RTP candidates, lowest for pair with two relayed RTCP VoIP and MultiMedia 2011 emil.ivov@jitsi.org 63/77

64 Frozen Algorithm ICE provides an optimization called the Frozen algorithm Applicable when checks need to be done for multiple components or sessions Main idea is to use the results of a previous check to predict the likelihood of a future one working Basic algorithm First, check the candidate pairs for first component of the first session Once one succeeds, then check the other components for the first session that are similar Once those are done, check all other components for all other media streams that are similar Candidates are similar when they are of the same type and obtained from the same interface and STUN or TURN server Same foundation VoIP and MultiMedia 2011 emil.ivov@jitsi.org 64/77

65 Visualizing Frozen Algorithm 9999 Host Candidates Interface 1 Component 1 Component 2 Interface Server Reflexive Candidates Pairs containing the red candidate pairs Will be Waiting, all others Frozen VoIP and MultiMedia 2011 emil.ivov@jitsi.org 65/77

66 Visualizing Frozen Algorithm 9999 Host Candidates Interface 1 Component 1 Component 2 Interface Server Reflexive Candidates Check on interface succeeds (in Green). Component 2 for same foundation is now Waiting to go and will be done next VoIP and MultiMedia 2011 emil.ivov@jitsi.org 66/77

67 Peer Reflexive Candidates Connectivity checks can produce additional candidates Peer reflexive candidates Typically happens when there is a symmetric between users Peer reflexive candidate will be discovered by both users For user A, from the Response For user B, from the Request Allows direct media even in the presence of symmetric! allocates new binding towards B A STUN Request A learns a new local candidate towards B! Sym STUN Response B informs A of new binding B VoIP and MultiMedia 2011 emil.ivov@jitsi.org 67/77

68 ICE Step 7: Coordination ICE needs to finalize on a candidate pair for each component of each media stream More than one may work Each agent needs to conclude on the same set of pairs Finalization takes place without signaling through rendezvous server all through STUN VoIP and MultiMedia 2011 emil.ivov@jitsi.org 68/77

69 Agent Roles One agent acts as the controlling agent, the other as the controlled agent Controlling agent is normally the offerer, unless offerer signals it is an ICE lite implementation Controlling agent responsible for Deciding when STUN checks should finish Deciding which pairs to use once it is finished VoIP and MultiMedia /77

70 Why not just use the first pair? ICE checks proceed in priority order So why not just stop once the first check succeeds, and use that? Several reasons Packet loss on a higher priority check may delay it from finishing giving checks more time may produce better results An agent may have other criteria for choosing pairs (for example RTT estimates!) VoIP and MultiMedia 2011 emil.ivov@jitsi.org 70/77

71 Signaling Completion When controlling agent is done, it inserts a flag into a STUN check If controlled agent had successfully completed a check in reverse direction, it stops checks for that component of that stream Both agents use the pair generated by the check that included the flag STUN Request STUN Response STUN Request+ flag STUN Response done Controlling Controlled VoIP and MultiMedia 2011 emil.ivov@jitsi.org 71/77

72 ICE Lite ICE Supports an implementation level called ICE lite Used for endpoints that always have public IP PSTN gateways Media servers Conference servers These endpoints need to run ICE for ICE to be used, but don t themselves have a problem An agent signals its lite in offer or answer If both agents are lite no checks or state machinery is used A lite agent has a single v4 candidate (host only) and only needs to Receive a STUN check and send a response Process offers and answers Use the candidate pair based on done flag in STUN VoIP and MultiMedia 2011 emil.ivov@jitsi.org 72/77

73 ICE Step 8: Communication Media can flow in each direction once pairs have been selected by the controlling agent for each component Allows early media in both directions STUN Server STUN Server VoIP and MultiMedia /77

74 ICE Step 9: SIP-specific fix-up If m/c-line in original INVITE didn t match candidate pairs selected by ICE, controlling agent does a re-invite to place them in m/c-line Re-INVITE ensures that middleboxes have the correct media address QoS installation (i.e., IMS or Packetcable) Diagnostic tools Monitoring applications Firewalls Re-INVITE 200 OK ACK Offerer Answerer VoIP and MultiMedia 2011 emil.ivov@jitsi.org 74/77

75 and Firewall Traversal VoIP and MultiMedia /77