1 / 17

Media Session Authorization

This document discusses the session authorization process for UDP media sessions using ICE and username/password authentication. It covers the use of ICE for NAT traversal, the exchange of per-flow usernames and passwords, and the secure authorization process involving SIP proxies, policy servers, and firewalls.

deweya
Download Presentation

Media Session Authorization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Media Session Authorization draft-wing-session-auth-00.txt Dan Wingdwing@cisco.com

  2. IPR Declaration • Cisco will be declaring IPR ondraft-wing-session-auth-00.txt

  3. Session Authorization Overview • Authorize UDP Media Sessions • Uses username/passwords of ICE • Authority comes from call controller • Natural packet routing • No NAT, no SBC • Allows multihomed networks • No topology awareness • No topology constraints

  4. ICE Overview • Interactive Connectivity Establishment • Useful for traversing NATs • Per-flow usernames (and passwords) are exchanged in ICE signaling • To verify connectivity, ICE endpoints send the username in media path • STUN Request / Reply (RFC3489)

  5. Media Session Authorization • Per-call username is seen by SIP proxy • SIP proxy gives policy server call info. • Firewall identifies STUN Request • Firewall asks policy server to authorize flow • Firewall opens pinhole • Result: secure authorization of a legitimate flow

  6. ICE with Policy Authorization, Slide 1 informational INVITEFrom: AliceTo: BobIP=X, UDP=x, Token=A1 Alice's Call Controller Bob's Call Controller 2 10 3 6 Alice’s Policy Server Bob’s Policy Server 1 11 9 7 5 8 4 Alice 12 Bob FW-A FW-B X, x STUNRequest

  7. ICE with Policy Authorization, Slide 2 Alice's Call Controller Bob's Call Controller SIP 183 or 200From: BobTo: AliceIP=Z, UDP=z, Token=B1 13 Alice Bob FW-A FW-B 14 15 16 No external authorization check is necessary because the same STUN transaction-id and (flipped) 5-tuple are in STUN Request and Response STUNResponse

  8. Asymmetric Routing: Problem • Firewall can’t learn about bi-directional flow, because it only sees one direction • Thus, can’t use transaction-id and 5-tuple to authorize STUN Response message Firewall-Atlanta Firewall-Dallas Gateway

  9. Asymmetric Routing: Approach A • Firewall asks policy server about STUN Responses, too • Continue using same protocol • Solution A causes additional STUN Request/Response delay

  10. Approach A (slide 1) informational INVITEFrom: AliceTo: BobIP=X, UDP=x, Token=A1 Alice's Call Controller Bob's Call Controller 2 10 3 6 Alice’s Policy Server Bob’s Policy Server 1 11 9 7 5 8 4 Alice 12 Bob FW-A FW-B-1 X, x FW-B-2 STUNRequest

  11. Approach A (slide 2) informational 183 or 200From: BobTo: AliceIP=Z, UDP=z, Token=B1 Alice's Call Controller Bob's Call Controller 13 17 Alice’s Policy Server Bob’s Policy Server 16 18 14 Alice Bob FW-A FW-B-1 Z, z 15 19 FW-B-2 STUNResponse

  12. Asymmetric Routing: Approach B • Tell other firewalls about every valid STUN transaction-id • Example: secure multicast protocol (GDOI?) • Optimization 1: tell firewalls that might need to know (but how do you know?) • Optimization 2: firewalls only need to remember authorized STUN transaction-id for a short time (5-10 seconds) • Solution B adds more state to firewalls

  13. Approach B informational INVITEFrom: AliceTo: BobIP=X, UDP=x, Token=A1 Alice's Call Controller Bob's Call Controller 2 10 3 6 Alice’s Policy Server Bob’s Policy Server 1 6a 11 9 7 5 8 4 Alice 12 Bob FW-A FW-B-1 X, x FW-B-2 FW-B-3 FW-B-4 STUNRequest

  14. Solution B: Tell Firewall (slide 2) 183 or 200From: BobTo: AliceIP=Z, UDP=z, Token=B1 Alice's Call Controller Bob's Call Controller 13 17 Alice’s Policy Server Bob’s Policy Server informational 16 14 Alice Bob FW-A FW-B-1 15 19 FW-B-2 FW-B-3 and FW-B-4 time out the STUN transaction-id aggressively (5-10 seconds) FW-B-2 needs no external authorization check because the same STUN transaction-id and (flipped) 5-tuple are in STUN Request and Response FW-B-3 FW-B-4 STUNResponse

  15. Features • No topology awareness • Supports multi-homed networks • Including asymmetric routing

  16. Drawbacks • Endpoints must cooperate in the scheme • ICE-capable endpoints cooperate as a side-effect of their normal ICE operation • Note well: Only a portion of ICE is needed -- only the exchange of tokens in signaling and the STUN Request/Response in media

  17. Going Forward • Standardize interfaces • SIP proxy to Policy Server • Policy Server to Firewall • Decide on approach A or B for multihomed asymmetric routing

More Related