Media Session Authorization

1

Media Session Authorization

Dan [email protected]

draft-wing-session-auth-00.txt

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



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



STUNRequest

2

5


1

79

8

11

12

X, x



3

4

610

FW-B-2

informational

11

FW-B-2

Approach A (slide 2)

Alice BobFW-B-1FW-A





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



STUNRequest

2

5


1

79

8

11

12

X, x



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





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

Media Session Authorization

Documents