SIPWG Slides for IETF 51

Jonathan Rosenberg

dynamicsoft

Early Media

• Existing approach– INVITE contains offer– 18x has SDP -> early media

• Problems– Caller cannot modify media (overlapping INVITEs)

• Cannot put it on hold• Cannot turn it off• Cannot refuse it• Cannot change port (forking demux)

– People associate 183 only with early media– Requires 100rel

Constraints

• Nice to be consistent with existing practice• MUST map onto 2-phase SDP exchange

(offer/answer model)• Approach:

– Called party must offer early media (rather than just send)

– Callee must answer the offer

– Either side can generate new offers as if the call were established

Problem Space

• Which messages for offer/answer for callee->caller and reverse?– (1) 1xx/PRACK and

INV/1xx

– (2) OFFER/2xx and OFFER/2xx

– (3) INV (new leg)/2xx and INV/2xx

– (4) 1xx/PRACK and OFFER/2xx

• Issues– (1) Overlapping INV

– (2) new way to establish sessions, not consistent w/ existing use

– (3) confuses call with session, not consistent

– (4) new way to establish sessions

Proposal: Scheme 1• Callee sends offer in 1xx

– Need not be valid answer to offered SDP

• Caller sends answer in PRACK– Answer to 1xx

• Caller can re-INVITE at any time– SDP constructed as if a mid-

call re-INVITE– Callee sends 490 (prev. 489) to

first INVITE• Close transactions

– Callee sends 1xx with answer

Caller Callee | | | | |INVITE SDP A | |--------------------->| |183 SDP B | |<---------------------| |PRACK SDP A | |--------------------->| |200 PRACK | |<---------------------| |200 SDP B | |<---------------------| |decides to mute | | | |INVITE SDP C | |--------------------->| |490 (INV 1) | |<---------------------| |ACK (INV 1) | |--------------------->| |183 SDP D (INV 2) | |<---------------------| |PRACK SDP C | |--------------------->| |200 PRACK | |<---------------------| | | | |

Open Issues

• Is this the right approach?– Worth even solving?

• Other issues– Ignoring SDP in

INVITE – OK?

– Interactions with 3pcc?

– All reliable provisional responses with SDP

– SDP in 2xx answers SDP in latest PRACK – weird

• Can instead be an offer, with answer in ACK

• Can be an answer to SDP in INVITE

Via Ports

• For SIP responses to work over UDP, response must go to source IP/port of request

• Solution: Via port– Client (UAC or proxy) adds

rport Via param to request– IP/port in Via is local address

of socket request sent on– Proxy sets rport in proxied

request to source port– Proxy sends response to

received/rport params

INVITEVia: SIP/2.0/UDP 1.2.3.4:1212;rport

INVITEVia: SIP/2.0/UDP 1.2.3.4:1212; rport=8928; received=8.2.3.0

200 OKVia: SIP/2.0/UDP 1.2.3.4:1212; rport=8928; received=8.2.3.0

200 OKVia: SIP/2.0/UDP 1.2.3.4:1212; rport=8928; received=8.2.3.0

UAC Proxy

NAT

S:1.2.3.4:1212 S:8.2.3.0:8928

Binding Expiration issues

• Problem: UDP timeouts– UDP binding in NAT will

timeout– No standard timeout, often

1 minute if no activity– Long INVITE transactions

can exceed this– If proxy sends 1xx, no

messages are sent to refresh binding!

– Solution: must retransmit INVITE at period of 32s even after 1xx

• TCP is better, since bindings last much longer– Explicit FIN used by

NAT to terminate bindings

• Recommendation– Use TCP if you can,

else UDP

Translate Header

• Special header which tells registrar “rewrite this specific contact using the IP address and port where the register came from”– Register comes from persistent TCP

connection to server or from UDP using received port

– Causes calls to be routed to UAS through NAT!

• Want to be explicit about translation– Call forward service

• Translate header also indicates what type of NAT client is behind (more later)

TCP Connectionthen REGISTER

Nothing is easy…• Registration creates a binding from UA

to one specific proxy that gets REGISTER

• Symmetric NATs will only allow requests to be routed to UAC from that proxy

• Implication: bank of redundant proxies won’t work– Other proxies can’t reach UA

• Solution:– DB entry includes address of proxy that

connection is to– Use preloaded Route headers to get request

from incoming proxy to connected proxy

TCP Connectionthen REGISTER

IncomingINVITE

Symmetric RTP

• Recipient sends RTP packets back to source IP of received RTP packet– Just like TCP operation, but over

UDP

• This is Symmetric RTP• Means only one side needs to

provide IP address – just like client/server

• SDP signaling with comedia– Backwards compatible, still

RTP/AVP but w/ direction attribute

CallerIP A

CalleeIP B

NAT

Private Network

A->B A’->BSource = A’

B->A’B->A

A<->A’ bindingestablished

Sends to A’

RTP pkt

RTP pkt

NAT Detection Protocol

• Define protocol for detecting presence and type of nats, and for address allocation, without changing nats– PRE-MIDCOM!

• Detecting presence of nat– Client sends packet through NAT

to reflector– Reflector includes source IP/port

in response– Client compares local IP/port with

response: <> means NAT!

• Results in allocation of binding– Only to reflector for symmetric

case– Generally useful in full-cone case

S: 10.0.1.1:8760D:1.2.3.4:5062

S: 63.1.2.3:1022D:1.2.3.4:5062

D: 63.1.2.3:1022S:1.2.3.4:5062

