SPEERMINT WGNetwork Working Group A. HouriInternet-DraftRequest for Comments: 5344 IBMIntended status:Category: Informational E. AokiExpires: December 3, 2008AOL LLC S. Parameswar Microsoft CorporationJuneSeptember 2008 Presence&and Instant Messaging Peering Use Casesdraft-ietf-speermint-consolidated-presence-im-usecases-05.txtStatus ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 3, 2008.this memo is unlimited. AbstractTheThis document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship betweenthemselvesthemselves, thus enabling their users to collaborate with users on the other Service Provider network. The target ofthethis document is to drive requirements for peering between domains that provide the non-VoIP based collaboration servicesandwith presenceandand, in particular, Instant Messaging(IM) in particular.(IM). Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3....................................................2 2. Use Cases. . . . . . . . . . . . . . . . . . . . . . . . . . 3.......................................................2 2.1. Simple Interdomain Subscription. . . . . . . . . . . . . 3............................2 2.2. List Based Interdomain Subscription. . . . . . . . . . . 4........................3 2.3. Authorization Migration. . . . . . . . . . . . . . . . . 4....................................3 2.4.PagePager Mode IM. . . . . . . . . . . . . . . . . . . . . . . 5..............................................4 2.5. Session Based IM. . . . . . . . . . . . . . . . . . . . . 5...........................................4 2.6. Other Services. . . . . . . . . . . . . . . . . . . . . . 5.............................................4 2.7. Federation&and Clearing House. . . . . . . . . . . . . . . 5..............................5 3.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4.Security Considerations. . . . . . . . . . . . . . . . . . . 6 5..........................................5 4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 7 6..................................................6 5. Informative References. . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10..........................................6 1. IntroductionTheThis document uses the terminology as defined in [1] unless otherwise stated. Real Time Collaboration (RTC) services have become as prevalent and essential for users on the Internet as email. While RTC services can be implemented directly by users in a point-to-point fashion, they are often providedforfor, or on behalfofof, a Peer Network of users within an administrative domain. As the use of these services grows, users increasingly have the need to communicate with users not only within their own Peer Network but with those in other Peer Networks as well (similar to the old Public Switched Telephony Network (PSTN) that enabled globalreadability).reachability). In practice, each Peer Network is controlled by some domain, and so there is a need to provide for easier establishment of connectivity between PeerNetworks,Networks and for the management of the relationships between the Peer Networks. This document describes a set of use cases that describe how peering between Peer Networks may be used innon Voice over IP (VoIP)non-VoIP RTC services. The use cases are intended to help in identifying and capturing requirements that will guide and then enable a secure and easier peering between Peer Networks that provide non-VoIP RTC services. The use cases for the VoIP RTC services are described in [2]. Note that this document does not define requirements for a new protocol or for protocol extensions. Itcaputrescaptures the way that presence and Instant Messaging are currently used within enterprises and operator domains. 2. Use Cases 2.1. Simple Interdomain Subscription Assume two Peer Networks, Peer Network A and Peer Network B. User Alice@example.com (hosted in Peer NetworkA),A) wants to subscribe to user Bob@example.net (hosted in Peer Network B) and get his presence information. In order to do so, Alice@example.com could connect directly to example.net and subscribe to Bob's presence information. However, Peer Network B is willing to accept subscriptions and route IMs only when they are coming from its users or from other Peer Networks that Peer Network B trusts. Inrealityreality, what will happen isthatPeer Network A will connect topeer networkPeer Network B andwillsend Alice's subscription to Bob via Peer Network B. Whenpeer networkPeer Network B has new information onBobBob, it will send notifications to Peer NetworkA thatA, which will pass them to Alice. 2.2.List BasedList-Based Interdomain Subscription This is similar to the simple interdomain subscription usecasecase, exceptthatin this case Alice subscribes to a Uniform Resource Identifier (URI) [8] that represents a list of users in Peer Network B [9][3][3]. There are several types of lists that Alice may subscribe to: o Personal group -Aa list thatwasis created and maintained by Alice and includes Alice's watch list. o Public group -Aa list that is created and maintained by anadministrator and is typically referred to as a public group.administrator. Public groups usuallycontainscontain a list of specific people that have some commoncharacteristic e.g.characteristic, e.g., support group of a company. o Ad-hoc group -Aa list that is short lived and is usually created inathe context of some activity that Alice is doing. An ad-hoc group may be created by Alice or by some application. Typical examples may be the list of people that participate with Alice in a conference or a game. 2.3. Authorization Migration If many users from one Peer Network watch presentities [6] in another Peer Network, it may be possible that many watchers [6] from one Peer Network will subscribe to the same user in the other Peer Network. However, due to privacy constraints that enable a user to provide different presence documents to different watchers, each Peer Network will have to send multiple copies of thewatched presencewatched-presence document. The need to send multiple copies between the Peer Networks is very inefficient and causes redundant traffic between the Peer Networks. In order to make the subscription between Peer Networks more efficient there needs to be a way to enable Peer Networks to agree to share privacy information between them. This will enable sending a single copy (the full copy) of the presence document of the watched user and letting the receiving Peer Networktobe responsible for sending the right values to the right watchers according to the delegated privacy policies of the watched users. Instead of sharingwatcher'sthe watched user's privacy policies between the Peer Networks, it is also possible to send different copies of the presence document with a list of the watchersthatthe presence document is intended for. For example, if there is a set of watchers inthe otherone Peer Network that may see the location of the presentity and another set of users in theothersame Peer Network that may not see the location information, two presence documents will besent, each one issent--each associated with a list of watchers that should receive it. One presence document will contain the location information and will be associated with a list of users that may seeitit, and the other presence document will not contain the location information and will be associated with a list of users that may not see the location information. See [11]. 2.4.PagePager Mode IM In this usecasecase, a user from one Peer Network sends apagepager mode [7] IM to a user on another Peer Network. 2.5. Session Based IM In this usecasecase, a user from one Peer Network creates a Message Session Relay Protocol (MSRP) [10] session with a user from another Peer Network. 2.6. Other Services In addition to VoIPsessionssessions, which are out of scope for thisdocumentdocument, only presence and IM have been ratified as RFCs. In addition to presence and IM, there are many other services that are being standardized or that may be implemented using minimal extensions to existing standards. These include: o N-way chat -Enableenable a multi-participant textual chat that will include users from multiple Peer Networks. See [4] for more details. o File transfer -Sendsend files from a user in one Peer Network to a user in another Peer Network. See [5] for more details. o Document sharing -Sharingsharing and editing a document between users in different Peer Networks. Note: Document sharing is mentioned in this document only for completeness of use cases. It is not being standardized by the IETF and will not be included in the requirementsdraftdocument that will result from this document. The list above is of course notexhaustiveexhaustive, as new developments in the world ofnon-VOIPnon-VoIP RTC will surface new services. Enabling peering between networks for some of the services will create a basis for enabling peeringalsofor futureservices.services also. 2.7. Federation&and Clearing House AFederationfederation as defined in [1] enables peering between multiple Peer Networks. A federation may be implemented by means of a central service providing a hub for the Peer Networks or, alternatively, Peer Networks may connect to each other in a peer-to-peer fashion. One of the most important services that this hub type of federation should provide is authorized interconnection that enables each Peering Network to securely identify other Peering Networks. Other services that might be provided include an N-way chat server, lawful interception,logginglogging, and more. This hub type of federation is also known as a "Clearing House". As non-VoIP services are usually text-based and consume less bandwidth, they may benefit from having a central service that will do central services such as logging for them. For example, instead of requiring each Peer Network to log all messages that are being sent to the other Peer-Network, this service can be done by the Clearing House. 3.IANA Considerations This document has no actions for IANA. 4.Security Considerations When Peer Network A peers with Peer Network B, there are several security issuesthatfor which the administrator of each Peer Network will need mechanisms to verify: o All communication channels between PeerNetworkNetworks and between each Peer Network and theclearing houseClearing House have their authenticity and confidentiality protected. o The other Peer Network is really the Peering Network that it claims to be. o The other Peer Network is secure andtrustfultrustworthy, such that information that is passed toit,it will not reach a third party. This includes information about specific users as well as information about the authorization policies associated with user information. o The other Peer Network is secure andtrustfultrustworthy, such that it will not modify or falsify data that it presents to its users except as required by the authorization policy provided. o If there is a third party(e.g.(e.g., aclearing house)Clearing House) involved in the connection between the two Peering Networks that element is alsoverified to besecure. The same issues of security are even more important from the point of view of the users of the Peer Networks. Users willhave the concern onbe concerned about how their privacy is being adhered to when their presence information isbeingsent to the other Peer Network. Users today are concerned about providing their email address to a third party when they register to a domain;Presencepresence contains much more sensitiveinformationinformation, and the concern of users here will be evendeeper.greater. The privacy issue is even harderifwhen we take into accountthatthat, in order to enable scalable peering between big PeerNetworksNetworks, there are some optimizations that may require migration of the privacy definitions of users between Peer Network (see Section 2.3). We can imagine the fiasco that would ensue if a user of one Peer Networkwill bewere able to see the privacy information andwilllearn he/sheareis listed inathe block list of a close friend. This document discusses use cases for peering between Peer Networks. It is out ofscope forthe scope of this document to provide solutions for security. Nevertheless, it is obvious that the protocols that will enable the use casesthat aredescribed here will have to provide for the security considerations also described here.5.4. Acknowledgments We would like to thank Jonathan Rosenberg, Jon Peterson, Rohan Mahy, Jason Livingood, Alexander Mayrhofer, Joseph Salowey, HenrySinnreichSinnreich, and Mohamed Boucadir for their valuable input.6.5. Informative References [1] Malas, D. and D. Meyer, "SPEERMINT Terminology",draft-ietf-speermint-terminology-16 (workWork inprogress),Progress, February 2008. [2] Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases",draft-ietf-speermint-voip-consolidated-usecases-08 (workWork inprogress),Progress, May 2008. [3] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP)Uniform Resource Identifier (URI)-ListURI-List Services",draft-ietf-sipping-uri-services-07 (workWork inprogress),Progress, November 2007. [4] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)",draft-ietf-simple-chat-02 (workWork inprogress),Progress, February 2008. [5] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer",draft-ietf-mmusic-file-transfer-mech-08 (workWork inprogress),Progress, May 2008. [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [7] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [9] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006. [10] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [11] Rosenberg, J., Donovan, S., and K. McMurry. "Optimizing Federated Presence with View Sharing", Work in Progress, July 2008. Authors' Addresses Avshalom Houri IBM 3 Pekris Street Science ParkBuilding 18/DRehovot, IsraelEmail:EMail: avshalom@il.ibm.com Edwin Aoki AOL LLC 360 W. Caribbean Drive Sunnyvale, CA 94089 USAEmail:EMail: aoki@aol.net Sriram Parameswar Microsoft Corporation One Microsoft Way Redmond, WA 98052 USAEmail:EMail: Sriram.Parameswar@microsoft.com Full Copyright Statement Copyright (C) The IETF Trust (2008). 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.