Download - Media Session Authorization
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
Alice BobFW-BFW-A
Bob's Call Controller
Alice's Call Controller
STUNRequest
2
5
INVITEFrom: AliceTo: BobIP=X, UDP=x, Token=A1
1
79
8
11
12
X, x
Alice’s Policy Server
Bob’s Policy Server
3
4
610
informational
7
ICE with Policy Authorization, Slide 2
Alice BobFW-BFW-A
13
14 16
SIP 183 or 200From: BobTo: AliceIP=Z, UDP=z, Token=B1
15
STUNResponse
Bob's Call Controller
Alice's Call Controller
No external authorization check is necessary because the same STUN
transaction-id and (flipped) 5-tuple are in STUN Request and Response
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)
Alice BobFW-B-1FW-A
Bob's Call Controller
Alice's Call Controller
STUNRequest
2
5
INVITEFrom: AliceTo: BobIP=X, UDP=x, Token=A1
1
79
8
11
12
X, x
Alice’s Policy Server
Bob’s Policy Server
3
4
610
FW-B-2
informational
11
FW-B-2
Approach A (slide 2)
Alice BobFW-B-1FW-A
Bob's Call Controller
Alice's Call Controller
Alice’s Policy Server
Bob’s Policy Server
183 or 200From: BobTo: AliceIP=Z, UDP=z, Token=B1
1317
14
15
16 18
19
Z, z
STUNResponse
informational
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
Alice BobFW-B-1FW-A
Bob's Call Controller
Alice's Call Controller
STUNRequest
2
5
INVITEFrom: AliceTo: BobIP=X, UDP=x, Token=A1
1
79
8
11
12
X, x
Alice’s Policy Server
Bob’s Policy Server
3
4
610
FW-B-2
6a
FW-B-3
FW-B-4
informational
14
FW-B-2
Solution B: Tell Firewall (slide 2)
Alice BobFW-B-1FW-A
Bob's Call Controller
Alice's Call Controller
Alice’s Policy Server
Bob’s Policy Server
183 or 200From: BobTo: AliceIP=Z, UDP=z, Token=B1
1317
14
15
16
19
STUNResponse
FW-B-2 needs no external authorization check because the same STUN transaction-id and (flipped) 5-tuple are in STUN
Request and ResponseFW-B-3
FW-B-4
FW-B-3 and FW-B-4 time out
the STUN transaction-id
aggressively (5-10 seconds)
informational
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