idnits 2.17.1 draft-niemi-sipping-event-throttle-reqs-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (January 22, 2003) is 7764 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 informational reference (is this intentional?): RFC 3265 (ref. '2') (Obsoleted by RFC 6665) == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-09 == Outdated reference: A later version (-05) exists of draft-ietf-simple-winfo-package-04 == Outdated reference: A later version (-04) exists of draft-ietf-sipping-mwi-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft Nokia 4 Expires: July 23, 2003 January 22, 2003 6 Requirements for Limiting the Rate of Event Notifications 7 draft-niemi-sipping-event-throttle-reqs-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on July 23, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 All event packages are required to specify a maximum rate at which 39 event notifications are generated by a single notifier. Such a limit 40 is provided in order to reduce network congestion. In addition to 41 the fixed limits introduced by specific event packages, further 42 mechanisms for limiting the rate of event notification are also 43 allowed to be defined by event package specifications but none have 44 been specified so far. This memo discusses the requirements for a 45 throttle mechanism that allows a subscriber to further limit the rate 46 of event notification. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Example Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 55 Normative References . . . . . . . . . . . . . . . . . . . . . . 5 56 Informative References . . . . . . . . . . . . . . . . . . . . . 5 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 58 Intellectual Property and Copyright Statements . . . . . . . . . 7 60 1. Introduction 62 The SIP events framework described in RFC 3265 [2] mandates that each 63 event package specification defines an absolute maximum on the rate 64 at which notifications are allowed to be generated by a single 65 notifier. Such a limit is provided in order to reduce network 66 congestion. 68 All of the existing event package specifications include a maximum 69 notification rate recommendation, ranging from once in every five 70 seconds [3], [4], [5] to once per second [6]. 72 Per the SIP events framework, each event package specification is 73 also allowed to define additional throttling mechanisms which allow 74 the subscriber to further limit the rate of event notification. So 75 far none of the event package specifications have defined such 76 throttling mechanisms. 78 This memo discusses the requirements for a generic throttling 79 mechanism, which allows the subscriber to limit the rate of event 80 notifications. It is intended that the throttle mechanism is not 81 event package specific, but commonly available to be used with all 82 event subscriptions. 84 2. Conventions 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 90 3. Example Use Case 92 There are many applications that potentially would make use of a 93 throttle mechanism. This chapter only illustrates one possible use 94 case, in which a mobile device uses the event throttling mechanism to 95 limit the amount of traffic it may receive. 97 A mobile application is watching the state of 100 presentities each 98 generating notifications at a maximum rate of once per five seconds. 99 Assuming that the arrival times of notifications are evenly 100 distributed, this will result in a maximum notification frequency of: 102 f = 100 * (1 / 5s) = 100 / 5 Hz = 20 Hz 104 experienced by the mobile. The same watcher subscribing using a 105 throttle mechanism to limit the maximum rate at which notifications 106 are to be generated to once per 20 seconds can expect a maximum 107 notification frequency of: 109 f = 100 * (1 / 20s) = 100 / 20 Hz = 5 Hz 111 thus resulting in 75% reduction in the maximum rate of incoming 112 presence notifications. 114 Note that the actual rate of notification is the sum of many 115 factors, and this example only makes a very broad assumption on 116 the absolute maximum rate at which the notifications might be 117 generated. 119 4. Requirements 121 REQ1: The subscriber MUST be able to limit using a throttle mechanism 122 the maximum rate at which the notifier is allowed to generate 123 notifications in a subscription. 125 REQ2: The subscriber MUST be able to indicate that it requires the 126 use of a throttle mechanism in the subscription. 128 REQ3: The subscriber SHOULD be allowed to indicate support for the 129 throttle mechanism without requiring it. 131 REQ4: The notifier MUST be able to indicate that it does not support 132 the use of a throttle mechanism in the subscription. 134 REQ5: If the throttle mechanism isn't required by the subscriber, the 135 notifier SHOULD be able to ignore it. 137 REQ6: It MUST be possible to use the throttle mechanism in 138 subscriptions to all events. 140 REQ7: It MUST be possible to use the throttle mechanism together with 141 any event filtering mechanism. 143 REQ8: The notifier MUST be allowed to use a maximum rate lower than 144 the one given by the subscriber. 146 REQ9: Authentication and integrity protection SHOULD be applied to 147 subscriptions that apply the throttle mechanism. 149 Note that Section 5 contains further discussion on the security 150 implications of the throttle mechanism. 152 5. Security Considerations 154 Naturally all of the security considerations for event subscriptions 155 and notifications also apply to subscriptions and notifications that 156 use the throttle mechanism. In addition, using the event throttle 157 mechanism introduces some new security issues to consider: 159 The throttle mechanism might allow a subscriber to set a very low 160 maximum notification rate - one that possibly exceeds the 161 subscription expiration. Such a limit inserted by a malicious 162 third party would result in very few if any notifications to be 163 generated, which could be perceived as theft of service to the 164 subscriber. 166 Similarly, the throttle mechanism might allow the subscriber to 167 set a very high maximum rate of notification that possibly is 168 higher than the default recommended rate of notification. Such a 169 high rate inserted by a malicious third party could result in 170 denial of service of the notifier due to performance issues. 172 Using the throttle mechanism potentially allows a subscriber to 173 increase the number of active subscriptions due to the decrease in 174 the maximum rate of notifications generated by a single notifier. 175 If a malicious third party is able to remove the throttle from the 176 subscriptions, the subscriber might be flooded with notifications. 178 All of the above problems can be avoided by ensuring that the 179 integrity and authenticity of subscriptions is protected by applying 180 relevant security measures. 182 Normative References 184 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 185 Levels", BCP 14, RFC 2119, March 1997. 187 Informative References 189 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 190 Notification", RFC 3265, June 2002. 192 [3] Rosenberg, J., "A Presence Event Package for the Session 193 Initiation Protocol (SIP)", draft-ietf-simple-presence-09 (work 194 in progress), December 2002. 196 [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 197 Package for Registrations", draft-ietf-sipping-reg-event-00 198 (work in progress), October 2002. 200 [5] Rosenberg, J., "A Watcher Information Event Template-Package for 201 the Session Initiation Protocol (SIP)", 202 draft-ietf-simple-winfo-package-04 (work in progress), December 203 2002. 205 [6] Mahy, R., "A Message Summary and Message Waiting Indication 206 Event Package for the Session Initiation Protocol (SIP)", 207 draft-ietf-sipping-mwi-01 (work in progress), November 2002. 209 Author's Address 211 Aki Niemi 212 Nokia 213 P.O. Box 321 214 NOKIA GROUP, FIN 00045 215 Finland 217 Phone: +358 50 389 1644 218 EMail: aki.niemi@nokia.com 220 Intellectual Property Statement 222 The IETF takes no position regarding the validity or scope of any 223 intellectual property or other rights that might be claimed to 224 pertain to the implementation or use of the technology described in 225 this document or the extent to which any license under such rights 226 might or might not be available; neither does it represent that it 227 has made any effort to identify any such rights. Information on the 228 IETF's procedures with respect to rights in standards-track and 229 standards-related documentation can be found in BCP-11. Copies of 230 claims of rights made available for publication and any assurances of 231 licenses to be made available, or the result of an attempt made to 232 obtain a general license or permission for the use of such 233 proprietary rights by implementors or users of this specification can 234 be obtained from the IETF Secretariat. 236 The IETF invites any interested party to bring to its attention any 237 copyrights, patents or patent applications, or other proprietary 238 rights which may cover technology that may be required to practice 239 this standard. Please address the information to the IETF Executive 240 Director. 242 Full Copyright Statement 244 Copyright (C) The Internet Society (2003). All Rights Reserved. 246 This document and translations of it may be copied and furnished to 247 others, and derivative works that comment on or otherwise explain it 248 or assist in its implementation may be prepared, copied, published 249 and distributed, in whole or in part, without restriction of any 250 kind, provided that the above copyright notice and this paragraph are 251 included on all such copies and derivative works. However, this 252 document itself may not be modified in any way, such as by removing 253 the copyright notice or references to the Internet Society or other 254 Internet organizations, except as needed for the purpose of 255 developing Internet standards in which case the procedures for 256 copyrights defined in the Internet Standards process must be 257 followed, or as required to translate it into languages other than 258 English. 260 The limited permissions granted above are perpetual and will not be 261 revoked by the Internet Society or its successors or assignees. 263 This document and the information contained herein is provided on an 264 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 265 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 266 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 267 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 268 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 Acknowledgement 272 Funding for the RFC Editor function is currently provided by the 273 Internet Society.