Body:63.1.2.3:1022

D: 10.0.1.1:8760S:1.2.3.4:5062

Body:63.1.2.3:1022

Client NAT Reflector

NAT Type Detection• Define two types of reflectors

– Reflector A: Same as previous, but body contains IP of reflector C

– Reflector B: controlled by reflector A, sends the response to client as well

• Flow– Client sends to reflector A– Reflector A responds – A tells B to send response as well– Client acks response from B if it gets it

• Whats the point?– If client gets response from A, its behind NAT– If clients never gets B, but gets A, it’s a

symmetric NAT (because source IP of B not A)

– If client gets both A and B response, it’s a full-cone nat

Client NAT A B

ping

Your IP Send to client

Full-cone resp.

ack

Allocation for Symmetric

• Need to route media through intermediary– Use another NAT!– NAT sits in front of

reflector C• Clients allocate binding,

get public address on it• rewrites source IP of

outside->inside to look like IP of reflector

• Result: traversal of symmetric NAT

– Used before each call setup

Client Ent.NAT SP.NAT C

S:10.0.1.1:8080D:1.2.3.4:5064

S:63.1.2.3:1098D:1.2.3.4:5064

S:1.2.8.8:7009D:1.2.3.4:5064

D:1.2.8.8:7009S:1.2.3.4:5064

Body:1.2.8.8:7009

D:63.1.2.3:1098S:1.2.3.4:5064

Body:1.2.8.8:7009

D:10.0.1.1:8080S:1.2.3.4:5064

Body:1.2.8.8:7009

RTPS:9.7.2.1:76D:1.2.8.8:7009

RTPS:1.2.3.4:5064D:63.1.2.3:1098

RTPS:1.2.3.4:5064D:10.0.1.1:8080

Complete Picture• At startup, client figures out if its

behind a NAT, and what type• REGISTER is done, type of NAT

described in Translate header• Before making a call, allocate an

address– Reflector C if symmetric– Reflector B if full-cone

• Place that address in SDP• If behind full-cone, add symmetric

RTP direction of both, else if symmetric, direction of active

• Send the INVITE….

• UAS gets INVITE• Allocate an address

– Reflector C if behind symmetric NAT– Reflector B if full-cone– Nothing if not behind a NAT

• Place the address in SDP• If symmetric RTP is understood,

set direction in response– Set as passive if request indicated

active– Set as active if request indicated both

and UAS behind symmetric

• Send 200 OK

Results• Result 1: Optimal media!

– Media always goes direct if at all possible

– Only case where its to SP NAT is when both participants are behind symmetric NATs

• Result 2: backwards compatibility– If symmetric RTP isn’t

understood by recipient, call proceeds fine, but will involve SP NAT if UAC was behind symmetric NAT

• Result 3: simplicity– Proxies largely unaffected– UA changes, but its not too

complex

• Result 4: migration to midcom– The behavior is the same as

would be with midcom

• Result 5: Good Security– If reflectors are compromised

no attacks possible

• Result 6:– Follows e2e principle!

Changes to Session Timer

• Consistent with bis recoverability– Use From tags– 481 on unknown leg, followed

by BYE

• 30 min recommended min.• Reject low session timers

– 422 Session Timer Too Small– Session Expires header with

minimum value– Client remembers largest

minimum timer, always sets that in Min-SE header in request

• Proxy/UAS cannot reduce session timer below Min-SE value

• Session-Expires SHOULD be in re-INVITE, with last value– Allows for rejection

Refresher

• Added refresher parameter to Session-Expires– Indicates who is sending

refreshes– More explicit, instead of

derived from Require/Supported

• Initial INVITE– UAC can force itself to do it

by setting it to uac– UAC doesn’t care: no value– If UAC supports, UAS can set

it to uas or uac if not present in request

• Re-INVITE– Contains identity of

current refresher

– Result: no switching of roles on re-INVITE!

– Change of roles can be forced

Open Issues

• Use Min-SE in 422 instead of Session-Expires?– Proposal: Yes

• Any reason for absolute times?– The require Date header, so

you are converting to relative anyway

– Simplifies processing

– Proposal: remove

• New refresher mechanism seem good?

Predictive Nonces

• Problem– Digest is susceptible to

replay attacks• “Stealing” phones with

replayed REGISTER w/ modified Contact

• Hanging up someone elses call with BYE w/ replayed Authorization

– Digest allows one-time nonces to protect

• High cost in terms of state

• Goal– Would like to improve

digest performance

• Proposal– Compute nonces as a

hashed function of the prediction of the values of headers in the resubmitted request

• Benefits– Totally stateless replay

prevention

Example

• UA sends INV to proxy• Proxy challenges

– Proxy-Authenticate contains nonce which is a hash of predicted To, From, SDP, etc.

• Resubmitted INVITE arrives at proxy– Computes same hash,

computes nonce, uses to validate credentials

• Hash also includes “N” – number of times resubmitted

INV

407

ACK

Proxy predictsthat To, From, Call-IDwill be a specific valuein this request

And uses hashof them fornonce

INV

UA Proxy

List Discussion

• Nonce computation needs to include the private key of proxy– Agreed

• Doesn’t solve MITM attacks– Agreed

• Open Issues– Put “N” inside of hash as

well as outside• Seems reasonable

– Add timestamp• Seems reasonable

• Main one: need we do anything with this?– Needs main spec to say not

to change headers from request to resubmit

– Otherwise – implementation choice