SIPWG Slides for IETF 51

1
SIPWG Slides for IETF 51

• Jonathan Rosenberg
• dynamicsoft

2
Early Media

• Existing approach
• INVITE contains offer
• 18x has SDP -gt 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

3
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

4
Problem Space

• Which messages for offer/answer for
  callee-gtcaller 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

5
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

---------------------gt
183 SDP B

lt---------------------
PRACK SDP A

---------------------gt
200 PRACK
lt---------------------
200 SDP B

lt---------------------
decides to mute


INVITE SDP C

---------------------gt
490 (INV 1)

lt---------------------
ACK (INV 1)

---------------------gt
183 SDP D (INV 2)
lt---------------------
PRACK SDP C

---------------------gt
200 PRACK

lt---------------------



6
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

7
Via Ports
S1.2.3.41212
S8.2.3.08928

• 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

INVITE Via SIP/2.0/UDP 1.2.3.41212rport
INVITE Via SIP/2.0/UDP 1.2.3.41212
rport8928 received8.2.3.0
200 OK Via SIP/2.0/UDP 1.2.3.41212
rport8928 received8.2.3.0
200 OK Via SIP/2.0/UDP 1.2.3.41212
rport8928 received8.2.3.0
NAT
UAC
Proxy
8
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

9
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 Connection then REGISTER
10
Nothing is easy
Incoming INVITE

• 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 wont work
• Other proxies cant 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 Connection then REGISTER
11
Symmetric RTP
Private Network

• 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

Alt-gtA binding established
A-gtB
A-gtB
Source A
RTP pkt
B-gtA
B-gtA
Sends to A
RTP pkt
NAT
Caller IP A
Callee IP B
12
NAT Detection Protocol
S 10.0.1.18760 D1.2.3.45062
S 63.1.2.31022 D1.2.3.45062

• 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 ltgt
  means NAT!
• Results in allocation of binding
• Only to reflector for symmetric case
• Generally useful in full-cone case

D 63.1.2.31022 S1.2.3.45062 Body63.1.2.3102
2
D 10.0.1.18760 S1.2.3.45062 Body63.1.2.3102
2
Client
Reflector
NAT
13
NAT Type Detection
ping

• 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, its a
  symmetric NAT (because source IP of B not A)
• If client gets both A and B response, its a
  full-cone nat

Send to client
Your IP
Full-cone resp.
ack
Client
A
NAT
B
14
Allocation for Symmetric
S10.0.1.18080 D1.2.3.45064
S63.1.2.31098 D1.2.3.45064
S1.2.8.87009 D1.2.3.45064

• 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-gtinside to look
  like IP of reflector
• Result traversal of symmetric NAT
• Used before each call setup

D1.2.8.87009 S1.2.3.45064 Body 1.2.8.87009
D10.0.1.18080 S1.2.3.45064 Body 1.2.8.87009
D63.1.2.31098 S1.2.3.45064 Body 1.2.8.87009
RTP S9.7.2.176 D1.2.8.87009
RTP S1.2.3.45064 D10.0.1.18080
RTP S1.2.3.45064 D63.1.2.31098
Ent.NAT
SP.NAT
Client
C
15
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

16
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 isnt 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!

17
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

18
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 doesnt 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

19
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?

20
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

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

• 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

407
ACK
And uses hashof them fornonce
INV
UA
Proxy
22
List Discussion

• Nonce computation needs to include the private
  key of proxy
• Agreed
• Doesnt 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