idnits 2.17.1
draft-rosen-simple-watcher-count-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 18.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 736.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 747.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 760.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- 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 (February 18, 2008) is 5912 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)
== Unused Reference: 'RFC3256' is defined on line 668, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141)
** Downref: Normative reference to an Informational RFC: RFC 2648
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665)
Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 simple B. Rosen
3 Internet-Draft NeuStar
4 Intended status: Standards Track S. Loreto
5 Expires: August 21, 2008 Ericsson
6 K. Kiss
7 Nokia
8 February 18, 2008
10 Optimizing Notifications for Presence Network Agents
11 draft-rosen-simple-watcher-count-00
13 Status of this Memo
15 By submitting this Internet-Draft, each author represents that any
16 applicable patent or other IPR claims of which he or she is aware
17 have been or will be disclosed, and any of which he or she becomes
18 aware will be disclosed, in accordance with Section 6 of BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
23 Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on August 21, 2008.
38 Copyright Notice
40 Copyright (C) The IETF Trust (2008).
42 Abstract
44 In large presence systems deployed in multiservice networks, presence
45 information is often known by the network in addition to, or instead
46 of the presentity's devices (endpoints). Examples of such
47 information include location and availability for various kinds of
48 session establishment. Even if devices know the information, the
49 network often has more bandwidth and better scale to keep the
50 presence server up to date. A Presence Network Agent (PNA) can
51 publish presence information to a Presence Server(PS). When done
52 large scale, the basic publish operation can be inefficient. When
53 the network has millions of subscribers, only some of which have
54 watchers, blind Publish operations are unecessary. WINFO can be used
55 to determine watchers, but the efficiency of maintaining WINFO per
56 subscriber, and the size of the messages involved, make that solution
57 unattractive. The PNA would prefer to have the Presence Server
58 simply tell it when there was at least one watcher.
60 This document describes an XML document stored on the PS by which the
61 PNA maintains a list of subscribers it can provide presence for as a
62 SIP event package that tells the PNA when the number of watchers for
63 a presentity on the list (or a specific presence element for a
64 presentity) goes from 0 to at least 1 or from 1 to 0.
66 Table of Contents
68 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
70 3. PNA Presentity List . . . . . . . . . . . . . . . . . . . . . 5
71 3.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 5
72 3.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 5
73 3.3. Default Document Namespace . . . . . . . . . . . . . . . . 6
74 3.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 6
75 3.5. Validation Constraints . . . . . . . . . . . . . . . . . . 6
76 3.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 7
77 3.6.1. Naming Conventions . . . . . . . . . . . . . . . . . . 7
78 3.6.2. Resource Interdependencies . . . . . . . . . . . . . . 7
79 3.6.3. Authorization Policies . . . . . . . . . . . . . . . . 7
80 4. Watcher-Count Event Package . . . . . . . . . . . . . . . . . 7
81 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 7
82 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7
83 4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 8
84 4.4. Subscription Duration . . . . . . . . . . . . . . . . . . 8
85 4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
86 4.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 9
87 4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 9
88 4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 10
89 4.9. Handling of Forked Requests . . . . . . . . . . . . . . . 10
90 4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 10
91 4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10
92 5. Watcher-count XML Document . . . . . . . . . . . . . . . . . . 11
93 5.1. Structure of the watcher-count document . . . . . . . . . 11
94 5.2. Computing Watcher Counts from the Document . . . . . . . . 12
95 5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
96 5.4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 13
97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
98 6.1. application/watcher-count+xml MIME Registration . . . . . 14
99 6.2. URN Sub-Namespace Registration for
100 urn:ietf:params:xml:ns:watcher-count . . . . . . . . . . . 14
101 6.3. Package Registration . . . . . . . . . . . . . . . . . . . 15
102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
103 7.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 15
104 7.2. Divulging Sensitive Information . . . . . . . . . . . . . 16
105 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
106 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
108 Intellectual Property and Copyright Statements . . . . . . . . . . 19
110 1. Terminology
112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
114 document are to be interpreted as described in [RFC2119].
116 2. Background
118 Presence systems [RFC3856] are being deployed in networks where the
119 network itself has presence information. This information may also
120 be known to the endpoint, but the network is often in a better
121 position to publish [RFC3903] the information to the presence server.
122 Mobile networks are an example of a network where a presence system
123 can have a very large number of presentities and providers, and where
124 bandwidth from the device to the presence server is restricted such
125 that volitile presence data would be much more efficient if the
126 network published some data elements to the presence server rather
127 than the user agent itself. A "Presence Network Agent" (PNA) is a
128 server operated by an entity in the network that has some presence
129 information and publishes this information to the presence server on
130 behalf of the presentity. Optimization techniques are available
131 which make the actual Publish operation reasonably efficient.
132 However, in large networks, there could be millions of presentities,
133 and if interconnected with other networks, even more watchers, but at
134 any point in time, there may not be any watchers for a particular
135 presentity. If there are no watchers, and presence information that
136 changes relatively often is published to the presence server anyway,
137 there can be significant wasted effort and bandwidth in both the
138 presence server and the presence network agent.
140 If the PNA knew which presentities that it had presence information
141 for had active watchers, then it could optimize its publishing
142 operations. The presence server knows that, but the only way for the
143 PNA to get that information is the WINFO package [RFC3857]. WINFO
144 provides the requisite data, but inefficiently. All the PNA wants to
145 know is when the number of watchers goes from zero (no watchers) to
146 at least 1, or from at least one to zero. There is no efficient way
147 to get that information.
149 PNAs provide information for a set of presentities, and the set of
150 presentities the PNA serves may not match the set of presentities a
151 particular PS serves. The PS has to know which presentities the PNA
152 serves in order to send it the right watcher state information. This
153 is simply a list of presentities that changes over time. The list
154 can be very long, so sending it in its entirety when something
155 changes on the list is not desirable.
157 Editor Note: There is an opportunity for further optimization if the
158 PS knows which elements the PNA can publish. Because of filtering
159 and presence rules, just because there is at least one watcher, it
160 doesn't mean that the elements the PNA publishes are visible to any
161 watchers. The PS could optimize notification of watcher counts to
162 only show when at least on watcher was recieving at least one element
163 the PNA publishes. This could further be extended to have the actual
164 watcher count for each element sent by the PS to the PNA.
166 3. PNA Presentity List
168 This document defines a Presentity List document intended to be
169 maintained on the PS by the PNS using XCAP [RFC4825].
171 3.1. Application Unique ID (AUID)
173 This specification defines the "pna-presentity-list" AUID within the
174 IETF tree, via the IANA registration in Section 6.
176 3.2. XML Schema
177
178
182
183
184 Root element for pna-presentity-list
185
186
187
188
189 PNA
190
191
192
193
194
195
196
197 List of Presentities
198
199
200
201 One Presentity on the list
202
203
204
205
207 3.3. Default Document Namespace
209 The default document namespace used in evaluating a URI is
210 urn:ietf:params:xml:ns:pna-presentity-list.
212 3.4. MIME Type
214 Documents conformant to this schema are known by the MIME type
215 "application/pna-presentity-list+xml", registered in Section 6.
217 3.5. Validation Constraints
219 The Presence Network Agent must be authorized to provide presence
220 data for the presentities on the list.
222 3.6. Data Semantics
224 The PNA element defines the URI of the PNA maintaining the list.
225 This URI must match the URI from which the PNA subscribes to the
226 watcher-count event package on the PS.
228 3.6.1. Naming Conventions
230 The PS must maintain a document with the file name containing the PNA
231 identity. Provisioning may be used to connect the file name to the
232 PNA URI.
234 3.6.2. Resource Interdependencies
236 There are no resource interdependencies in this application usage
237 beyond those defined by the schema.
239 3.6.3. Authorization Policies
241 This application usage does not change the default authorization
242 policy defined by XCAP.
244 4. Watcher-Count Event Package
246 This section fills in the details needed to specify an event package
247 as defined in Section 4.4 of [RFC3265].
249 4.1. Event Package Name
251 [RFC3265] requires package definitions to specify the name of their
252 package or template-package.
254 The name of this template-package is "watcher-count". It cannot be
255 applied to any other package. Recursive template-packaging is not
256 allowed.
258 4.2. Event Package Parameters
260 [RFC3265] requires package and template-package definitions to
261 specify any package specific parameters of the Event header field.
263 A single parameter "PNA" is defined. The parameter indicates pna-
264 presentity-list URI.
266 4.3. SUBSCRIBE Bodies
268 [RFC3265] requires package or template-package definitions to define
269 the usage, if any, of bodies in SUBSCRIBE requests.
271 No bodies are defined for the watcher-count package.
273 4.4. Subscription Duration
275 [RFC3265] requires package definitions to define a default value for
276 subscription durations, and to discuss reasonable choices for
277 durations when they are explicitly specified.
279 The PNA typically supports a large number of presentities, which
280 typically have watchers come and go. The PNA wants notifications for
281 any of the presentities on its list. Therefore, the duration of the
282 subscription is typically long. The default value for the
283 subscription duration is one day. However, clients SHOULD use an
284 Expires header field to specify their preferred duration.
286 4.5. NOTIFY Bodies
288 [RFC3265] requires package definitions to describe the allowed set of
289 body types in NOTIFY requests, and to specify the default value to be
290 used when there is no Accept header field in the SUBSCRIBE request.
292 The body of the watcher-count notification contains a watcher-count
293 document. This document contains a list of presentities in the pna-
294 presentity list whose watcher count went from 0 to 1 or 1 to 0 and
295 the current watcher count (which will always be zero or one). All
296 watcher-count subscribers and notifiers MUST support the application/
297 watcher-count+xml format described in herein, and MUST list its MIME
298 type, application/watcher-count+xml, in any Accept header field
299 present in the SUBSCRIBE request.
301 Other watcher count formats might be defined in the future. In that
302 case, the watcher-count subscriptions MAY indicate support of other
303 formats. However, they MUST always support and list application/
304 watcher-count+xml as an allowed format.
306 Of course, the watcher-count notifications generated by the server
307 MUST be in one of the formats specified in the Accept header field in
308 the SUBSCRIBE request. If no Accept header field was present, the
309 notifications MUST use the application/watcher-count+xml format
310 described herein.
312 4.6. Notifier Processing of SUBSCRIBE Requests
314 [RFC3265] specifies that packages should define any package- specific
315 processing of SUBSCRIBE requests at a notifier, specifically with
316 regards to authentication and authorization.
318 Although the number of watchers is less sensitive than identification
319 of a watcher, watcher information is personal information.
320 Therefore, all watcher-count subscriptions MUST be authenticated and
321 then authorized before approval. Authentication MAY be performed
322 using any of the techniques available through SIP, including digest,
323 S/MIME, TLS or other transport specific mechanisms [RFC3261].
324 Authorization policy is at the discretion of the administrator.
326 Editor Note: There is a timing problem. When a PS gets a SUBSCRIBE,
327 it should reply immediately with the presence state. However, if
328 this causes watcher-count to go from 0 to 1, the PS doesn't have good
329 state. It has to NOTIFY the PNA and wait for a response. That needs
330 to be described here. There may be further complications with a one
331 time or short subscription.
333 4.7. Notifier Generation of NOTIFY Requests
335 The SIP Event framework requests that packages specify the conditions
336 under which notifications are sent for that package, and how such
337 notifications are constructed.
339 Each watcher-count subscription is associated with a set of "inner"
340 subscriptions being watched. This set is defined by the URI in the
341 pna-presentity-list. A watcher-count notifier MUST generate a
342 notification any time the count of watchers in any of the watched
343 subscriptions goes from zero to at least one, or from one to zero.
344 To optimize the notification, the PS may delay the issuance of the
345 NOTIFY for a provisioned period of time. 5 seconds is the suggested
346 default time. The delay gives the PS an opportunity to gather
347 additional watcher count changes and send one NOTIFY with all of them
348 recieved in the delay period. The PS MUST make certain that no
349 watcher count change from zero to at least one or one to zero is
350 delayed by more than this period.
352 It is RECOMMENDED that a given notification only mention a particular
353 presentity once. The PNA MUST NOT depend on this behavior. When the
354 same presentity URI is encountered in more than one wc element's "r"
355 value, the "c" value in the last wc element determines the watcher
356 count of the presentity following processing in the PNA. That means
357 that the order of wc elements may matter. The recommended behavior
358 would filter multiple watcher changes from growing the size of the
359 NOTIFY body.
361 Upon a successful SUBSCRIBE where no subscription for a particular
362 pna-presentity-list was extant at the time of the subscription, the
363 initial NOTIFY from the PS to the PNA MUST have all of the
364 presentities for which there is at least one watcher. That is, the
365 PNA and PS behave as if just before the subscription, all
366 presentities on the list had no watchers. Presentities that actually
367 do have at least one watcher will be listed in the initial NOTIFY.
368 If at any time the PNA is concerned that it has lost track of watcher
369 count, it can reSUBSCRIBE, triggering a complete notification of
370 watcher count. Note that the size of this initial NOTIFY can be
371 quite large.
373 4.8. Subscriber Processing of NOTIFY Requests
375 [RFC3265] expects packages to specify how a subscriber processes
376 NOTIFY requests in any package specific ways, and in particular, how
377 it uses the NOTIFY requests to construct a coherent view of the state
378 of the subscribed resource. The watcher-count NOTIFY will only
379 contain information about those presentities whose watcher count
380 changed from zero to at least one, or from one to zero. To construct
381 a coherent view of the total state of all presentities on the pna-
382 presentity-list, a watcher-count subscriber will need to combine
383 NOTIFYs received over time. See Section 4.7 for a discussion of how
384 the PNA can trigger a complete state update from the PS.
386 4.9. Handling of Forked Requests
388 The behavior of forked requests for watcher-count is not defined and
389 implementations MUST NOT fork SUBSCRIBE or NOTIFY requests.
391 4.10. Rate of Notifications
393 [RFC3265] mandates that packages define a maximum rate of
394 notifications for their package.
396 For reasons of congestion control, it is important that the rate of
397 notifications not become excessive. As a result, it is RECOMMENDED
398 that the server not generate watcher-count notifications for a single
399 presentity at a rate faster than once every 5 seconds. See
400 Section 4.8 for a discussion of pacing NOTIFY operations for changes
401 to multiple presentity's watcher count. It is RECOMMENDED that such
402 a pacing mechanism be used.
404 4.11. State Agents
406 [RFC3265] asks packages to consider the role of state agents in their
407 design.
409 State agents are not required for watcher-count.
411 5. Watcher-count XML Document
413 5.1. Structure of the watcher-count document
415 Watcher-count is an XML [ref] document that MUST be well-formed and
416 SHOULD be valid. Watcher-count documents MUST be based on XML 1.0
417 and MUST be encoded using UTF-8. This specification makes use of XML
418 namespaces for identifying watcher-count documents and document
419 fragments. The namespace URI for elements defined by this
420 specification is a URN [RFC2141], using the namespace identifier
421 'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is:
422 urn:ietf:params:xml:ns:watcher-count
424 A watcher-count document begins with the root element tag "watcher-
425 count-list". It consists of any number of "wc" (for "watcher-count")
426 sub- elements, each of which is a presentity URI and a count of
427 watchers for that presentity. The count is either zero or one, where
428 zero means no watchers are presently receiving any form of presence
429 updates for the presentity and one means there is at least one active
430 watcher. Other elements from different namespaces MAY be present for
431 the purposes of extensibility; elements or attributes from unknown
432 namespaces MUST be ignored. There are two attributes associated with
433 the "watcher-count-list" element, both of which MUST be present:
434 PNA: This element contains the URI of a pna-presence-list maintained
435 on the PS. The presentities in the watcher-count document MUST be
436 on that list
437 version: This attribute allows the recipient of watcher-count
438 documents to properly order them. Versions start at 0, and
439 increment by one for each new document sent to a watcher-count
440 subscriber. Versions are scoped within a watcher-count
441 subscription. Versions MUST be representable using a 32 bit
442 integer. However, versions do not wrap.
444 Each "wc" element contains a list of presentities whose count of
445 watchers has changed from zero to at least one or from one to zero.
446 Other elements from different namespaces MAY be present for the
447 purposes of extensibility; elements or attributes from unknown
448 namespaces MUST be ignored. There are two attributes associated with
449 the "wc" element, both of which MUST be present:
450 r: This attribute contains a URI for the resource being watched. It
451 is mandatory.
453 c: This attribute contains an integer value of 0 or 1. Zero means
454 that there are presently no watchers for this resource. One means
455 there is at least one watcher.
457 The names "wc", "r" and "c" are deliberately short, as the document
458 is expected to be long and contain a great many such elements.
460 5.2. Computing Watcher Counts from the Document
462 Typically, the watcher-count NOTIFY will only contain information
463 about those presentities whose state has changed. To construct a
464 coherent view of the total state of all presentities on the pna-
465 presentity-list, a watcher-count subscriber will need to combine
466 NOTIFYs received over time. The watcher-count subscriber
467 conceptually maintains a table for each presentity on the pna-
468 presentity-list. Each pna-presentity-list is uniquely identified by
469 the URI in the "PNA" attribute of the "watcher-count-list" element.
470 Each table contains a row for each presentity in that list. Each row
471 is indexed by the URI for that presentity. It is conveyed in the "r"
472 attribute of the "wc" element. The contents of each row contain the
473 count of watchers of that presentity as conveyed in the "wc" element.
474 Other implementations are possible. For example, the PNA could
475 maintain a list of presentities whose watcher-count is >1 and add/
476 delete presentities to its list based on notifications it recieves
477 from the PS.
479 The tables are also associated with a version number. The version
480 number MUST be initialized with the value of the "version" attribute
481 from the "watcherinfo" element in the first document received. Each
482 time a new document is received, the value of the local version
483 number, and the "version" attribute in the new document, are
484 compared. If the value in the new document is one higher than the
485 local version number, the local version number is increased by one,
486 and the document is processed. If the value in the document is more
487 than one higher than the local version number, the local version
488 number is set to the value in the new document, the document is
489 processed, and the watcherinfo subscriber SHOULD generate a refresh
490 request to trigger a full state notification. If the value in the
491 document is less than the local version, the document is discarded
492 without processing.
494 5.3. Example
496 The following is an example of watcher-count information.
498
499
502
503
504
506 5.4. XML Schema
508 The following is the schema definition of the watcher-count document
509 format:
511
514
515
517
518
519
520
522
524
525
526
528
529
530
531
533
535
536
537
538
539
540
542 6. IANA Considerations
544 This document registers a new MIME type, application/
545 watcher-count+xml, registers a new XML namespace and registers a new
546 event package.
548 6.1. application/watcher-count+xml MIME Registration
550 MIME media type name: application
551 MIME subtype name: watcher-count+xml
552 Mandatory parameters: none
553 Optional parameters: Same as charset parameter application/xml as
554 specified in [RFC3023].
555 Encoding considerations: Same as encoding considerations of
556 application/xml as specified in [RFC3023].
557 Security considerations: See Section 10 of [RFC3023] and Section 7
558 of this specification.
559 Interoperability considerations: none.
560 Published specification: This document.
561 Applications which use this media type: This document type is used
562 to support optimization of publishing operations from a Presence
563 Network Agent to a Presence Server.
564 Additional Information:
565 Magic Number: None
566 File Extension: .wif or .xml
567 Macintosh file type code: "TEXT"
568 Personal and email address for further information: Brian Rosen
569
570 Intended usage: COMMON
571 Author/Change controller: The IETF.
573 6.2. URN Sub-Namespace Registration for
574 urn:ietf:params:xml:ns:watcher-count
576 This section registers a new XML namespace, as per the guidelines in
577 [?].
578 URI: The URI for this namespace is
579 urn:ietf:params:xml:ns:watcher-count.
580 Registrant Contact: IETF, SIMPLE working group, ,
581 Brian Rosen
.
582 XML:
584 BEGIN
585
586
588
589
590
592 Watcher Count Namespace
593
594
595 Namespace for Watcher Count
596 urn:ietf:params:xml:ns:watcher-count
597 See
598 RFC3858.
599
600
601 END
603 6.3. Package Registration
605 This specification registers an event template package as specified
606 in Section 6.2 of [RFC3265].
607 Package Name: watcher-count
608 Template Package: yes
609 Published Specification: This document
610 Person to Contact: Brian Rosen, br@brianrosen.net.
612 7. Security Considerations
614 7.1. Denial of Service Attacks
616 Watcher count generates notifications about changes in the state of
617 watchers for a particular resource. A single notification could be
618 extremely large, as in the initial state notification. This makes a
619 watcher-count subscription a potential tool for denial of service
620 attacks. Preventing these can be done through a combination of
621 sensible authorization policies and good operating principles.
623 Watcher-count subscriptions to that resource should only be allowed
624 from explicitly authorized entities, whose identity has been properly
625 authenticated. That prevents a watcher-count NOTIFY stream from
626 being generated from subscriptions made by an attacker.
628 7.2. Divulging Sensitive Information
630 Watcher count indicates how many users are interested in a particular
631 resource. Depending on the package and the resource, this can be
632 very sensitive information. One way in which this information can be
633 revealed is eavesdropping. An attacker can observe watcher-count
634 notifications, and learn this information. To prevent that, watchers
635 MAY use the sips URI scheme when subscribing to a watcherinfo
636 resource. Notifiers for watcher-count MUST support TLS and sips as
637 if they were a proxy (see Section 26.3.1 of [RFC3261]).
639 SIP encryption, using S/MIME, MAY be used end-to-end for the
640 transmission of both SUBSCRIBE and NOTIFY requests.
642 Another way in which this information can be revealed is through
643 spoofed subscriptions. These attacks can be prevented by
644 authenticating and authorizing all watcher-count subscriptions. In
645 order for the notifier to authenticate the subscriber, it MAY use
646 HTTP Digest (Section 22 of [RFC3261]). As a result, all watchers
647 MUST support HTTP Digest. This is a redundant requirement, however,
648 since all SIP user agents are mandated to support it by [RFC3261].
650 8. Acknowledgements
652 Guy Paradis and Fridy Sharon-Fridman of NeuStar contributed to the
653 ideas in this document and reviewed the text.
655 9. Normative References
657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
658 Requirement Levels", BCP 14, RFC 2119, March 1997.
660 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
662 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
663 August 1999.
665 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
666 Types", RFC 3023, January 2001.
668 [RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable
669 Service Interface Specifications) Device Class DHCP
670 (Dynamic Host Configuration Protocol) Relay Agent
671 Information Sub-option", RFC 3256, April 2002.
673 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
674 A., Peterson, J., Sparks, R., Handley, M., and E.
675 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
676 June 2002.
678 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
679 Event Notification", RFC 3265, June 2002.
681 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
682 January 2004.
684 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
685 Initiation Protocol (SIP)", RFC 3856, August 2004.
687 [RFC3857] Rosenberg, J., "A Watcher Information Event Template-
688 Package for the Session Initiation Protocol (SIP)",
689 RFC 3857, August 2004.
691 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
692 for Event State Publication", RFC 3903, October 2004.
694 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
695 Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
697 Authors' Addresses
699 Brian Rosen
700 NeuStar, Inc.
701 470 Conrad Dr
702 Mars, PA 16046
703 US
705 Email: br@brianrosen.net
707 Salvatore Loreto
708 Ericsson
709 Hirsalantie 11
710 Jorvas 02420
711 Finland
713 Email: salvatore.loreto@ericsson.com
714 Krisztian Kiss
715 Nokia
716 313 Fairchild Dr
717 Mountain View, CA 94043
718 US
720 Email: krisztian.kiss@nokia.com
722 Full Copyright Statement
724 Copyright (C) The IETF Trust (2008).
726 This document is subject to the rights, licenses and restrictions
727 contained in BCP 78, and except as set forth therein, the authors
728 retain all their rights.
730 This document and the information contained herein are provided on an
731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
732 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
733 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
734 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
735 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
738 Intellectual Property
740 The IETF takes no position regarding the validity or scope of any
741 Intellectual Property Rights or other rights that might be claimed to
742 pertain to the implementation or use of the technology described in
743 this document or the extent to which any license under such rights
744 might or might not be available; nor does it represent that it has
745 made any independent effort to identify any such rights. Information
746 on the procedures with respect to rights in RFC documents can be
747 found in BCP 78 and BCP 79.
749 Copies of IPR disclosures made to the IETF Secretariat and any
750 assurances of licenses to be made available, or the result of an
751 attempt made to obtain a general license or permission for the use of
752 such proprietary rights by implementers or users of this
753 specification can be obtained from the IETF on-line IPR repository at
754 http://www.ietf.org/ipr.
756 The IETF invites any interested party to bring to its attention any
757 copyrights, patents or patent applications, or other proprietary
758 rights that may cover technology that may be required to implement
759 this standard. Please address the information to the IETF at
760 ietf-ipr@ietf.org.
762 Acknowledgment
764 Funding for the RFC Editor function is provided by the IETF
765 Administrative Support Activity (IASA).