INTERNET DRAFT Wolfgang Beck SIPPING Working Group T-Systems Nova draft-beck-sippping-billing-scen-00 28 March 2002 SIP billing scenarios 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 docu- ments 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 September 28, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract In contrast to other Internet services, most SIP sessions take place between individuals. Today's billing schemes (flat rate or volume based) do not reflect that. A caller causes costs on the callee's side. With SIP's authentication methods and few additional headers, a SIP billing service could be established that would enable callees to charge their callers. Call stateful proxies are not required. Beck Expires September 2002 [Page 1] Internet-Draft SIP billing scenarios 28 March 2002 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 [4]. Motivation How to mimic PSTN style billing with SIP is a frequently asked question. The lack of the centralized state makes billing diffi- cult. Today, Internet providers charge either a flat rate or by volume. Sender and receiver share the cost of a session. This is fair as long as both parties agree upon this. By accessing a web site, the user accepts the site returning a certain amount of traf- fic. The owner of the web site accepts the visitors causing traf- fic he is being charged for. With e-mail the situation is often different. This is known as unsolicited e-mail or spam. As with e-mails, so can unsolicited SIP calls be expected. By imposing a charge on the traffic caused by the caller, it is possible to limit unwanted solicitation. Furthermore, there are additional services such as access to PSTN gateways, non-free support hotlines etc, that require billing. Glossary BSP Billing service provider. A trusted third party that gathers call details and handles billing on behalf of callees BP Billing proxy. A proxy of a billing service provider authenti- cating and recording transactions. billing system A system that gathers transaction records from BPs and recon- structs call details. It does consistency checks to detect fraud. Requirements SIP follows the common internet design principles in maintaining call state in the end device. Billing should not change this. * Callers MUST be protected against false claims. Beck Expires September 2002 [Page 2] Internet-Draft SIP billing scenarios 28 March 2002 * Callers MUST be able to limit the cost associated with a SIP call to a certain callee. * Callees MUST be protected against repudiation of calls. * Billing MUST be possible across provider boundaries Creating and updating billing information in the end device has some security shortcomings. A trusted third party is needed that collects and verifies call details. A bullet-proof non-repudiation system is difficult to implement. However, it should be possible to achieve at least the non-repudiation level of today's PSTN. Collecting call data A callee willing to use a billing service accepts only transactions that have passed one of the billing service provider's proxies. The BSP's proxies send transaction details to a repository where the call details can be reconstructed. The proxies need not to be stateful. The BSP's proxy authenticates the callers with SIP mechanisms. Transactions originating from unknown proxies or UAs are not logged. They will not be forwarded but redirected. The callee can decide whether he accepts the call which the caller can not be charged for. The call details reconstructed from transactions of authenticated callers can be used for invoicing. * The call duration can be used for client billing * The call time and type can be used to find SIP sessions match- ing IP flow information collected by the callee's access router. If the callee pays for traffic volume, he can charge the caller using this data. If BSP and ISP are identical, this can be done by the ISP. The former scenario requires some agreement between callee and his BSP, the latter resembles today's PSTN billing. Other variations are possible. Cross domain operations Beck Expires September 2002 [Page 3] Internet-Draft SIP billing scenarios 28 March 2002 To make billing services scalable, an authentication hierarchy is required. * A call can be billed if there is an agreement between the caller and the callee's BSP * A call can be billed if there is an agreement between the caller's BSP and the callee's BSP. To limit the number of agreements between BSPs, a toplevel settle- ment instance would be useful. The agreement consists of authenti- cation data and bank account details. Determining the price The principle of least astonishment requires some pricing informa- tion to be included in SIP messages. Price Tag The UAS responds with a "402 Payment Required" containing a pricing information. The UAC sends a new INVITE if the user is willing to accept the indicated price. Budget Unit The UAC could include a budget limit header in the INVITE mes- sage saying: "I am willing to pay x $ per interval t". The UAS rejects the call if this limit is insufficient. The UAS's response contains a pricing information. If the UAS accepts the call, it monitors the UAC's budget. If the limit is reached, it sends a re-INVITE containing a new pricing information. If the caller responds with a "200 OK" containing the new bud- get, the call continues. The BSP records the call's transactions. Although re-INVITEs require additional bandwidth, yet it is quite fail-safe and allows billing schemes vary over time. [UPDATE instead of re-INVITE?] Additional schemes may be possible. Beck Expires September 2002 [Page 4] Internet-Draft SIP billing scenarios 28 March 2002 Security Considerations The billing service is a trusted third party that collects data about SIP transactions. The billing service is a component to pre- vent repudiation. Non-repudiation of Origin/Receipt The BP authenticates a UA or a different BSP's proxy with com- mon SIP mechanisms, like TLS, IPSec or digest. Non-repudiation of Delivery/Submission The delivery of the BYE message must be confirmed by the BSP. A UAC may construct BYE requests that will be seen by the BP but not by the UAS, eg. by choosing a low Max-Forwards value. However, the billing system can detect whether the UAS has received the BYE or not. Error responses such as "483 Too many Hops" or "482 Loop detected" show that a SIP device has dis- carded the message. To avoid packet loss, the remaining down- stream proxies MUST use reliable transport and they MUST have a trust relationship with the BSP. A UAC can circumvent the BP by sending requests directly to the UAS. A malicious callee can use this to pretend a long call dura- tion. It sends a BYE request directly to the UAS to terminate the real session and issues a BYE request to the BP later. The UAS responds with a "481 Call/Transaction does not exist". The calling UA can prevent such frauds in rejecting requests that were not authenticated by a BSP. The pricing information headers MUST be integrity protected. References [1] Handley, M., Schulzrinne, H, Schooler, E. and Rosenberg, J., "SIP: Session Initiation Protocol", Work In Progress, draft-ietf- sip- rfc2543bis-09.txt, IETF, February 2002 [2] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request for Comments 2246, Internet Engineering Task Force, Jan. 1999. [3] S. Kent and R. Atkinson, "Security architecture for the inter- net protocol," Request for Comments 2401, Internet Engineering Task Force, Nov. 1998. Beck Expires September 2002 [Page 5] Internet-Draft SIP billing scenarios 28 March 2002 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Acknowledgements Dariusch Shirinzadeh T-Systems Nova Author's Address Wolfgang Beck T-Systems Nova Am Kavalleriesand 3 64295 Darmstadt, Germany electronic mail: beckw@t-systems.com Beck Expires September 2002 [Page 6]