SIPPING K. Ono Internet-Draft NTT Corporation Expires: January 7, 2005 July 9, 2004 Discussion on Service Providers' Policies with the Session Initiation Protocol (SIP) draft-ono-sipping-providers-policy-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 7, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Some service providers who operate SIP proxy servers and registrars need to be able to express various types of policies to their customers, such as media policies and security policies. Discussion needs to take place about the types of policies and how they will have an impact on SIP User Agents (UA)s. This document presents an overview of the types of policies that might be available, and how the operations of policies might be executed to aid in advancing the current discussions on session policies. Ono Expires January 7, 2005 [Page 1] Internet-Draft Provider's Policies July 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Examples of Service Providers' Policies . . . . . . . . . . . 3 3. Policy Operations . . . . . . . . . . . . . . . . . . . . . . 3 4. A Mechanism of Operation #1: UAs disclose information that providers utilize to determine session-dependent policies. . . 4 5. A Mechanism of Operation #2: Providers instruct UA about the policies . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. A Mechanism of Operation #3: UAs comply with or don't comply with the policies . . . . . . . . . . . . . . . . . . . 5 7. A Mechanism of Operation #4: Providers verify that UAs follow the directives in the policies. . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Ono Expires January 7, 2005 [Page 2] Internet-Draft Provider's Policies July 2004 1. Overview Some service providers operate SIP [2] proxy servers and registrars to provide services, such as Voice over IP services and PSTN gateway services. Service providers sometimes place limits on which SIP UAs can connect to its network. However, to allow for interoperability among different SIP UA implementations and the provider's servers, it is necessary to notify SIP UAs of these policies. This document provides examples of a typical service provider's policies, including some that have not yet been discussed in the SIPPING WG. It also discusses possible operations for these policies that will have an impact on the operation of SIP UAs so as to get a better understanding of what session policies need to accomplish. 2. Examples of Service Providers' Policies We can classify the examples of policies into two categories: media policies and security policies. Session policy work [3] mainly focuses on media policies, and the e2m work [4] mainly focuses on security policies. o Media Policies * Codec restrictions * Call admission control for bandwidth management o Security Policies * User authentication for proxy servers * Information disclosure for dynamic firewall control * Information disclosure for logging services * Information disclosure for location-based routing 3. Policy Operations There are four operations that need to take place for providers' policies to be reflected on UAs, these are listed below. Operation #1: UAs disclose information that providers utilize to determine session-dependent policies. Operation #2: Provider's proxy servers instruct the UA about the policies. Operation #3: UAs comply with or don't comply with the policies. Operation #4: Providers verify that UAs follow the directives in the policies. Operation #1 is only required for session-dependent policies. If the policies are statically determined, such as user-by-user basis or for all users, operation #1 is not required. While the media policies have the possibility of being session-dependent and Ono Expires January 7, 2005 [Page 3] Internet-Draft Provider's Policies July 2004 session-independent, the security policies are always session-independent. So far in discussions on the mailing list and at the meetings, the WGs have discussed only operations #1 and #2. Operations #3 and #4 are out of scope of the session policies discussion, because only media proxy servers can execute operation #4. However, use cases described in [4] include Operations #3 and #4, because some of these use cases are done in signaling messages, where media proxy servers are not involved. An example is user authentication using HTTP digest authentication in SIP. 4. A Mechanism of Operation #1: UAs disclose information that providers utilize to determine session-dependent policies. This operation #1 is needed, if the media policies are dependent of session. There are two mechanism options for this operation, which are both UA driven. Since it is desirable to have the same mechanism to be consistent over the consecutive operations, option#2 which is congruent with the preferred option in operation #2 for the media policies is more desirable. Option #1: in-band * Discloses information in messages, such as INVITE/200 or UPDATE/ 200. * Requires security for end-to-middle, no matter where the information is set; a header or a body. Option #2: out-of-band * Discloses information in messages, such as PUBLISH or SUBSCRIBE/NOTIFY. * Requires the correlation with the session. * Requires new data definition that contains media attributes of a UAC and the UAS. * Requires end-to-end security. 5. A Mechanism of Operation #2: Providers instruct UA about the policies There are two mechanism options: proxy server driven and UA driven mechanisms. Policy servers are assumed to be co-located with proxy servers. Since option # 1 has several problems, option #2 is generally preferable. The media policies are changeable during a session. The lack of capability of dynamic notification could be a fatal problem Ono Expires January 7, 2005 [Page 4] Internet-Draft Provider's Policies July 2004 in option #1. Therefore, option #2 is preferable for the media policies. However, the problems do not come into play for certain use cases. For example, the security policies are not changeable during a session. Some use cases of the security policies are only applied only to a request message, that is to a UAC. Whether to utilize in-band or out-of-band as the preferred mechanism depends on the use cases of the security policies. Option #1: in-band * Instructs the policies by proxy server driven. * Requires a proxy server to return an error response or to add something to a response in order to notify a UAC. * Requires a proxy server to add something to a request in order to notify the UAS.[OPEN ISSUE] * Requires middle-to-end security to secure policy information. * Lacks of a capability of dynamic notification during a session. [OPEN ISSUE] * Discloses policies to other providers. [OPEN ISSUE] Option #2: out-of-band * Instructs the policies by UA driven. * Requires correlation with the session. * Requires end-to-end security. 6. A Mechanism of Operation #3: UAs comply with or don't comply with the policies There are two mechanism options for this operation, which are both UA driven. The media policies feedback on media streams between the UAs. Therefore, for the media policies, this operation, of course, is accomplished with out-of-band. For the security policies, whether to utilize in-band or out-of-band as a possible mechanism, depends on the use cases. For example, user authentication, logging services, and location-based routing are best done using in-band signaling messages, because information that effect the policies is conveyed within the signaling itself. Dynamic firewall control can be accomplished with either out-of-band or in-band, because information that effect the policies is conveyed separately. Option #1: in-band * Appropriate use cases that information that effect the policies is conveyed within the signaling. * Requires the end-to-middle security. Ono Expires January 7, 2005 [Page 5] Internet-Draft Provider's Policies July 2004 Option #2: out-of-band * Appropriate use cases that information that effect the policies is conveyed separately. 7. A Mechanism of Operation #4: Providers verify that UAs follow the directives in the policies. Media policies need media proxy servers to verify that media streams of the UAs follow the directives. In case of security policies, the proxy servers can reject to transfer the signaling messages unless the UAs follow the directives. This operation is accomplished with in-band. 8. Security Considerations This document does not introduce a new mechanism. 9. IANA Considerations This document requires no additional considerations. 10. Acknowledgments I would like to thank Gonzalo Camarillo, Volker Hilt, Cyrus Shaoul and Shida Schubert. 11 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] 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. [3] Rosenberg, J., "Requirements for Session Policy for the Session Initiation Protocol (SIP)", draft-ietf-sipping-session-policy-req-01 (work in progress), February 2004. [4] Ono, K. and S. Tachimoto, "Requirements for End-to-middle security in the Session Initiation Protocol(SIP)", draft-ietf-sipping-e2m-sec-reqs-03 (work in progress), July 2004. Ono Expires January 7, 2005 [Page 6] Internet-Draft Provider's Policies July 2004 Author's Address Kumiko Ono Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan EMail: ono.kumiko@lab.ntt.co.jp Ono Expires January 7, 2005 [Page 7] Internet-Draft Provider's Policies July 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ono Expires January 7, 2005 [Page 8]