SIPPING Beck Internet-Draft T-Systems Nova GmbH Expires: December 20, 2002 June 21, 2002 SIP endpoint service charging requirements draft-beck-sipping-svc-charging-req-00 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 December 20, 2002. 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 extension that can be used to implement such functionality. Beck Expires December 20, 2002 [Page 1] Internet-Draft SIP endpoint service charging requirements June 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 [2]. Beck Expires December 20, 2002 [Page 2] Internet-Draft SIP endpoint service charging requirements June 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 in today's Internet. Bandwidth broker architectures and core stateless queueing algorithms might change this in the future. Devices implementing bandwidth reservation 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. For example, callees could charge callers and use the money to pay their high-priority VoIP traffic. Or, instead of blocking spammer domains, solicitors could be charged with special fees for making calls. Gateway providers would profit from lower administrative costs. The rest of this document deals with the requirements for charging services provided by an endpoint. Beck Expires December 20, 2002 [Page 3] Internet-Draft SIP endpoint service charging requirements June 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 a call stateful proxy. In the latter case the UA MUST use a secure transport protocol to contact the call stateful proxy. 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 December 20, 2002 [Page 4] Internet-Draft SIP endpoint service charging requirements June 2002 4. Functional Requirements 4.1 Authentication Caller and callee MUST be able to authenticate each other. Non- repudiation is important if the callee is not well-known and trusted. SIP specifies the WWW-Authenticate/Authorization headers and S/MIME for authentication. S/MIME's public key signatures may be used to implement non-repudiation. 4.2 Pricing Information The caller needs to know about the price of the service offered by the callee. It MUST be possible to o allow the inclusion of a trusted third party, which either provides the pricing information itself or records/signs the pricing information provided by the callee 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 to protect the integrity of the pricing information from alteration o immediately display the current rate to the caller 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 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 Beck Expires December 20, 2002 [Page 5] Internet-Draft SIP endpoint service charging requirements June 2002 automatically. 4.3 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 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.5 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 [5] 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 December 20, 2002 [Page 6] Internet-Draft SIP endpoint service charging requirements June 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 December 20, 2002 [Page 7] Internet-Draft SIP endpoint service charging requirements June 2002 References [1] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. [5] Rosenberg, J. and S. Donovan, "SIP Session Timer", draft-ietf- sip-session-timer-08 (work in progress), October 2001. [6] Sinnreich, H., Johnston, A., Thomas, S. and D. Rawlins, "OSP Authorization Token Header for SIP", draft-johnston-sip-osp- token-02 (work in progress), October 2001. Author's Address Wolfgang Beck T-Systems Nova GmbH Am Kavalleriesand 3 Darmstadt 64295 Germany EMail: beckw@t-systems.com Beck Expires December 20, 2002 [Page 8] Internet-Draft SIP endpoint service charging requirements June 2002 Appendix A. Evaluation of the Open Settlement Protocol The Open Settlement Protocol (ETSI TIPHON TS 101 321) 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. A.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 [6]. 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 December 20, 2002 [Page 9] Internet-Draft SIP endpoint service charging requirements June 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 December 20, 2002 [Page 10] Internet-Draft SIP endpoint service charging requirements June 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. A.2 Discussion Some open questions remain: o Is the OSP architecture scalable enough to handle requests of billions 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 December 20, 2002 [Page 11] Internet-Draft SIP endpoint service charging requirements June 2002 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 assigns. 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 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 December 20, 2002 [Page 12]