ICE basic
Download as PPTX, PDF3 likes1,422 views
The document discusses Network Address Translation (NAT) and how it causes issues for SIP calls by hiding private IP addresses. It introduces Interactive Connectivity Establishment (ICE) as the IETF's solution to this problem. ICE uses STUN and TURN to dynamically discover potential transport addresses between endpoints and then verifies connectivity through these addresses to find the optimal path for media.
ICE basic
- 1. Jonathan Rosenberg Cisco Fellow Cisco Interactive Connectivity Establishment: ICE
- 2. What is NAT? • Network Address Translation (NAT) – Creates address binding between internal private and external public address – Modifies IP Addresses/Ports in Packets – Benefits • Avoids network renumbering on change of provider • Allows multiplexing of multiple private addresses into a single public address ($$ savings) • Maintains privacy of internal addresses Client N A T N A T S: 1.2.3.4:8877 D: 67.22.3.1:80 Binding Table Internal External 10.0.1.1:6554 -> 1.2.3.4:8877 S: 10.0.1.1:6554 D: 67.22.3.1:80 IP Pkt IP Pkt
- 3. Why is this bad for SIP? • Client will generate SIP INVITE and 200 OK responses with private addresses – In the SDP as the target for receipt of media – In the Contact of a REGISTER as the target for incoming INVITE – In the Via of a request as the target for the response • Recipient will not be able to send packets to this private address – Media is discarded – Incoming calls are not delivered – Responses are not received Client N A T INVITE Send media to 10.0.1.1:8228
- 4. Why is this bad for SIP? • Client will generate SIP INVITE and 200 OK responses with private addresses – In the SDP as the target for receipt of media – In the Contact of a REGISTER as the target for incoming INVITE – In the Via of a request as the target for the response • Recipient will not be able to send packets to this private address – Media is discarded – Incoming calls are not delivered – Responses are not received Client N A T INVITE Send media to 10.0.1.1:8228 Hardest problem, solved by ICE Solved by SIP Outbound Solved by rport (RFC 3581)
- 5. IETFs Answer: Interactive Connectivity Establishment (ICE) 1. ICE makes use of Simple Traversal Underneath NAT (STUN) and Traversal Using Relay NAT (TURN) 2. ICE is a form of p2p NAT traversal 3. ICE only requires a network to provide STUN and TURN servers 4. ICE allows for media to flow even in very challenging network conditions 5. ICE can make sure the phone doesn’t ring unless media connectivity exists 6. ICE dynamically discovers the shortest path for media to travel between endpoints 7. ICE has a side effect of eliminating a key DoS attack on SIP (Voice Hammer) 8. ICE works through nearly any type of NAT and firewall 9. ICE does not require the endpoint to discover the NATs, their type, or their presence 10. ICE only uses relays in the worst case – when BOTH sides are behind symmetric NAT Top 10 ICE Facts
- 6. 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
- 7. ICE Step 1: Allocation • Before Making a Call, the Client Gathers Candidates • Each candidate is a potential address for receiving media • Three different types of candidates – Host Candidates – Server Reflexive Candidates – Relayed Candidates Relay Host Candidates reside on the agent itself Server Reflexive candidates are addresses residing on a NAT NAT NAT Relayed candidates reside on a host acting as a relay towards the agent
- 8. Using STUN to Obtain Candidates • Server reflexive and relayed candidates are learned by talking to a STUN server using the Relay Usage • Client sends query to STUN relay server • Query passes through NAT, creates bindings • STUN relay server allocates a relayed address and also reports back source address of request to client – This will be the server reflexive address STUN Server 1.2.3.4:1000 NAT NAT 12.13.14.15:8200 10.0.1.1:500 Allocate Request Allocate Response reflexive=1.2.3.4:1000 relayed=12.13.14.15:8200
- 9. ICE Step 2: Prioritization • 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 servers, preference for that server • Component ID as described previously • This algorithm is only SHOULD strength priority = (2^24)*(type preference) +(2^8)*(local preference) +(2^0)*(256 - component ID) Local Preference Component IDType Preference 32 bits
- 10. Visualization: Priority Space Host Candidates Server Reflexive Candidates 65535 Interface 1 Interface 2 RTP RTCP
- 11. Encoding the Offer • Each candidate is placed into an a=candidate attribute of the offer • Each candidate line has – IP address and port – Component ID – Foundation – Transport Protocol – Priority – Type – “Related Address” v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
- 12. Encoding the Offer • Each candidate is placed into an a=candidate attribute of the offer • Each candidate line has – IP address and port – Component ID – Foundation – Transport Protocol – Priority – Type – “Related Address” v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
- 13. Encoding the Offer • Each candidate is placed into an a=candidate attribute of the offer • Each candidate line has – IP address and port – Component ID – Foundation – Transport Protocol – Priority – Type – “Related Address” v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
- 14. Encoding the Offer • Each candidate is placed into an a=candidate attribute of the offer • Each candidate line has – IP address and port – Component ID – Foundation – Transport Protocol – Priority – Type – “Related Address” v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 Foundation is the same for all candidates Of the same type, from the same interface And STUN server. Used as part of the Frozen algorithm (later)
- 15. Encoding the Offer • Each candidate is placed into an a=candidate attribute of the offer • Each candidate line has – IP address and port – Component ID – Foundation – Transport Protocol – Priority – Type – “Related Address” v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 Only UDP defined in ICE-12. Draft-ietf-mmusic-ice-tcp defines several TCP types and TLS
- 16. Encoding the Offer • Each candidate is placed into an a=candidate attribute of the offer • Each candidate line has – IP address and port – Component ID – Foundation – Transport Protocol – Priority – Type – “Related Address” v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
- 17. Encoding the Offer • Each candidate is placed into an a=candidate attribute of the offer • Each candidate line has – IP address and port – Component ID – Foundation – Transport Protocol – Priority – Type – “Related Address” v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
- 18. Encoding the Offer • Each candidate is placed into an a=candidate attribute of the offer • Each candidate line has – IP address and port – Component ID – Foundation – Transport Protocol – Priority – Type – “Related Address” v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 Optional information. For relayed candidates, gives the server reflexive. For server reflexive, gives the host.
- 19. ICE Step 3: Initiation • Caller sends a SIP INVITE as normal • No ICE processing by proxies • SIP itself traverses NAT using SIP outbound and rport SIP Proxy INVITE
- 20. ICE Step 4: Allocation • Called party does exactly same processing as caller and obtains its candidates • Recommended to not yet ring the phone! STUN Server NAT NAT Allocate Request Allocate Response
- 21. ICE Step 5: Information • Caller sends a provisional response containing its SDP with candidates and priorities – Can also happen in 2xx, but this flow is “best” • Provisional response is periodically retransmitted • As with INVITE, no processing by proxies • Phone has still not rung yet SIP Proxy 1xx
- 22. 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 every 20ms, in pair priority order – Binding Request from the local candidate to the remote candidate • Upon receipt of the request the peer agent generates a response – Contains a mapped address indicating the source IP and port seen in the request • If the response is received the check has succeeded STUN Server NAT NAT STUN Server NAT NAT 1 2 3 4 5
- 23. Pairing up Candidates • 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 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 O-P: Offerers Priority A-P: Answerers Priority
- 24. Peer Reflexive Candidates • Connectivity checks can produce additional candidates – Peer reflexive candidates • Typically happens when there is a symmetric NAT 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 NAT! Sym NAT NAT allocates new binding towards B STUN Request STUN Response A B B informs A of new binding A learns a new local candidate towards B!
- 25. 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 SIP signaling – all through STUN
- 26. Agent Roles • One agent acts as the controlling agent, the other as the passive agent • Controlling agent is normally the offerer, unless offerer signals it only supports passive role (see later) • Controlling agent responsible for – Deciding when STUN checks should finish – Deciding which pairs to use once it is finished
- 27. 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!)
- 28. Signaling Completion • When controlling agent is done, it inserts a flag into a STUN check • If passive 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 • When ‘done’ – ring the phone! Controlling Passive STUN Request+ flag STUN Response STUN Request STUN Response done
- 29. 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 NAT NAT STUN Server NAT NAT
- 30. ICE Step 9: Confirmation • 200 OK and ACK work as normal – 200 mirrors SDP from provisional • 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 Offerer Answerer Re-INVITE 200 OK 200 OK ACK ACK
- 31. Questions?