1 / 8

Explicit Subscriptions for REFER

Explicit Subscriptions for REFER. d raft-sparks-sipcore-refer-explicit-subscription-00 SIPCORE – IETF90 Robert Sparks. Proposed Plan. Today: Discuss strawman’s open questions and issues raised on list Shortly after IETF90: Flesh out strawman based on today’s discussions

aoife
Télécharger la présentation

Explicit Subscriptions for REFER

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. Explicit Subscriptions for REFER draft-sparks-sipcore-refer-explicit-subscription-00 SIPCORE – IETF90 Robert Sparks

  2. Proposed Plan • Today: Discuss strawman’s open questions and issues raised on list • Shortly after IETF90: Flesh out strawman based on today’s discussions • Process result as a SIPCORE WG document with a PubReq target of late September

  3. Summary of Strawman (so far) • Send REFER in- or out-of-dialog • Require: explicitsub • Accepting server MUST NOT create implicit subscription • Instead, returns a URI for use with SUBSCRIBE in a new Refer-Events-At: header

  4. Transfer Example Alice Bob Carol INVITE bob Contact: gruu-a dialog 1 INVITE carol 200 OK Contact: gruu-c dialog 2 REFER gruu-c Require: explicitsub Refer-To: gruu-a; replaces = dialog1 200 OK Refer-Events-At: rev-token-c dialog 3 SUBSCRIBE rev-token-c Event: refer Contact: gruu-b INVITE gruu-a Replaces: dialog 1 dialog 4 dialog 5 NOTIFY gruu-b Event: refer Subscription-State: terminated dialog 4

  5. Easy Questions from Strawman • Do we use a different method? • NO: An extension does the work and will likely be easier to deploy • Do we use a different event package? • NO : The meaning of the state and the payload delivered in NOTIFY messages does not change. • Do we further restrict what an appear in Refer-To? • NO : A UA can use the existing ability to reject REFER requests with Refer-To URIs that it doesn’t care for. • Do we deprecate RFC4488? • NO : These extensions can co-exist (but not be used together)

  6. When no subscription is wanted • REFER-er can simply ignore the Refer-Events-At header, and not subscribe if it doesn’t care about the state. • But the server has had to prepare for a subscription that may never come. • Proposal: Additional option tag ‘nosub’ telling server to not bother with those preparations

  7. Acting on an Refer-Events-At URI • Header field can contain an arbitrary URI • Could be abused to cause peer to send a subscription to a malicious place • Attack advantage is small • Only one SUBSCRIBE is going to be sent – isn’t a good amplifier for a DoS attack • All other security considerations are the same as for anymechanism through which a UA might get a URI to subscribe to • Existing mechanisms (particularly Refer-To) are more attractive

  8. Accepting an Event: refer subscription • How should the SUBSCRIBE be authorized? • Proposal: If someone knows the URI, they get to subscribe. • These URIs are necessarily short-lived and specific to the state being subscribed to. • They can be generated to be hard to guess • Getting another temp-gruu would be a good way to do this

More Related