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 INVITE Via: SIP/2.0/UDP :1212;rport INVITE Via: SIP/2.0/UDP :1212; rport=8928; received= OK Via: SIP/2.0/UDP :1212; rport=8928; received= OK Via: SIP/2.0/UDP :1212; rport=8928; received= UACProxy NAT S: :1212 S: :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 Connection then 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 Connection then REGISTER Incoming INVITE

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 Caller IP A Callee IP B NAT Private Network A->BA’->B Source = A’ B->A’ B->A A A’ binding established Sends to A’ 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: :8760 D: :5062 S: :1022 D: :5062 D: :1022 S: :5062 Body: :1022 D: :8760 S: :5062 Body: :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: :8080 D: :5064 S: :1098 D: :5064 S: :7009 D: :5064 D: :7009 S: :5064 Body: :7009 D: :1098 S: :5064 Body: :7009 D: :8080 S: :5064 Body: :7009 RTP S: :76 D: :7009 RTP S: :5064 D: :1098 RTP S: :5064 D: :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 predicts that To, From, Call-ID will be a specific value in this request And uses hash of them for nonce INV UAProxy

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