SIPPING Beck Internet-Draft T-Systems Nova GmbH Expires: June 20, 2003 December 20, 2002 SIP endpoint service charging requirements draft-beck-sipping-svc-charging-req-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 June 20, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Today, a SIP user wanting to charge for a service needs to establish an agreement with all prospective callers. This administrative overhead can be avoided if caller and callee can prove the duration and existence of a call in case of a dispute. The draft describes requirements for protocols and SIP extensions that can be used to implement such functionality. Beck Expires June 20, 2003 [Page 1] Internet-Draft SIP endpoint service charging requirements December 2002 1. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [1]. Beck Expires June 20, 2003 [Page 2] Internet-Draft SIP endpoint service charging requirements December 2002 2. Introduction The total cost of a call can be split into the following components: access flat fees for IP access, SIP proxy/registrar usage etc. bandwidth reservation Scaling issues have prevented the introduction of bandwidth reservation protocols in today's Internet. Such protocols will have their own accounting mechanisms. bandwidth usage With the deployment of DiffServ, usage sensitive billing will become more widespread. Accounting of DiffServ packets is done in routers and is outside the scope of SIP. However, a SIP proxy controlling a COPS [3] Policy Decision Point could prevent a customer from being flooded with expensive high priority packets. service provided by the callee Examples are PSTN-Gateways and support hotlines. Today, these services require an agreement between caller and callee before the first call is made. The costs and administrative efforts to handle the agreements limit the applicability of such schemes. There is no way to prove the existence or duration of a call. An ad-hoc way to charge incoming calls would allow to introduce new services and to replicate the PSTN's Premium Rate service. Providers of gateways, media and conferencing servers would profit from lower administrative costs. Ordinary end users could charge callers: instead of blocking spammer domains, solicitors could be charged with special fees for making calls ("pay for attention"). End users could charge callers and use the money to pay their own high-priority VoIP traffic. The rest of this document deals with the requirements for charging services provided by an endpoint. Beck Expires June 20, 2003 [Page 3] Internet-Draft SIP endpoint service charging requirements December 2002 3. Overall Requirements 3.1 Scalability and Reliability If third parties or intermediaries are needed to meet the requirements of this draft, the amount of state in those entities must be kept as low as possible. It MUST be possible to distribute the load on multiple entities without mirroring state. It SHOULD be possible for a client to recover within a few seconds when a third party or intermediary fails. 3.2 Cheap End Devices Some end devices have only limited CPU power and RAM space. A solution SHOULD either use this resources sparingly enough or SHOULD allow to delegate functionality to an intermediary. In the latter case the UA MUST use a secure transport protocol to contact the intermediary. Permanent storage in the UA MUST NOT be a prerequisite. A solution MUST be able to cope with device failures and network outages. 3.3 Mobile End Devices Wireless links often have limited capacity, high error rates and use small MTU sizes. Solutions SHOULD prefer protocols with short messages and few round trips. 3.4 Reuse of existing protocols and formats Existing cryptographic protocols and formats SHOULD be re-used wherever possible. To implement non-cryptographic functionalities, existing protocols and formats SHOULD be used, as long as no other requirements are violated. Beck Expires June 20, 2003 [Page 4] Internet-Draft SIP endpoint service charging requirements December 2002 4. Functional Requirements 4.1 Fairness The caller MUST NOT be able to repudiate the time and duration of a call. The callee MUST NOT be able to charge for calls that never happened. 4.2 Anonymity It MUST be possible for the caller to remain anonymous. Only in cases of dispute, a trusted third party should be able to reveal the real identity of the caller. 4.3 Expense Control The caller needs to know about the price of the service offered by the callee. It must either be possible to o allow the involvement of a trusted third party, which either provides the pricing information itself or records/signs the pricing information provided by the callee. o or allow the caller to set an explicit expense limit. The latter could be achieved by using signed tokens as in some micropayment protocols. If the session setup fails, the caller MUST NOT be charged. Furthermore, it must be possible to o immediately display the current rate to the caller o allow user-defined pricing schemes that depend on day time and contents of a SIP message (like From: header, To: header etc). o allow the calling UA to process the pricing information automatically Today's SIP can fulfill only some of these requirements: o The callee refers to his web page (eg. in a Call-Info header) or plays an announcement. However, in cases of dispute it will not be easy to prove the correctness of the web page or announcement. o The callee uses a Call-Info header that includes a URL pointing to Beck Expires June 20, 2003 [Page 5] Internet-Draft SIP endpoint service charging requirements December 2002 a trusted third party's web page. This web page displays the pricing information of the callee's service. This solution requires a web browsing capability in the UA. o The callee is reachable through a trusted third party that plays the announcement and refers to the callee's real UA (eg. by using the REFER method). This solution introduces additional setup delays. Neither web pages nor voice announcements can be processed automatically. 4.4 Accounting The callee's UA can easily record accounting data, like call duration and generated IP traffic. The question is whether the caller can trust the callee. 4.4.1 Evidence of session establishment The callee needs an evidence that a session has been established. In case of dispute, he can show the evidence and prove that a caller has really called. The evidence should contain the relevant details of the session (time, media etc). 4.4.2 Evidence of session teardown In case of dispute, the caller needs an evidence that a session ended at a certain time. As sessions can be terminated without any message exchange (eg. if a UA dies), the evidence generation is hard. The evidence of session teardown can be replaced with the evidence of an ongoing session. The session timer mechanism described in [4] uses this technique. In case of dispute, the evidence of session establishment and the evidence of session teardown show that there has been a session. To determine the accurate duration of the session the evidences need to be time-stamped by a trusted third party. Periodical evidences during a session have some advantages. The call duration can be derived from the number of evidences and no secure time source is needed. The evidence of session teardown needs no extra mechanism. However, there is a trade-off between the resolution of the call duration measurement and signaling bandwidth requirements. A cooperative callee will only charge for the exact call duration, though. Beck Expires June 20, 2003 [Page 6] Internet-Draft SIP endpoint service charging requirements December 2002 5. Security Considerations Some of the above requirement sections deal with security issues which are discussed there. Proven security mechanisms and protocols should be used wherever possible. Forging evidences MUST NOT be possible in reasonable time without specialized hardware or very large clusters. It MUST be possible to exchange security relevant parts of a solution with improved versions. If an implementations speaks to an older version it MUST either ask for user confirmation or reject the message. The user MUST be warned of bidding-down attacks. To avoid denial of service attacks, every stateful entity MUST authenticate clients before creating state. Beck Expires June 20, 2003 [Page 7] Internet-Draft SIP endpoint service charging requirements December 2002 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 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] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [4] Rosenberg, J. and S. Donovan, "Session Initiation Protocol Extension for Session Timer", draft-ietf-sip-session-timer-10 (work in progress), November 2002. [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [6] European Telecommunications Standards Institute, "Open Settlement Protocol (OSP) for interdomain pricing and usage exchange", ETSI TIPHON TS 101 321 v2.1.1 2000-08, August 2000. [7] Johnston, A. and D. Rawlins, "Session Initiation Protocol Private Extension for an OSP Authorization Token", draft-johnston-sip-osp-token-03 (work in progress), November 2002. [8] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. Author's Address Wolfgang Beck T-Systems Nova GmbH Am Kavalleriesand 3 Darmstadt 64295 Germany EMail: beckw@t-systems.com Beck Expires June 20, 2003 [Page 8] Internet-Draft SIP endpoint service charging requirements December 2002 Appendix A. TLS-based micropayment schemes Some web payment schemes use TLS (Transport Layer Security [5]) connections to a trusted third party. These schemes could be adopted for SIP: 1. The callee returns a https URI in a Call-Info header of a '402 Payment Required' response. The https URI points to a web page of a trusted billing service provider. The URI contains the callee's name, a service description, rates and a unique ID. 2. The billing service provider checks if the caller is able to pay. 3. The caller's UA starts a browser to display the billing service provider's web page which displays the callee's pricing information. The caller confirms his willingness to pay by clicking on a button. 4. The billing service provider redirects the caller's web browser to a SIP URI that contains cryptographically signed transaction data. The caller's SIP UA calls this SIP URI and the callee checks the cryptographic portion of it. If it is valid, the callee accepts the call. This procedure requires some interaction between UA and web browser. A web browser is not always present, though. Periodical small payments to limit the caller's risk are inconvenient. The billing service provider's web page can't be processed by a program that assists the user. Beck Expires June 20, 2003 [Page 9] Internet-Draft SIP endpoint service charging requirements December 2002 Appendix B. Evaluation of the Open Settlement Protocol The Open Settlement Protocol [6] is a promising protocol candidate. A trusted third party, the OSP server, hands out signed authorization tokens. The authorization tokens are a kind of ticket. Like a ticket, the token contains a lifespan information (valid-after, valid-until). OSP does not really record an evidence of session establishment. It records the fact that some user is willing to pay for a call. OSP is not involved in the call signalling itself. It can't provide an evidence of session teardown and is not able to verify the usage indications it receives. OSP allows periodic re-authorization that fits well into SIP's session timer mechanism. The OSP server can estimate the call duration by counting the re-authorizations. The settlement provider can use this estimation for billing if there is a significant difference between the caller's and the callee's usage indication. B.1 Example Message Flow 1. The caller requests a token from an OSP server (AuthorizationRequest, AuthorizationResponse). 2. The caller sends an INVITE to the callee containing the OSP token [7]. 3. The callee verifies the OSP token. If it is invalid or missing, the caller responds with "402 Payment required". If the token is valid, the callee accepts the call and responds with "200 OK". Beck Expires June 20, 2003 [Page 10] Internet-Draft SIP endpoint service charging requirements December 2002 Alice's UA OSP Server Bob's UA | | | +-- INVITE ---------------------------------->| | | | |<------------------- 402 Payment Required ---+ | | | +-- AuthorizationReq -->| | | | | |<- AuthorizationRes ---+ | | | | +-- INVITE (token) -------------------------->| | | | |<-------------------------------- 200 OK ----+ | | | +-- ACK-------------------------------------->| | | | | | | 4. If the callee does not trust the caller, he finishes the call when the caller's credit is used up. 5. To prevent the callee from dropping the call, the caller requests re-authorization from its OSP server and sends an INVITE or UPDATE message containing the new OSP token to the callee. Alice's UA OSP Server Bob's UA +- ReAuthorizationReq ->| | | | | |<- ReAuthorizationRes -+ | | | | +-- UPDATE (token) -------------------------->| | | | |<-------------------------------- 200 OK ----+ | | | +- ReAuthorizationReq ->| | | | | |<- ReAuthorizationRes -+ | | | | +-- UPDATE (token) -------------------------->| | | | |<-------------------------------- 200 OK ----+ | | | .. etc 6. After the call has finished, the callee sends a usage indication message to its OSP server. The usage indication does not only Beck Expires June 20, 2003 [Page 11] Internet-Draft SIP endpoint service charging requirements December 2002 contain information about the session duration, but also the OSP tokens received during the call. Alice's UA OSP Server Bob's UA | | | +-- BYE ------------------------------------->| | | | |<-------------------------------- 200 OK ----+ | | | +- UsageIndication ---->|<-- UsageIndication -+ | | | |<- UsageConfirmation --+- UsageConfirmation >| 7. The settlement provider who runs the OSP server derives a call detail record from the usage indications and the number of re-authorizations. B.2 Discussion Some open questions remain: o Is the OSP architecture scalable enough to handle requests of millions of SIP UAs? OSP was designed to operate with gateways, not with endpoints. Periodic OSP re-authorizations and SIP session refreshs will stress OSP servers and SIP proxies. o Is OSP too complex for small end devices? OSP uses HTTP, XML, S/ MIME and TLS. Many SIP devices already support HTTP for configuration purposes. S/MIME and TLS can be used for SIP as well. The memory and CPU requirements will be an obstacle for small and/or cheap end devices. o Will OSP extend setup delays? OSP uses simple request/response pairs in a TLS connection. If the UA and the OSP server keep existing TLS sessions open, the setup delay caused by TCP and TLS connection setup can be reduced. An expired draft (sinnreich-interdomain-sip-qos-osp-03) described an architecture where OSP was used to authenticate interdomain bandwidth reservations. This approach would not necessarily collide with the OSP usage outlined here. An INVITE would just carry two OSP authorization tokens, one for authorizing the bandwidth reservation and one for authorizing access to a non-free service. Beck Expires June 20, 2003 [Page 12] Internet-Draft SIP endpoint service charging requirements December 2002 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Beck Expires June 20, 2003 [Page 13] Internet-Draft SIP endpoint service charging requirements December 2002 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Beck Expires June 20, 2003 [Page 14]