SIP Working Group M. Garcia-Martin Internet-Draft Nokia Siemens Networks Intended status: Informational H. Schulzrinne Expires: November 12, 2007 Columbia University May 11, 2007 Notification of General Events Using the Session Initiation Protocol (SIP) Event Notification Framework draft-garcia-sipping-general-events-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 12, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The SIP event notification framework is specified in RFC 3265. The framework restricts usage to notifications of events related to the SIP state. However, there is growing interest in the community for relaxing that constraint and using the SIP event notification framework for reporting changes in state that is not directly related to SIP. For example, it has been suggested a usage of the framework Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 1] Internet-Draft SIP General Events May 2007 for reporting events related to a vehicle state, files stored in a device, calendar events, and Sieve notifications. This memo discusses the benefits of a mechanism for general event notifications using SIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. General requirements . . . . . . . . . . . . . . . . . . . . . 4 3. Benefits of Using SIP . . . . . . . . . . . . . . . . . . . . 4 3.1. Operations with the SIP Event Notification Framework . . . 5 3.2. Soft State . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Separation of Transport and Events . . . . . . . . . . . . 5 3.4. Subscriber List Discovery . . . . . . . . . . . . . . . . 5 3.5. Aggregation, Rate Limit, and Filtering Event Notifications . . . . . . . . . . . . . . . . . . . . . . 5 3.6. Owner Control of Offered Information . . . . . . . . . . . 6 3.7. Availability of Protocol Stack . . . . . . . . . . . . . . 6 3.8. Service Integration . . . . . . . . . . . . . . . . . . . 6 3.9. Maturity of protocols . . . . . . . . . . . . . . . . . . 6 3.10. Infrastructure Re-usability . . . . . . . . . . . . . . . 7 3.11. Security Properties . . . . . . . . . . . . . . . . . . . 7 3.11.1. Authentication . . . . . . . . . . . . . . . . . . . 7 3.11.2. Authorization . . . . . . . . . . . . . . . . . . . . 7 3.11.3. Integrity Protection and Confidentiality . . . . . . 7 3.11.4. Identity Management . . . . . . . . . . . . . . . . . 8 3.12. Discovery of IP Address . . . . . . . . . . . . . . . . . 8 3.13. Support for Multiple Endpoints . . . . . . . . . . . . . . 8 3.14. Independence of Data Source and Notifiers . . . . . . . . 8 3.15. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 8 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informational References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 2] Internet-Draft SIP General Events May 2007 1. Introduction The Session Initiation Protocol (SIP) (RFC 3261 [1]) provides a mechanism for creating, modifying, and terminating sessions between users. The SIP event notification framework (RFC 3265 [2]) extends SIP with a mechanism for subscribing to, and receiving notifications of, SIP-related events within SIP networks. The SIP event notification framework introduces the notion of a package, which is a specific "instantiation" of the events framework for a well-defined set of events. However, the SIP-specific event notification framework restricts its usage to SIP-related events. Specifically, the framework indicates that it is not intended to be a general-purpose infrastructure for all classes of event subscription and notification. Rather, the framework is restricted to provide notifications related to SIP state. Following the guidelines in RFC 3265, a number of event packages for reporting SIP-related notifications have been developed. To cite a few of them: o The conference event package (RFC 4575 [14]) provides notifications of conference participants and associated data. o The dialog event package (RFC 4235 [11]) provides notifications related to a given SIP dialog. o The Key Press Stimulus event package (RFC 4730 [16]) provides notifications of key presses in SIP User Agents (UAs). o The Message-Summary event package (RFC 3842 [6]) provides notifications of message waiting status and message summaries stored in voicemail servers. o The presence event package (RFC 3856 [8]) provides notifications of the user's presence information. o The 'reg' event package (RFC 3680 [5]) provides notifications of the SIP registration state associated with a user. All of the above mentioned event packages provide notifications of events related, in some manner, to SIP. However, during the last years, there is a growing interest in the community to use the SIP notification framework for providing notifications of events that are somehow related to real-time communications, but not necessarily to SIP. A few examples of those event packages specifications are: o The vehicle information event package [18] provides status of vehicles and diagnostic information distributed by vehicle telematics systems. Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 3] Internet-Draft SIP General Events May 2007 o The calendar event package [25] provides notifications of calendar events. o Sieve notifications using SIP [26] proposes an event package to provide notifications of Sieve filter rules. o The resource sharing framework [23] and the companion resource event package [24] propose a mechanism for getting a list of remotely available files and notifications of changes in those files. It must be noted that none of the mentioned proposed usages require an extension to the core SIP protocol or the SIP event notification framework. The definition of the event package is the only required extension. 2. General requirements We have a analyzed the proposed usages of the SIP event notification framework for reporting non-SIP state, and we have drafted a set of requirements to be met by a suitable protocol. These requirements are: REQ-1: The protocol must provide subscribe, notification, and publication operations. REQ-2: The protocol must provide subscriptions to soft state with configurable time-out. REQ-3: The protocol must provide a separation of transport and event description, to allow adding new event types. REQ-4: The protocol must have the ability to discover who is currently subscribed to an event. REQ-5: The protocol must have the ability to aggregate, rate-limit and filter event notifications. REQ-6: The protocol must have the ability of the event "owner" to restrict access to event notifications. REQ-7: The protocol must have the ability to control who can subscribe to what and when. 3. Benefits of Using SIP According to RFC 3265, implementations of event packages need to consider whether SIP is a correct protocol for delivering the needed notifications. This sections analyzes the benefits of using SIP and its compliance with the above-mentioned requirements for delivering non-SIP related notifications. Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 4] Internet-Draft SIP General Events May 2007 3.1. Operations with the SIP Event Notification Framework The SIP Event Notification Framework [2] provides for two basic operations: subscriptions to event state and notifications of changes in the event state. These are modeled through the SUBSCRIBE and NOTIFY SIP methods. In addition, SIP also provides a publication operation in the format of the SIP PUBLISH method [10]. 3.2. Soft State The SIP event notification framework allows subscribers of event state data to get subscribed by utilizing soft-state subscriptions, i.e., subscriptions that eventually expire (if not renewed). This contrasts hard state subscriptions, which only expire upon the reception of an explicit message. The mechanism allows a negotiation of the time-out of the soft state between the subscriber and notifier. 3.3. Separation of Transport and Events SIP publications, subscriptions and notifications are handled by the SIP PUBLISH, SUBSCRIBE, and NOTIFY methods, respectively. None of the methods define which events are to be reported, not even the data format that describes such event. Events are specified separately, so they are the data formats. These provides a separation of two separate issues: the transport and the events. As a consequence, it is possible to add new events with no changes to the transport protocol. 3.4. Subscriber List Discovery There are scenarios where it is needed to discover the list of subscribers to a certain event. This might be the case, for example, to provide authorization for subscriptions or to be able to adapt certain authorization rules to a group of subscribers. SIP provides a watcher information template event package [9] that meets the requirements. A user can subscribe to the watcher information of an event package of a given resource, and get notifications that contain the list of subscribers to that event package at that resource. 3.5. Aggregation, Rate Limit, and Filtering Event Notifications SIP provides a number of mechanisms that help to provide aggregation, rate limit, and filtering of event notifications. On one side, event packages can be designed to provide aggregated events, where a single notification provides the new event state for a number of atomic changes. Event packages need to defined the minimum notification rate and be able to hand aggregated notifications. Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 5] Internet-Draft SIP General Events May 2007 On the other hand, work is on progress for providing SIP with a mechanism that allows a subscriber to limit the rate of notifications [21]. SIP also provides a filtering mechanism [15] by which a subscriber can indicate the pieces of information within the event for which notifications should be sent. 3.6. Owner Control of Offered Information Owners of event state information (or other duly authorized users) can determine the level of privacy of the state information by, e.g., setting the rules that govern the level of details of the state information that is to be delivered to each subscriber. This makes that two different subscribers receive different level of details pertaining to the same state, according to the rules that an authorized person has set. Common Policy [17] offers a framework for expressing privacy preferences. The framework allows a user to create authorization policies for access application-specific data. This framework has been tailored to different applications. For example, the presence service instantiates Common Policy [17] with Presence Authorization Rules [22]. These rules determine the type of information supplied to each subscriber to a presence event package. 3.7. Availability of Protocol Stack Most modern communications applications already implement SIP and the SIP event notification framework due to requirements of a number of applications. Assuming SIP and the SIP event notification framework is already implemented, adding a new event package is simpler, from the implementation point of view, than adding a completely new protocol. In many occasions, the SIP event notification framework has been already implemented to support the presence service. 3.8. Service Integration Most communications services today integrate a number of services, such as voice, video, instant messaging, presence, web, email, and file transfer, where some of these services are based on SIP. When a new service or function should be integrated in the existing set of services, the integration is greatly simplified if a single protocol is used for the new and existing services. 3.9. Maturity of protocols SIP is a mature protocol which is widely deployed in the Internet, enterprise, and other networks. Interoperability of SIP has been a key aspect of it over the years. This can be verified through the Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 6] Internet-Draft SIP General Events May 2007 logs of the multiple SIP and SIMPLE interoperability tests that have been taking place during the last years. Because of this, SIP offers an enviable record that attracts new services. 3.10. Infrastructure Re-usability There are cases when the new service or function requires to deploy some sort of network support, for example, to route SIP signaling, authenticate users, aggregate state, or handle subscriptions. If an existing SIP network of proxies, registrars, or notifiers is already available and can be re-utilized by the service or function, then the deployment and operation of the service is greatly simplified. 3.11. Security Properties SIP provides a number of security properties that are very interesting for the deployment of services. Among others, the following security properties are of interest for most services. 3.11.1. Authentication SIP provides means to do client to server or mutual authentication. Authentication can be done on a request by request basis, or at registration time and then extended to all the SIP requests that take place while the registration is active. Several authentication mechanisms have been developed or adapted for SIP. The HTTP Digest Authentication scheme (RFC 2617 [3]) offers the common minimum denominator. Other mechanisms include TLS [12] with certificates, etc. These mechanisms are further complemented with mechanisms for delivering a cryptographic identity [13], network asserted identity [4], or trait-based authorization using the Security Assertion Markup Language (SAML) [20]. 3.11.2. Authorization The SIP event notification framework provides several levels of authorizations. On one side, an event state compositor can authorize state suppliers to publish state related to some data. On the other hand, an event state compositor can authorize subscriptions of subscribers of state information. 3.11.3. Integrity Protection and Confidentiality Integrity protection and confidentiality of the supplied state can be achieved by applying S/MIME [7] to the bodies of the SIP requests (e.g., NOTIFY, PUBLISH). Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 7] Internet-Draft SIP General Events May 2007 3.11.4. Identity Management A user of SIP services is usually provided with an identity, typically in the format of a SIP URI, for his disposal. When a new service is introduced, the new service can reuse existing SIP identities, if deemed necessary. So, the new service does not need to deploy new identities (and perhaps also new associated credentials) for delivering the new service. 3.12. Discovery of IP Address A problem that often arises is the discovery of the IP address and port number of the endpoint that eventually wants to receive notifications of event state. In SIP, User Agents (UAs) typically register with a SIP service provider. The registration process binds a SIP Address-Of-Record identity with a URI that resolves to the IP address of the user. Any other SIP User Agent or proxy can route towards a proxy that can get the IP address and port number of the UA where the user is logged in. 3.13. Support for Multiple Endpoints SIP contains built-in support for a user that is running a service in different devices. For example, the user can be subscribed to event state information from different endpoints, and receive notifications in several endpoints. On the other hand, a supplier of event state information can publish the state information from different sources; an event state compositor will merge the various inputs into congruent state data. 3.14. Independence of Data Source and Notifiers An advantage of SIP consists of the ability to separate sources of event state data and the notifier that handles subscriptions to such data. So, the source or sources of state need not be located in the same host where notifications are managed. For example, state agents publishes state information acquired from sources of state. 3.15. NAT traversal SIP provides an outbound mechanism [19] for easing the burden of firewall and NAT traversal of SIP messages. However, many NATs and firewalls requires a keep alive mechanism that keeps the state in those nodes alive. Sometimes the keepalive timer might be as short as 30 seconds. In this respect, having SIP as a single protocol for various usages allows to have a single keep alive mechanism shared by those different usages, as opposed to using two separated keep alive mechanisms for two different protocols. This becomes a benefit for Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 8] Internet-Draft SIP General Events May 2007 extending the battery life of battery-operated devices. 4. Discussion Several key aspects for providing new services have been evaluated in the previous sections. While in some cases it might be possible to deliver a service using alternative protocols, the SIP event notification framework provides in most cases a great deal of simplification by reusing many of the existing functions: security mechanism, authorization rules, composition rules, privacy mechanisms, and state agents. If the service has to be integrated with an existing SIP application, then SIP is usually superior in the evaluation of alternatives. RFC 3265 [2] indicates that the mechanism is not intended to be a general-purpose infrastructure for all classes of event subscription and notification. But it must be noted that the RFC provides no technical reasons for such restriction. However, on the other hand, we are not advocating for a general purpose event notification mechanism either, since we believe there are no compelling reasons for implementing the SIP event notification framework in every case (for example, we believe there are no reasons for implementing the framework in an Ethernet switch or a router). Instead, we advocate for a relaxation of the said constraint so that the SIP event notification framework can also be applied to more general events, such as those to be integrated in communication services, where the state to be reported is not directly related to SIP. That is the case for the proposals listed in Section 1. RFC 3265 [2] provides a discussion about the rate of notifications, indicating that the mechanism is not to be used in applications where the frequency of reportable events is excessively rapid (e.g., more than about once per second). It is believed that the proposals under discussion meet this criterion. Additionally, none of the proposed usages of the SIP event notification framework require any extension to the core SIP protocol or the SIP event notification framework. 5. Conclusion This document identifies a number of benefits when the SIP event notification framework is used to report non-SIP state related to communication services. We advocate for relaxing the restriction existing in RFC 3265 [2] that limits the usage of the SIP event notification framework to report SIP-related event state. Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 9] Internet-Draft SIP General Events May 2007 6. IANA Considerations This document has no actions for IANA. 7. Security considerations This document discusses the usage of the SIP event notification framework for reporting non-SIP state. The document itself does not define a protocol. However, certain security features of SIP are discussed throughout it. 8. References 8.1. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 8.2. Informational References [3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [5] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [6] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004. [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 10] Internet-Draft SIP General Events May 2007 [9] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [10] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [11] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [13] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [14] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [15] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 2006. [16] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [17] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. [18] Singh, V., "Vehicle Info Event Package", draft-singh-simple-vehicle-info-00 (work in progress), February 2007. [19] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-08 (work in progress), March 2007. [20] Tschofenig, H., "SIP SAML Profile and Binding", draft-ietf-sip-saml-01 (work in progress), October 2006. [21] Niemi, A., "Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling", draft-niemi-sipping-event-throttle-05 (work in progress), Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 11] Internet-Draft SIP General Events May 2007 March 2007. [22] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-09 (work in progress), March 2007. [23] Garcia-Martin, M., "A Framework for Sharing Resources with the Session Initiation Protocol (SIP)", draft-garcia-sipping-resource-sharing-framework-01 (work in progress), December 2006. [24] Garcia-Martin, M. and M. Matuszewski, "A Session Initiation Protocol (SIP) Event Package and Data Format for Describing Generic Resources", draft-garcia-sipping-resource-event-package-01 (work in progress), December 2006. [25] Niemi, A., "Session Initiation Protocol Event Packages for Calendaring", draft-niemi-sipping-cal-events-01 (work in progress), March 2006. [26] Mahy, R., "Sieve Notification Using the Session Initiation Protocol (SIP) Message Summary and Message Waiting Indication Event Package", draft-mahy-sieve-notify-sip-00 (work in progress), January 2007. Authors' Addresses Miguel A. Garcia-Martin Nokia Siemens Networks P.O.Box 6 Nokia Siemens Networks, FIN 02022 Finland Email: miguel.garcia@nsn.com Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 12] Internet-Draft SIP General Events May 2007 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York 10027 USA Phone: +1 212 939 7042 Email: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 13] Internet-Draft SIP General Events May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 14]