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