idnits 2.17.1 draft-dusseault-s2s-event-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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-dusseault-s2s-event-reqs', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-dusseault-s2s-event-reqs', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-dusseault-s2s-event-reqs', but the file name used is 'draft-dusseault-s2s-event-reqs-00' == 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 a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 202: '...ent notification MUST require minimum-...' RFC 2119 keyword, line 226: '...ent notification MUST protect from eve...' RFC 2119 keyword, line 229: '... MUST protect the notification aggre...' RFC 2119 keyword, line 273: '...ol specification MUST discuss how an i...' 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 (February 23, 2003) is 7730 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) -- Looks like a reference, but probably isn't: 'REF' on line 311 ** Obsolete normative reference: RFC 3265 (ref. '1') (Obsoleted by RFC 6665) Summary: 8 errors (**), 1 flaw (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Dusseault 3 Internet-Draft Xythos 4 Expires: August, 2003 February 23, 2003 6 Requirements for Server-to-Server Event Pipeline Protocols 7 draft-dusseault-s2s-event-reqs 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 Internet- 17 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 May 28, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 Server-to-server event pipelines are required in situations where an 39 event source generates events for a number of end-users (or simply 40 generates events without an idea of who the end recipients might be), 41 and sends these events to an event or notification aggregator 42 service. These kinds of event source servers are common in messaging 43 (for example, voice messaging servers and calendar servers might send 44 events to a user's main messaging server or to a single-purpose 45 notification server). A general set of requirements is outlined here 46 for the server-to-server aspect of these kinds of scenarios. 48 1. Introduction 50 The need for this requirements document arose in the VPIM and 51 Lemonade working groups in 2002, where a protocol for server-to- 52 server messaging events was being considered. Such a protocol cannot 53 be considered in isolation: it must be considered together with other 54 protocols and applications with which the protocol interacts. This 55 includes the nature of the application server generating events, the 56 kind of events that may be generated, and other protocols that may be 57 used later to deliver notifications. It is also important to have a 58 basic idea how this protocol will be used and extended beyond its 59 original description. 61 This document considers security requirements, internationalization 62 requirements, and architectural requirements. Also, it considers 63 notification info-set requirements. The notification info-set refers 64 to the set of information that must be present or can be generated 65 for an event notification so that it can be delivered using another 66 protocol without having to make inaccurate guesses at any important 67 information. For example, it must be possible to tell what host an 68 event arises on so that when the event is delivered the end 69 application knows what host to go to for more information about the 70 event. Since the source machine may be host multiple site names 71 which all use the same event pipeline, this information must be in 72 the event notification. This and other possible examples will be 73 discussed later. 75 The security requirements section includes some discussion of the 76 threat model. 78 Examples from unified messaging are typically used (voice mail, 79 email, calendaring) but occasionally examples from more speculative 80 areas are used to illustrate the need for a certain requirement. 82 Here is a representative list of the kinds of application problems 83 IETF groups are would like to solve related to notifications. 85 o SNAP proposal in lemonade and vpim working groups, intended for 86 email/voice mailbox event delivery from source server to 87 aggregation server 89 o RFC 3265 [1] specifies SIP notifications 91 o WebDAV WG has seen a specific proposal for events (GENA) relating 92 to resources. For example, authors may be notified when their 93 document becomes unlocked. 95 o CalSched WG has discussed notifications for appointment reminders. 97 o HTTP/OPES/WEBI WG has discussed notifications of web cache timeout 98 events. 100 o XMPP involves notifications of presence changes. Instant messages 101 can almost be seen as events. 103 o LDAP-EXT WG has discussed a notification protocol 105 o IPP WG has discussed requirements for a printing event 106 notification 108 2. Architecture Considerations 110 2.1 Connection Characteristics 112 A server-to-server messaging event pipeline can be used to aggregate 113 notifications for eventual delivery to end-user. It can also be used 114 to update information on an application server. For example, 115 notifications of new voice mail events could arrive at a regular 116 email server, and the regular email server could store a count of new 117 voice mail events until the user logs on and asks for all new 118 messages. Multiple event source servers, of the same type or 119 different types, could all set up a pipeline to the source sink 120 server. 122 If the messaging servers all have accounts for the same users, then 123 the pipeline is likely to carry a large number of events. Modern 124 email servers can handle 10,000 concurrent users, and people can 125 recieve 300 new email a day, thus 3 million new email events can be 126 generated daily, before even counting other types of email events, or 127 other types of events (voice messages, calendaring, instant messaging 128 and presence). This kind of load must be assumed for a server-to- 129 server messaging event protocol. 131 The server-to-server pipeline could be efficiently maintained as an 132 open TCP connection, to avoid recurring connection startup costs. 133 Privacy and authentication could be ensured with a transport layer 134 encryption protocol like TLS [REF]. A TCP connection also allows for 135 somewhat simpler acknowledgement of received events, assuming acks 136 are required. 138 UDP could be considered for efficient delivery of small messages, but 139 in the absence of IPSEC, some kind of encryption would have to be 140 used to protect privacy. A per-UDP-packet encryption mechanism like 141 S/MIME is probably unusable due to length limitations, but it would 142 be possible to define an encryption mechanism that encrypted each 143 packet using the same shared secret. However, this might not provide 144 authorization/authentication, unless provisioning work was used to 145 configure the servers to share the secret and not connect to servers 146 without such a secret. Note that with UDP acks are somewhat more 147 complicated because the event source server needs to correlate acks 148 to events that may have been sent a while ago even if more recent 149 events have already been acked. 151 TODO: think more about TCP/UDP and per-packet encryption. 153 Whether TCP or UDP is used, a request/response model protocol is 154 likely inappropriate. Request/response protocols rely very little on 155 state between requests, so instead state-like information is repeated 156 on each request. In this application, some state information is 157 likely to change only rarely if ever. For example, HTTP requires 158 headers like content-length and content-type on every single request. 159 In an event pipeline, content-type (of the notification itself) will 160 likely be unnecessary or rarely necessary. 162 2.2 ACKs 164 Are acknowledgements required? 166 2.3 Interoperation with other Notification systems 168 A server receiving a large number of notifications relating to many 169 users mailboxes may be able to deal with those notifications itself, 170 but may also need to pass those notifications on to the end-user's 171 client at some point. This may result in some need for consistent or 172 consistently transformable addresses. Email addresses can probably 173 be used in some messaging scenarios, but what about other addresses? 174 What if the server receiving the notifications is not an email server 175 but another kind of notification aggregator? Can a SIP event server 176 receive a "new voice message" notification and know what address to 177 use to set up a replay session with a SIP client? 179 2.4 Subscriptions 181 Is it a requirement that the recipient of notifications be able to 182 choose which kinds are required? This would allow the server to 183 filter out notifications for accounts that are inactive, and 184 notifications of uninteresting types. It might greatly reduce the 185 quantity of notifications used in the system. 187 Another possible advantage of subscriptions is that if a subscription 188 ID is assigned, the sender of the notification can more efficiently 189 identify the context of the notification for the recipient. 191 3. Security Requirements 193 3.1 Privacy 195 Messaging events, and any other event having to do with user account 196 activity, and in fact many events of many kinds, may have sensitive 197 or private information. The event may only contain the information 198 that an email arrived from a certain address at a certain time with a 199 certain subject, but even this much information can be considered 200 sensitive. 202 A protocol for event notification MUST require minimum-to-implement 203 privacy protection mechanisms. It is not sufficient to leave these 204 mechanisms up to implementors, because two independent 205 implementations must have at least one shared privacy mechanism in 206 order to be able to interoperate and still protect privacy. 208 3.2 Integrity 210 Event integrity considerations include the following threats 212 o An attacker might want to cause certain events not to get 213 delivered, and for this lack of delivery to go unnoticed. 215 o An attacker might generate false event notifications which are 216 received and treated as legitimate events. 218 o An attacker might cause duplicate delivery of otherwise legitimate 219 event notifications. The danger is if the duplicate delivery goes 220 unnoticed. For example, a legitimate event signaling the order of 221 expensive equipment might get delivered several times appearing as 222 separate events. 224 o Event notifications might be changed en route. 226 A protocol for event notification MUST protect from event 227 notification integrity attacks by requiring a minimum-to-implement 228 integrity protection mechanism. Notice also that the architecture 229 MUST protect the notification aggregator from impersonation attacks, 230 which allow streams of false events to be inserted into the system by 231 pretending to be a legitimate event source. 233 It's probably not possible to protect completely from an attacker 234 causing events to be lost (the attacker might be able to cause the 235 connection between the servers to go down). However, it should not 236 be possible for events to be removed from an otherwise successfully 237 maintained connection. 239 3.3 Authentication 241 Authentication must be considered in order to ensure privacy and 242 protect from integrity attacks. It may be necessary for a 243 notification aggregation server to provide authentication for the end 244 user in order to prove that access to certain kinds of event 245 information is allowed. 247 3.4 Authorization 249 There are a number of potential authorization issues. 251 o Permission to subscribe to certain information: e.g. is the 252 notification aggregation server allowed to subscribe to a certain 253 user's calendar events 255 o Permission to send events: e.g. is the event source server 256 allowed to open a pipeline and send events to the event sink 257 server 259 o Permission to route events to a particular user: e.g. is the 260 event source server allowed to send events to a particular user 261 via a notification aggregation server 263 Some of these authorization issues may be mitigated by opening a 264 connection in a certain direction. For example, if a notification 265 aggregation server opens a connection to the event source server, it 266 can be assumed the event source server is allowed to send events over 267 this connection. 269 Sometimes authorization issues are dealt with as a matter of 270 provisioning. It is assumed that the administrator configures the 271 source to send events to the sink, and configures the sink to receive 272 events from the source. However, if this is the approach used, the 273 protocol specification MUST discuss how an implementation should 274 behave such that provisioning does solve the problem. 276 4. Internationalization Requirements 278 4.1 Character Set 280 An event notification protocol must support Unicode (must require 281 implementations to support Unicode) in order to convey information 282 about events. For example, the name of a WebDAV resource that 283 becomes unlocked (and generates an unlock event) might be Unicode). 285 4.2 Language Negotiation 287 An event notification may not need language negotiation. The events 288 occur with given text, with or without language negotiation. The 289 event sink server may not even be capable of determining the language 290 preference for an event if the event is going to be multiplexed to 291 multiple users. 293 Because some languages share some unicode characters, an event 294 notification protocol will sometimes need to convey the language of 295 human-readable strings. The language information allows proper 296 selection of font for display. 298 In order to minimize language issues, error codes should be machine 299 parsable. 301 5. Extensibility Requirements 303 5.1 Event Type Names 305 The most likely path for extensibility is simply to define new event 306 types, new event names, and the information that goes along with 307 events. By "event name" I mean the name given to a type of event so 308 that the event sink server can tell what type of event it is. Thus 309 the event name could be something like "new-email" in the namespace 310 "http://www.example.com/namespaces/email-application" (a XML QName or 311 Qualified Name [REF]). 313 Event names must be machine readable so that applications can 314 dispatch based on event type. 316 Event names should be extensible by any number of independently 317 operating groups without serious risk of collision. For example, the 318 WebDAV group should be able to define a resource unlock event, and 319 not have to coordinate with other groups that might wish to define an 320 event for unlocking other kinds of objects. This problem could be 321 solved with use of XML namespaces, because each group can 322 independently define its own namespace with certain rules that make 323 duplicate namespaces unlikely, then the group can define event names 324 that are qualified with that namespace. 326 References 328 [1] Roach, A., "SIP-Specific Event Notification", RFC 3265, June 329 2002. 331 Author's Address 333 Lisa Dusseault 334 Xythos Software, Inc. 335 2064 Edgewood Dr. 336 Palo Alto, CA 94303 337 US 339 EMail: lisa@xythos.com 341 Full Copyright Statement 343 Copyright (C) The Internet Society (2002). All Rights Reserved. 345 This document and translations of it may be copied and furnished to 346 others, and derivative works that comment on or otherwise explain it 347 or assist in its implementation may be prepared, copied, published 348 and distributed, in whole or in part, without restriction of any 349 kind, provided that the above copyright notice and this paragraph are 350 included on all such copies and derivative works. However, this 351 document itself may not be modified in any way, such as by removing 352 the copyright notice or references to the Internet Society or other 353 Internet organizations, except as needed for the purpose of 354 developing Internet standards in which case the procedures for 355 copyrights defined in the Internet Standards process must be 356 followed, or as required to translate it into languages other than 357 English. 359 The limited permissions granted above are perpetual and will not be 360 revoked by the Internet Society or its successors or assigns. 362 This document and the information contained herein is provided on an 363 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 364 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 365 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 366 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 367 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Acknowledgement 371 Funding for the RFC Editor function is currently provided by the 372 Internet Society.