1 / 22

SIPWG Slides for IETF 51

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

coxf
Download Presentation

SIPWG Slides for IETF 51

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SIPWG Slides for IETF 51 Jonathan Rosenberg dynamicsoft

  2. 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

  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. 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 Problem Space

  5. 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 Proposal: Scheme 1 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 | |<---------------------| | | | |

  6. 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 Open Issues

  7. 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 Via Ports S:1.2.3.4:1212 S:8.2.3.0:8928 INVITE Via: SIP/2.0/UDP 1.2.3.4:1212;rport INVITE Via: SIP/2.0/UDP 1.2.3.4:1212; rport=8928; received=8.2.3.0 200 OK Via: SIP/2.0/UDP 1.2.3.4:1212; rport=8928; received=8.2.3.0 200 OK Via: SIP/2.0/UDP 1.2.3.4:1212; rport=8928; received=8.2.3.0 NAT UAC Proxy

  8. 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 Binding Expiration issues

  9. 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) Translate Header TCP Connection then REGISTER

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

  11. 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 Symmetric RTP Private Network A<->A’ binding established A->B A’->B Source = A’ RTP pkt B->A B->A’ Sends to A’ RTP pkt NAT Callee IP B Caller IP A

  12. 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 NAT Detection Protocol S: 10.0.1.1:8760 D:1.2.3.4:5062 S: 63.1.2.3:1022 D:1.2.3.4:5062 D: 10.0.1.1:8760 S:1.2.3.4:5062 Body:63.1.2.3:1022 D: 63.1.2.3:1022 S:1.2.3.4:5062 Body:63.1.2.3:1022 Client Reflector NAT

  13. 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 NAT Type Detection ping Send to client Your IP Full-cone resp. ack Client A NAT B

  14. 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 Allocation for Symmetric S:10.0.1.1:8080 D:1.2.3.4:5064 S:63.1.2.3:1098 D:1.2.3.4:5064 S:1.2.8.8:7009 D:1.2.3.4:5064 D:1.2.8.8:7009 S:1.2.3.4:5064 Body: 1.2.8.8:7009 D:10.0.1.1:8080 S:1.2.3.4:5064 Body: 1.2.8.8:7009 D:63.1.2.3:1098 S:1.2.3.4:5064 Body: 1.2.8.8:7009 RTP S:9.7.2.1:76 D:1.2.8.8:7009 RTP S:1.2.3.4:5064 D:10.0.1.1:8080 RTP S:1.2.3.4:5064 D:63.1.2.3:1098 Ent.NAT SP.NAT Client C

  15. 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 Complete Picture

  16. 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! Results

  17. 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 Changes to Session Timer

  18. 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 Refresher

  19. 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? Open Issues

  20. 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 Predictive Nonces

  21. 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 Example INV Proxy predictsthat To, From, Call-IDwill be a specific valuein this request 407 ACK And uses hashof them fornonce INV UA Proxy

  22. 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 List Discussion

More Related