idnits 2.17.1
draft-ietf-simple-winfo-package-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The "Author's Address" (or "Authors' Addresses") section title is
misspelled.
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (January 31, 2003) is 7753 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 3265 (ref. '1') (Obsoleted by RFC 6665)
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force SIMPLE WG
3 Internet Draft J. Rosenberg
4 dynamicsoft
5 draft-ietf-simple-winfo-package-05.txt
6 January 31, 2003
7 Expires: July 2003
9 A Watcher Information Event Template-Package for
10 the Session Initiation Protocol (SIP)
12 STATUS OF THIS MEMO
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress".
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt
30 To view the list Internet-Draft Shadow Directories, see
31 http://www.ietf.org/shadow.html.
33 Abstract
35 This document defines the watcher information template-package for
36 the SIP event framework. Watcher information refers to the set of
37 users subscribed to a particular resource within a particular event
38 package. Watcher information changes dynamically as users subscribe,
39 unsubscribe, are approved, or are rejected. A user can subscribe to
40 this information, and therefore learn about changes to it. This event
41 package is a template-package because it can be applied to any event
42 package, including itself.
44 Table of Contents
46 1 Introduction ........................................ 3
47 2 Terminology ......................................... 3
48 3 Usage Scenarios ..................................... 4
49 3.1 Presence Authorization .............................. 4
50 3.2 Blacklist Alerts .................................... 5
51 4 Package Definition .................................. 5
52 4.1 Event Package Name .................................. 5
53 4.2 Event Package Parameters ............................ 6
54 4.3 SUBSCRIBE Bodies .................................... 6
55 4.4 Subscription Duration ............................... 6
56 4.5 NOTIFY Bodies ....................................... 7
57 4.6 Notifier Processing of SUBSCRIBE Requests ........... 7
58 4.7 Notifier Generation of NOTIFY Requests .............. 8
59 4.7.1 The Subscription State Machine ...................... 8
60 4.7.2 Applying the State Machine .......................... 11
61 4.8 Subscriber Processing of NOTIFY Requests ............ 12
62 4.9 Handling of Forked Requests ......................... 12
63 4.10 Rate of Notifications ............................... 13
64 4.11 State Agents ........................................ 13
65 5 Example Usage ....................................... 13
66 6 Security Considerations ............................. 16
67 6.1 Denial of Service Attacks ........................... 16
68 6.2 Divulging Sensitive Information ..................... 17
69 7 IANA Considerations ................................. 17
70 8 Acknowledgements .................................... 18
71 9 Authors Addresses ................................... 18
72 10 Normative References ................................ 18
73 11 Informative References .............................. 18
75 1 Introduction
77 The SIP event framework is described in RFC 3265 [1]. It defines a
78 generic framework for subscription to, and notification of, events
79 related to SIP systems. The framework defines the methods SUBSCRIBE
80 and NOTIFY, and introduces the notion of a package. A package is a
81 concrete application of the event framework to a particular class of
82 events. Packages have been defined for user presence [5], for
83 example.
85 This draft defines a "template-package" within the SIP event
86 framework. A template-package has all the properties of a regular SIP
87 event package. However, it is always associated with some other event
88 package, and can always be applied to any event package, including
89 the template-package itself.
91 The template-package defined here is for watcher information, and is
92 denoted with the token "winfo". For any event package, such as
93 presence, there exists a set (perhaps an empty set) of subscriptions
94 that have been created or requested by users trying to ascertain the
95 state of a resource in that package. This set of subscriptions
96 changes over time as new subscriptions are requested by users, old
97 subscriptions expire, and subscriptions are approved or rejected by
98 the owners of that resource. The set of users subscribed to a
99 particular resource for a specific event package, and the state of
100 their subscriptions, is referred to as watcher information. Since
101 this state is itself dynamic, it is reasonable to subscribe to it in
102 order to learn about changes to it. The watcher information event
103 template-package is meant to facilitate exactly that - tracking the
104 state of subscriptions to a resource in another package.
106 To denote this template-package, the name is constructed by appending
107 ".winfo" to the name of whatever package is being tracked. For
108 example, the set of people subscribed to presence is defined by the
109 "presence.winfo" package.
111 2 Terminology
113 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
115 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
116 indicate requirement levels for compliant implementations.
118 This document fundamentally deals with recursion - subscriptions to
119 subscriptions. Therefore, the term "subscription" itself can be
120 confusing in this document. To reduce confusion, the term
121 "watcherinfo subscription" refers to a subscription to watcher
122 information, and the term "watcherinfo subscriber" refers to a user
123 that has subscribed to watcher information. The term "watcherinfo
124 notification" refers to a NOTIFY request sent as part of a
125 watcherinfo subscription. When the terms "subscription",
126 "subscriber", and "notification" are used unqualified, they refer to
127 the "inner" subscribers, subscriptions, and notifications - those
128 that are being monitored through the watcherinfo subscriptions. We
129 also use the term "watcher" to refer to a subscriber to the "inner"
130 resource. Information on watchers is reported through watcherinfo
131 subscriptions.
133 3 Usage Scenarios
135 There are many useful applications for the watcher information
136 template-package.
138 3.1 Presence Authorization
140 The motivating application for this package is presence
141 authorization. When user A subscribes to the presence of user B, the
142 subscription needs to be authorized. Frequently, that authorization
143 needs to occur through direct user intervention. For that to happen,
144 B's software needs to become aware that a presence subscription has
145 been requested. This is supported through watcher information. B's
146 client software would SUBSCRIBE to the watcher information for the
147 presence of B:
149 SUBSCRIBE sip:B@example.com SIP/2.0
150 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
151 From: sip:B@example.com;tag=123s8a
152 To: sip:B@example.com
153 Call-ID: 9987@pc34.example.com
154 Max-Forwards: 70
155 CSeq: 9887 SUBSCRIBE
156 Contact: sip:B@pc34.example.com
157 Event: presence.winfo
159 The policy of the server is such that it allows B to subscribe to its
160 own watcher information. So, when A subscribes to B's presence, B
161 gets a notification of the change in watcher information state:
163 NOTIFY sip:B@pc34.example.com SIP/2.0
164 Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna66g
165 From: sip:B@example.com;tag=xyz887
166 To: sip:B@example.com;tag=123s8a
167 Call-ID: 9987@pc34.example.com
168 Max-Forwards: 70
169 CSeq: 1288 NOTIFY
170 Contact: sip:B@server.example.com
171 Event: presence.winfo
172 Content-Type: application/watcherinfo+xml
173 Content-Length: ...
175
176
178
179 sip:A@example.com
181
182
184 This indicates to B that A has subscribed, and that the subscription
185 is pending (meaning, it is awaiting authorization). B's software can
186 alert B that this subscription is awaiting authorization. B can then
187 set policy for that subscription.
189 3.2 Blacklist Alerts
191 Applications can subscribe to watcher information in order to provide
192 value-added features. An example application is "blacklist alerts".
193 In this scenario, an application server maintains a list of known
194 "bad guys". A user, Joe, signs up for service with the application
195 provider, presumably by going to a web page and entering in his
196 presence URI. The application server subscribes to the watcher
197 information for Joe's presence. When someone attempts to SUBSCRIBE to
198 Joe's user presence, the application learns of this subscription as a
199 result of its watcher info subscription. It checks the watcher's URI
200 against the database of known bad guys. If there is a match, it sends
201 email to Joe letting him know about this.
203 For this application to work, Joe needs to make sure that the
204 application is allowed to subscribe to his presence.winfo.
206 4 Package Definition
208 This section fills in the details needed to specify an event package
209 as defined in Section 4.4 of RFC 3265 [1].
211 4.1 Event Package Name
212 RFC 3265 [1] requires package definitions to specify the name of
213 their package or template-package.
215 The name of this template-package is "winfo". It can be applied to
216 any other package. Watcher information for any package foo is denoted
217 by the name "foo.winfo". Recursive template-packaging is explicitly
218 allowed (and useful), so that "foo.winfo.winfo" is a valid package
219 name.
221 4.2 Event Package Parameters
223 RFC 3265 [1] requires package and template-package definitions to
224 specify any package specific parameters of the Event header field.
226 No package specific Event header field parameters are defined for
227 this event template-package.
229 4.3 SUBSCRIBE Bodies
231 RFC 3265 [1] requires package or template-package definitions to
232 define the usage, if any, of bodies in SUBSCRIBE requests.
234 A SUBSCRIBE request for watcher information MAY contain a body. This
235 body would serve the purpose of filtering the watcherinfo
236 subscription. The definition of such a body is outside the scope of
237 this specification. For example, in the case of presence, the body
238 might indicate that notifications should contain full state every
239 time something changes, and that the time the subscription was first
240 made should not be included in the watcherinfo notifications.
242 A SUBSCRIBE request for a watcher information package MAY be sent
243 without a body. This implies the default watcherinfo subscription
244 filtering policy has been requested. The default policy is:
246 o Watcherinfo notifications are generated every time there is
247 any change in the state of the watcher information.
249 o Watcherinfo notifications triggered from a SUBSCRIBE contain
250 full state (the list of all watchers that the watcherinfo
251 subscriber is permitted to know about). Watcherinfo
252 notifications triggered from a change in watcher state only
253 contain information on the watcher whose state has changed.
255 Of course, the server can apply any policy it likes to the
256 subscription.
258 4.4 Subscription Duration
259 RFC 3265 [1] requires package definitions to define a default value
260 for subscription durations, and to discuss reasonable choices for
261 durations when they are explicitly specified.
263 Watcher information changes as users subscribe to a particular
264 resource for some package, or their subscriptions time out. As a
265 result, the state of watcher information can change very dynamically,
266 depending on the number of subscribers for a particular resource in a
267 given package. The rate at which subscriptions time out depends on
268 how long a user maintains its subscription. Typically, watcherinfo
269 subscriptions will be timed to span the lifetime of the subscriptions
270 being watcher, and therefore range from minutes to days.
272 As a result of these factors, it is difficult to define a broadly
273 useful default value for the lifetime of a watcherinfo subscription.
274 We arbitrarily choose one hour. However, clients SHOULD use an
275 Expires header field to specify their preferred duration.
277 4.5 NOTIFY Bodies
279 RFC 3265 [1] requires package definitions to describe the allowed set
280 of body types in NOTIFY requests, and to specify the default value to
281 be used when there is no Accept header field in the SUBSCRIBE
282 request.
284 The body of the watcherinfo notification contains a watcher
285 information document. This document describes some or all of the
286 watchers for a given package, and the state of their subscriptions.
287 All watcherinfo subscribers and notifiers MUST support the
288 application/watcherinfo+xml format described in [3], and MUST list
289 its MIME type, application/watcherinfo+xml, in any Accept header
290 field present in the SUBSCRIBE request.
292 Other watcher information formats might be defined in the future. In
293 that case, the watcherinfo subscriptions MAY indicate support for
294 other formats. However, they MUST always support and list
295 application/watcherinfo+xml as an allowed format.
297 Of course, the watcherinfo notifications generated by the server MUST
298 be in one of the formats specified in the Accept header field in the
299 SUBSCRIBE request. If no Accept header field was present, the
300 notifications MUST use the application/watcherinfo+xml format
301 described in [3].
303 4.6 Notifier Processing of SUBSCRIBE Requests
305 RFC 3265 [1] specifies that packages should define any package-
306 specific processing of SUBSCRIBE requests at a notifier, specifically
307 with regards to authentication and authorization.
309 The watcher information for a particular package contains sensitive
310 information. Therefore, all watcherinfo subscriptions SHOULD be
311 authenticated and then authorized before approval. Authentication MAY
312 be performed using any of the techniques available through SIP,
313 including digest, S/MIME, TLS or other transport specific mechanisms
314 [4]. Authorization policy is at the discretion of the administrator,
315 as always. However, a few recommendations can be made.
317 It is RECOMMENDED that user A be allowed to subscribe to their own
318 watcher information for any package. This is true recursively, so
319 that it is RECOMMENDED that a user be able to subscribe to the
320 watcher information for their watcher information for any package.
322 It is RECOMMENDED that watcherinfo subscriptions for some package foo
323 for user A be allowed from some other user B, if B is an authorized
324 subscriber to A within the package foo. However, it is RECOMMENDED
325 that the watcherinfo notifications sent to B only contain the state
326 of B's own subscription. In other words, it is RECOMMENDED that a
327 user be allowed to monitor the state of their own subscription.
329 To avoid infinite recursion of authorization policy, it is
330 RECOMMENDED that only user A be allowed to subscribe to
331 foo.winfo.winfo for user A, for any foo. It is also RECOMMENDED that
332 by default, a server does not authorize any subscriptions to
333 foo.winfo.winfo.winfo or any other deeper recursions.
335 4.7 Notifier Generation of NOTIFY Requests
337 The SIP Event framework requests that packages specify the conditions
338 under which notifications are sent for that package, and how such
339 notifications are constructed.
341 Watcherinfo notifications MAY be generated for watcher information on
342 package foo, when the subscription state for a user on package foo
343 changes. The watcher information package therefore needs a model of
344 subscription state. This is accomplished by specifying a subscription
345 Fine State Machine (FSM), described below, which governs the
346 subscription state of a user in any package. Watcherinfo
347 notifications MAY be generated on transitions in this state machine.
348 Its important to note that this FSM is just a model of the
349 subscription state machinery maintained by a server. An
350 implementation would map its own state machines to this one in an
351 implementation-specific manner.
353 4.7.1 The Subscription State Machine
354 The underlying state machine for a subscription is shown in Figure 1.
355 It derives almost entirely from the descriptions in RFC 3265 [1], but
356 adds the notion of a waiting state.
358 Initially, there is no state allocated for a subscription (the init
359 state). When a SUBSCRIBE request arrives, the subscription FSM is
360 created. The next state depends on whether policy exists for the
361 subscription. If there is an existing policy that determines that the
362 subscription is forbidden, it moves into the terminated state
363 immediately, where the FSM can be destroyed. If there is existing
364 policy that determines that the subscription is authorized, the FSM
365 moves into the active state. This state indicates that the subscriber
366 will receive notifications.
368 If, when a subscription arrives, there is no authorization policy in
369 existence, the subscription moves into the pending state. In this
370 state, the server is awaiting an authorization decision. No
371 notifications are generated on changes in presence state (an initial
372 NOTIFY will have been delivered as per RFC 3265 [1]), but the
373 subscription FSM is maintained. If the authorization decision comes
374 back positive, the subscription is approved, and moves into the
375 active state. If the authorization is negative, the subscription is
376 rejected, and the FSM goes into the terminated state. It is possible
377 that the authorization decision can take a very long time. In fact,
378 no authorization decision may arrive until after the subscription
379 itself expires. If a pending subscription suffers a timeout, it moves
380 into the waiting state. At any time, the server can decide to end a
381 pending or waiting subscription because it is concerned about
382 allocating memory and CPU resources to unauthorized subscription
383 state. If this happens, a "giveup" event is generated by the server,
384 moving the subscription to terminated.
386 The waiting state is similar to pending, in that no notifications are
387 generated. However, if the subscription is approved or denied, the
388 FSM is destroyed. The purpose of the waiting state is so that a user
389 can fetch watcherinfo state at any time, and learn of any
390 subscriptions that arrived previously (and which may arrive again)
391 which require an authorization decision. Consider an example. A
392 subscribes to B. B has not defined policy about this subscription, so
393 it moves into the pending state. B is not "online", so that B's
394 software agent cannot be contacted to approve the subscription. The
395 subscription expires. Let's say it were destroyed. B logs in, and
396 fetches its watcherinfo state. There is no record of the subscription
397 from A, so no policy decision is made about subscriptions from A. B
398 logs off. A refreshes its subscription. Once more, the subscription
399 is pending since no policy is defined for it. This process could
400 continue indefinitely. The waiting state ensures that B can find out
401 subscribe,
402 policy= +----------+
403 reject | |<------------------------+
404 +------------>|terminated|<---------+ |
405 | | | | |
406 | | | |noresource |
407 | +----------+ |rejected |
408 | ^noresource |deactivated |
409 | |rejected |probation |
410 | |deactivated |timeout |noresource
411 | |probation | |rejected
412 | |giveup | |giveup
413 | | | |approved
414 +-------+ +-------+ +-------+ |
415 | |subscribe| |approved| | |
416 | init |-------->|pending|------->|active | |
417 | |no policy| | | | |
418 | | | | | | |
419 +-------+ +-------+ +-------+ |
420 | | ^ ^ |
421 | subscribe, | | | |
422 +-----------------------------------+ |
423 policy = accept | | +-------+ |
424 | |subscribe | | |
425 | +----------|waiting|----------+
426 +----------->| |
427 timeout | |
428 +-------+
430 Figure 1: Subscription State Machine
432 about this subscription attempt.
434 The waiting state is also needed to allow for authorization of fetch
435 attempts, which are subscriptions that expire immediately.
437 Of course, policy may never be specified for the subscription. As a
438 result, the server can generate a giveup event to move the waiting
439 subscription to the terminated state. The amount of time to wait
440 before issuing a giveup event is system dependent. If, while in the
441 waiting state, the subscription is refreshed through another
442 SUBSCRIBE, it moves back into the pending state.
444 The giveup event is generated in either the waiting or pending states
445 to destroy resources associated with unauthorized subscriptions.
446 Servers need to exercise care in selecting this value. It needs to be
447 large in order to provide a useful user experience; a user should be
448 able to log in days later and see that someone tried to subscribe to
449 them. However, allocating state to unauthorized subscriptions can be
450 used as a source of DoS attacks. Therefore, it is RECOMMENDED that
451 servers which retain state for unauthorized subscriptions add
452 policies which prohibit a particular subscriber from having more than
453 some number of pending or waiting subscriptions.
455 At any time, the server can deactivate a subscription. Deactivation
456 implies that the subscription is discarded without a change in
457 authorization policy. This may be done in order to trigger refreshes
458 of subscriptions for a graceful shutdown or subscription migration
459 operation. A related event is probation, where a subscription is
460 terminated, and the subscriber is requested to wait some amount of
461 time before trying again. The meaning of these events is described in
462 more detail in Section 3.2.4 of RFC 3265 [1].
464 A subscription can be terminated at any time because the resource
465 associated with that subscription no longer exists. This corresponds
466 to the noresource event.
468 4.7.2 Applying the State Machine
470 The server MAY generate a notification to watcherinfo subscribers on
471 a transition of the state machine. Whether it does or not is policy
472 dependent. However, several guidelines are defined.
474 Consider some event package foo. A subscribes to B for events within
475 that package. A also subscribes to foo.winfo for B. In this scenario
476 (where the subscriber to foo.winfo is also a subscriber to foo for
477 the same resource), it is RECOMMENDED that A receive watcherinfo
478 notifications only about the changes in its own subscription.
479 Normally, A will receive notifications about changes in its
480 subscription to foo through the Subscription-State header field. This
481 will frequently obviate the need for a separate subscription to
482 foo.winfo. However, if such a subscription is performed by A, the
483 foo.winfo notifications SHOULD NOT report any state changes which
484 would not be reported (because of authorization policy) in the
485 Subscription-State header field in notifications on foo.
487 As a general rule, when a watcherinfo subscriber is authorized to
488 receive watcherinfo notifications about more than one watcher, it is
489 RECOMMENDED that watcherinfo notifications contain information about
490 those watchers which have changed state (and thus triggered a
491 notification), instead of delivering the current state of every
492 watcher in every watcherinfo notification. However, watcherinfo
493 notifications triggered as a result of a fetch operation (a SUBSCRIBE
494 with Expires of 0) SHOULD result in the full state of all watchers
495 (of course, only those watchers that have been authorized to be
496 divulged to the watcherinfo subscriber) to be present in the NOTIFY.
498 4.8 Subscriber Processing of NOTIFY Requests
500 RFC 3265 [1] expects packages to specify how a subscriber processes
501 NOTIFY requests in any package specific ways, and in particular, how
502 it uses the NOTIFY requests to contruct a coherent view of the state
503 of the subscribed resource. Typically, the watcherinfo NOTIFY will
504 only contain information about those watchers whose state has
505 changed. To construct a coherent view of the total state of all
506 watchers, a watcherinfo subscriber will need to combine NOTIFYs
507 received over time. This details of this process depend on the
508 document format. See [3] for details on the
509 application/watcherinfo+xml format.
511 4.9 Handling of Forked Requests
513 The SIP Events framework mandates that packages indicate whether or
514 not forked SUBSCRIBE requests can install multiple subscriptions.
516 When a user wishes to obtain watcher information for some resource
517 for package foo, the SUBSCRIBE to the watcher information will need
518 to reach a collection of servers that have, unioned together,
519 complete information about all watchers on that resource for package
520 foo. If there are a multiplicity of servers handling subscriptions
521 for that resource for package foo (for load balancing reasons,
522 typically), it is very likely that no single server will have the
523 complete set of watcher information. There are several solutions in
524 this case. This specification does not mandate a particular one, nor
525 does it rule out others. It merely ensures that a broad range of
526 solutions can be built.
528 One solution is to use forking. The system can be designed so that a
529 SUBSCRIBE for watcher information arrives at a special proxy which is
530 aware of the requirements for watcher information. This proxy would
531 fork the SUBCRIBE request to all of the servers which could possibly
532 maintain subscriptions for that resource for that package. Each of
533 these servers, whether or not they have any current subscribers for
534 that resource, would accept the watcherinfo subscription. Each needs
535 to accept because they may all eventually receive a subscription for
536 that resource. The watcherinfo subscriber would receive some number
537 of watcherinfo NOTIFY requests, each of which establishes a separate
538 dialog. By aggregating the information across each dialog, the
539 watcherinfo subscriber can compute full watcherinfo state. In many
540 cases, a particular dialog might never generate any watcherinfo
541 notifications; this would happen if the servers never receive any
542 subscriptions for the resource.
544 In order for such a system to be built in an interoperable fashion,
545 all watcherinfo subscribers MUST be prepared to install multiple
546 subscriptions as a result of a multiplicity of NOTIFY messages in
547 response to a single SUSCRIBE.
549 Another approach for handling the server multiplicity problem is to
550 use state agents. See Section 4.11 for details.
552 4.10 Rate of Notifications
554 RFC 3265 [1] mandates that packages define a maximum rate of
555 notifications for their package.
557 For reasons of congestion control, it is important that the rate of
558 notifications not become excessive. As a result, it is RECOMMENDED
559 that the server not generate watcherinfo notifications for a single
560 watcherinfo subscriber at a rate faster than once every 5 seconds.
562 4.11 State Agents
564 RFC 3265 [1] asks packages to consider the role of state agents in
565 their design.
567 State agents play an important role in this package. As discussed in
568 Section 4.9, there may be a multiplicity of servers sharing the load
569 of subscriptions for a particular package. A watcherinfo subscription
570 might require subscription state spread across all of those servers.
571 To handle that, a farm of state agents can be used. Each of these
572 state agents would know the entire watcherinfo state for some set of
573 resources. The means by which the state agents would determine the
574 full watcherinfo state is outside the scope of this specification.
575 When a watcherinfo subscription is received, it would be routed to a
576 state agent that has the full watcherinfo state for the requested
577 resource. This server would accept the watcherinfo subscription
578 (assuming it was authorized, of course), and generate watcherinfo
579 notifications as the watcherinfo state changed. The watcherinfo
580 subscriber would only have a single dialog in this case.
582 5 Example Usage
584 The following section discusses an example application and call flows
585 using the watcherinfo package.
587 In this example, a user Joe, sip:joe@example.com provides presence
588 through the example.com presence server. Joe subscribes to his own
589 watcher information, in order to learn about people who subscribe to
590 his presence, so that he can approve or reject their subscriptions.
591 Joe sends the following SUBSCRIBE request:
593 SUBSCRIBE sip:joe@example.com SIP/2.0
594 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
595 From: sip:joe@example.com;tag=123aa9
596 To: sip:joe@example.com
597 Call-ID: 9987@pc34.example.com
598 CSeq: 9887 SUBSCRIBE
599 Contact: sip:joe@pc34.example.com
600 Event: presence.winfo
601 Max-Forwards: 70
603 The server responds with a 401 to authenticate, and Joe resubmits the
604 SUBSCRIBE with credentials (message not shown). The server then
605 authorizes the subscription, since it allows Joe to subscribe to his
606 own watcher information for presence. It responds with a 200 OK:
608 SIP/2.0 200 OK
609 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8
610 ;received=192.0.2.8
611 From: sip:joe@example.com;tag=123aa9
612 To: sip:joe@example.com;tag=xyzygg
613 Call-ID: 9987@pc34.example.com
614 CSeq: 9988 SUBSCRIBE
615 Contact: sip:server19.example.com
616 Expires: 3600
617 Event: presence.winfo
619 The server then sends a NOTIFY with the current state of
620 presence.winfo for joe@example.com:
622 NOTIFY sip:joe@pc34.example.com SIP/2.0
623 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
624 From: sip:joe@example.com;tag=xyzygg
625 To: sip:joe@example.com;tag=123aa9
626 Call-ID: 9987@pc34.example.com
627 CSeq: 1288 NOTIFY
628 Contact: sip:server19.example.com
629 Event: presence.winfo
630 Max-Forwards: 70
631 Content-Type: application/watcherinfo+xml
632 Content-Length: ...
634
635
637
638 sip:A@example.com
640
641
643 Joe then responds with a 200 OK to the NOTIFY:
645 SIP/2.0 200 OK
646 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
647 ;received=192.0.2.7
648 From: sip:joe@example.com;tag=xyzygg
649 To: sip:joe@example.com;tag=123aa9
650 Call-ID: 9987@pc34.example.com
651 CSeq: 1288 NOTIFY
653 The NOTIFY tells Joe that user A currently has a pending
654 subscription. Joe then authorizes A's subscription through some
655 means. This causes a change in the status of the subscription (which
656 moves from pending to active), and the delivery of another
657 notification:
659 NOTIFY sip:joe@pc34.example.com SIP/2.0
660 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
661 From: sip:joe@example.com;tag=xyzygg
662 To: sip:joe@example.com;tag=123aa9
663 Call-ID: 9987@pc34.example.com
664 CSeq: 1289 NOTIFY
665 Contact: sip:server19.example.com
666 Event: presence.winfo
667 Max-Forwards: 70
668 Content-Type: application/watcherinfo+xml
669 Content-Length: ...
671
672
674
675 sip:A@example.com
677
678
680 B then responds with a 200 OK to the NOTIFY:
682 SIP/2.0 200 OK
683 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
684 ;received=192.0.2.7
685 From: sip:joe@example.com;tag=xyzygg
686 To: sip:joe@example.com;tag=123aa9
687 Call-ID: 9987@pc34.example.com
688 CSeq: 1289 NOTIFY
690 6 Security Considerations
692 6.1 Denial of Service Attacks
694 Watcher information generates notifications about changes in the
695 state of watchers for a particular resource. It is possible for a
696 single resource to have many watchers, resulting in the possibility
697 of a large volume of notifications. This makes watcherinfo
698 subscription a potential tool for denial of service attacks.
699 Preventing these can be done through a combination of sensible
700 authorization policies and good operating principles.
702 Firstly, when a resource has a lot of watchers, watcherinfo
703 subscriptions to that resource should only be allowed from explicitly
704 authorized entities, whose identity has been properly authenticated.
705 That prevents a watcherinfo NOTIFY stream from being generated from
706 subscriptions made by an attacker.
708 Even when watcherinfo subscriptions are properly authenticated, there
709 are still potential attacks. For example, consider a valid user, T,
710 who is to be the target of an attack. T has subscribed to their own
711 watcher information. The attacker generates a large number of
712 subscriptions (not watcherinfo subscriptions). If the server creates
713 subscription state for unauthenticated subscriptions, and reports
714 those changes in watcherinfo notifications, user T would receive a
715 flood of watcherinfo notifications. In fact, if the server generates
716 a watcherinfo notification when the subscription is created, and
717 another when it is terminated, there will be an amplification by a
718 factor of two. The amplification would actually be substantial if the
719 server generates full state in each watcherinfo notification. Indeed,
720 the amount of data sent to T would be the square of the data
721 generated by the attacker! Each of the N subscriptions generated by
722 the attacker would result in a watcherinfo NOTIFY being sent to T,
723 each of which would report on up to N watchers. To avoid this,
724 servers should never generate subscription state for unauthenticated
725 SUBSCRIBE requests, and should never generate watcherinfo
726 notifications for them either.
728 6.2 Divulging Sensitive Information
730 Watcher information indicates what users are interested in a
731 particular resource. Depending on the package and the resource, this
732 can be very sensitive information. For example, in the case of
733 presence, the watcher information for some user represents the
734 friends, family, and business relations of that person. This
735 information can be used for a variety of malicious purposes.
737 One way in which this information can be revealed is eavesdropping.
738 An attacker can observe watcherinfo notifications, and learn this
739 information. To prevent that, watchers MAY use the SIPS scheme when
740 subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST
741 support TLS and SIPS as if they were a proxy (see Section 26.3.1 of
742 RFC 3261).
744 SIP encryption, using S/MIME, MAY be used end-to-end for the
745 transmission of both SUBSCRIBE and NOTIFY requests.
747 Another way in which this information can be revealed is through
748 spoofed subscriptions. These attacks can be prevented by
749 authenticating and authorizing all watcherinfo subscriptions. In
750 order for the notifier to authenticate the subscriber, it MAY use
751 HTTP Digest (Section 22 of RFC 3261). As a result, all watchers MUST
752 support HTTP Digest. This is a redundant requirement, however, since
753 all SIP user agents are mandated to support it by RFC 3261.
755 7 IANA Considerations
757 This specification registers an event template package as specified
758 in Section 6.2 of RFC 3265 [1].
760 Package Name: winfo
762 Template Package: yes
764 Published Specification: RFC XXXX (Note to IANA: Please replace
765 XXXX with the RFC number of this specification.)
767 Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
769 8 Acknowledgements
771 The authors would like to thank Adam Roach, Allison Mankin and Brian
772 Stucker for their detailed comments.
774 9 Authors Addresses
776 Jonathan Rosenberg
777 dynamicsoft
778 72 Eagle Rock Avenue
779 First Floor
780 East Hanover, NJ 07936
781 email: jdrosen@dynamicsoft.com
783 10 Normative References
785 [1] A. B. Roach, "Session initiation protocol (sip)-specific event
786 notification," RFC 3265, Internet Engineering Task Force, June 2002.
788 [2] S. Bradner, "Key words for use in rfcs to indicate requirement
789 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
791 [3] J. Rosenberg, "An extensible markup language (XML) based format
792 for watcher information," internet draft, Internet Engineering Task
793 Force, Dec. 2002. Work in progress.
795 [4] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
796 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
797 initiation protocol," RFC 3261, Internet Engineering Task Force, June
798 2002.
800 11 Informative References
802 [5] J. Rosenberg, "A presence event package for the session
803 initiation protocol (SIP)," internet draft, Internet Engineering Task
804 Force, Dec. 2002. Work in progress.
806 Intellectual Property Statement
808 The IETF takes no position regarding the validity or scope of any
809 intellectual property or other rights that might be claimed to
810 pertain to the implementation or use of the technology described in
811 this document or the extent to which any license under such rights
812 might or might not be available; neither does it represent that it
813 has made any effort to identify any such rights. Information on the
814 IETF's procedures with respect to rights in standards-track and
815 standards-related documentation can be found in BCP-11. Copies of
816 claims of rights made available for publication and any assurances of
817 licenses to be made available, or the result of an attempt made to
818 obtain a general license or permission for the use of such
819 proprietary rights by implementors or users of this specification can
820 be obtained from the IETF Secretariat.
822 The IETF invites any interested party to bring to its attention any
823 copyrights, patents or patent applications, or other proprietary
824 rights which may cover technology that may be required to practice
825 this standard. Please address the information to the IETF Executive
826 Director.
828 Full Copyright Statement
830 Copyright (c) The Internet Society (2003). All Rights Reserved.
832 This document and translations of it may be copied and furnished to
833 others, and derivative works that comment on or otherwise explain it
834 or assist in its implementation may be prepared, copied, published
835 and distributed, in whole or in part, without restriction of any
836 kind, provided that the above copyright notice and this paragraph are
837 included on all such copies and derivative works. However, this
838 document itself may not be modified in any way, such as by removing
839 the copyright notice or references to the Internet Society or other
840 Internet organizations, except as needed for the purpose of
841 developing Internet standards in which case the procedures for
842 copyrights defined in the Internet Standards process must be
843 followed, or as required to translate it into languages other than
844 English.
846 The limited permissions granted above are perpetual and will not be
847 revoked by the Internet Society or its successors or assigns.
849 This document and the information contained herein is provided on an
850 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
851 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
852 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
853 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
854 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.