idnits 2.17.1 draft-rosenberg-stir-sipcoin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 2, 2018) is 2245 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Rosenberg 3 Internet-Draft C. Jennings 4 Intended status: Standards Track Cisco Systems 5 Expires: September 3, 2018 March 2, 2018 7 SIPCoin: A Cryptocurrency for Preventing RoboCalling on the PSTN 8 draft-rosenberg-stir-sipcoin-00 10 Abstract 12 Robocalling has become an increasing problem in the Public Switched 13 Telephone Network (PSTN). While techniques like verified caller ID 14 can help reduce its impact, ultimately robocalling will continue 15 until economically it is no longer viable. This document proposes a 16 new type of cryptocurrency, called SIPCoin, which is used to create a 17 tax - in the form of computation - that must be paid before placing 18 an inter-domain call on the SIP-based public telephone network. 19 SIPCoin maintains complete anonymity of calls, is non-transferable 20 between users avoiding its usage as an exchangeable currency, causes 21 minimal increase call setup delays, and makes use of traditional 22 certificate authority trust chains to validate proofs of work. 23 SIPCoin is best used in concert with whitelist based techniques to 24 minimize costs on known valid callers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 3, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Reference Architecture . . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Applicability of Traditional Cryptocurrencies . . . . . . . . 7 65 6. Applicability of Challenge Based Solutions . . . . . . . . . 8 66 7. Overview of SIPCoin . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. SIPCoin Roles . . . . . . . . . . . . . . . . . . . . . . 9 68 7.2. Creation and Maintenance of the Self Ledger . . . . . . . 9 69 7.3. Transaction Types . . . . . . . . . . . . . . . . . . . . 11 70 7.3.1. Create Transaction . . . . . . . . . . . . . . . . . 11 71 7.3.2. Burn Transaction . . . . . . . . . . . . . . . . . . 11 72 7.4. Closing Ledger Pages . . . . . . . . . . . . . . . . . . 12 73 7.5. Server Validation . . . . . . . . . . . . . . . . . . . . 13 74 7.6. Constructing Burn Receipts . . . . . . . . . . . . . . . 14 75 8. Usage of SIPCoin with SIP . . . . . . . . . . . . . . . . . . 15 76 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 16 77 9.1. Enterprise SIP Trunks . . . . . . . . . . . . . . . . . . 16 78 9.2. Inter-Carrier Trunks . . . . . . . . . . . . . . . . . . 17 79 9.3. Consumer provider to Mobile Phone . . . . . . . . . . . . 17 80 9.4. Target Model . . . . . . . . . . . . . . . . . . . . . . 18 81 10. Governance . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 11. Economic Analysis and Parameter Tuning . . . . . . . . . . . 18 83 11.1. Cost Targets . . . . . . . . . . . . . . . . . . . . . . 18 84 11.2. Impact of Compute Variability . . . . . . . . . . . . . 20 85 11.3. Load Analysis on the CAs . . . . . . . . . . . . . . . . 20 86 12. Alternative Consensus Techniques . . . . . . . . . . . . . . 21 87 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 13.1. Creating Additional SIPCoin . . . . . . . . . . . . . . 21 89 13.2. Burning a SIPCoin Multiple Times . . . . . . . . . . . . 22 90 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 91 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 92 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 16.1. Normative References . . . . . . . . . . . . . . . . . . 23 94 16.2. Informative References . . . . . . . . . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Problem Statement 99 Robocalling (also known as SPAM, voice SPAM, and so on) has become an 100 increasing problem in the Public Switched Telephone Network (PSTN). 101 Efforts to prevent it - such as the do-not-call list - have so far 102 proven ineffective. Recently, robocallers have gotten even more 103 crafty, and are tailoring the caller ID of incoming calls to match 104 the area codes and exchanges of the recipients in order to increase 105 the likelihood that targets pick up the phone. 107 This problem is not new, and ultimately the techniques for its 108 prevention have been known for some time. [RFC5039] outlines a 109 number of techniques for prevention of SPAM in Session Initiation 110 Protocol (SIP) [RFC3261] based systems. 112 Ultimately, SPAM calls are a matter of economics. Each call costs 113 the spammer a certain amount of money to perform. However, a small 114 fraction of calls produce a successful result, generating economic 115 returns. As long as the profit is positive, spammers will continue 116 and will likely work around legal hurdles, blacklists, reputation 117 systems, black lists, and so on. Consequently, the only true way to 118 end robocalling is to use economics - to make it no longer 119 profitable. 121 This can be achieved in two ways. One is by the exchange of actual 122 monies across all access and peering points in the public telephone 123 network. As the telephone network continues to grow, this becomes 124 increasingly difficult. Furthermore, it only requires a single point 125 of failure at one peering point, and calls have a way to enter the 126 network. Indeed, this is exactly why we see robocalling today 127 despite the fact that monies are in fact exchanged within the PSTN. 129 An alternative solution is to use computational puzzles, as described 130 in Section 3.9 of [RFC5039]. The original concept described there is 131 the a callee passes a computation test back to the caller, which 132 performs it, and then passes the results towards the callee. This 133 suffers from two problems. One, described in the document, is that 134 there is high variability in the computation capabilities of 135 individual calling devices and systems. Secondly, performing the 136 computation at call initiation time increases call setup delays. 137 This increase is likely to be large, owing to the amount of 138 computation required to act as an economic disincentive. 140 Consequently, the problem to be solved is to provide a system that 141 requires callers to demonstrate a proof of work towards callees in a 142 way which does not suffer these problems. Fortunately, in the 143 intervening years since the publication of [RFC5039], blockchain 144 technology was invented, and along with it, a wealth of 145 cryptocurrencies (BitCoin, Ethereum, etc). The goal is to apply 146 these technologies in a way to solve the unique requirements of the 147 problem at hand. 149 2. Reference Architecture 151 The reference architecture for SIPCoin is: 153 +----------+ 154 | Ledger | 155 | Server | 156 | | 157 | | 158 +----+-----+ 159 ^ 160 | 161 | Ledger 162 | Verification 163 | Protocol 164 | 165 | 166 a.com | b.com 167 +-----+------+ +------------+ 168 | Ledger | SIP | | 169 | Client +---------------^+ | 170 | | | | 171 |Call Agent | |Call Agent | 172 +------------+ +------------+ 174 +-+ +-+ +-+ +-+ 175 | | | | | | | | 176 +-+ +-+ +-+ +-+ 178 In this architecture, users associated with one call agent 179 (representing a.com) wish to communicate with users associated with a 180 different agent, reachable through b.com, using the Session 181 Initiation Protocol (SIP) [RFC3261]. The b.com agent wishes to gate 182 incoming calls based on proof of computational work provided by the 183 a.com call agent. To perform this, the a.com agent implements the 184 client component of the Ledger Verification Protocol (LVP). In LVP, 185 clients - in this case embedded into the call agent - perform hashing 186 operations, and maintain a self-generated ledger of transactions. To 187 validate pages in the ledger, the ledger client accesses a ledger 188 server through LVP. Through this protocol, the ledger client can 189 obtain information to include int the SIP INVITE. A call agent will 190 typically implement many instances of the ledger client, since each 191 instance has an upper bound on the amount of calls per second it can 192 perform. 194 In this architecture, there are two call agent roles - the generating 195 agent and the receiving agent. Though, in the picture as shown, they 196 represent the registrar of record for the caller and callee 197 respectively, this need not be the case. Rather, the two roles can 198 be implemented at differing paths along the actual call setup, and 199 indeed occur multiple times along the call. Later sections in this 200 document map the architecture to recommended points of physical 201 implementation. 203 3. Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 Generating Agent 210 The SIP proxy, user agent or B2BUA which wishes to demonstrate 211 proof of work in order to pass a call downstream towards a 212 receiving agent which will ultimately validate the proof of work. 214 Receiving Agent 215 The SIP proxy, user agent or B2BUA which will only accept incoming 216 calls under demonstration of proof of work. 218 4. Requirements 220 o Unlimited Participants: The system must allow for an unlimited 221 number of call agents to participate. New agents should be able 222 to come and go on demand. This allows the system to extend to 223 agents representing carriers, enterprises, home networks, and so 224 on. 226 o Low Latency: The system should not significantly increase the call 227 setup delay for calls. This is a big constraint, since it means 228 that proof-of-work computations must be performed in advance of 229 placing the actual call. One to two seconds is acceptable, but 230 not more than that. 232 o Privacy Protection: There must not be any sharing of logs of 233 calls, personally identifiable information (PII), phone numbers, 234 or similar information. Sharing includes passing this information 235 between entites which would otherwise not have access to it, or 236 storing it in some kind of ledger. 238 o Non-Transferrable: Any currency used for placing calls must be 239 limited in scope to only allow placing of calls, and not be 240 transferrable amongst participants in the system, or exchangeable 241 for traditional or crypto currencies. This is a significant 242 requirement since it rules out all existing cryptocurrencies by 243 definition. Why is this requirement important for this use case? 245 * Enable small players: SIP was designed to enable an open 246 interconnection amongst anyone on the Internet. A SIP domain 247 can be a single device supporting a single user. It can be a 248 home network. It can be a small business. It can be a large 249 enterprise. It can be a small telco, a large telo, or a 250 massive global provider. In order to enable the most open 251 access possible, barriers to entry must be small. 252 Consequently, we want to retain the property of SIP that a two 253 person domain can install an open source SIP server, and be off 254 and able to make calls. Transferability would mean that the 255 currency has real value, and thus to operate a system, the 256 agent must be able to connect to currency exchange systems, 257 payment processing platforms, and so on, in order to obtain the 258 currency before being able to place the first call. This makes 259 it difficult for small players to participate. 261 * Fraud: The entire purpose of this system is to prevent 262 fraudulent entities from placing calls into the global SIP 263 network. If it was based on transferrable cryptocurrencies, it 264 would likely be susceptible to fraud and thus benefit the very 265 entities we are trying to stop. 267 * Managed Costs: Today's cryptocurrencies have highly variable 268 exchange rates, sufficiently variable that they are difficult 269 to use as a payment vehicle, and even more difficult to use for 270 microtransactions. However, that is exactly the opposite of 271 our case - we require high volume, extremely low cost 272 microtransactions, at a price point which hits a particular 273 operating point that is just high enough to make it 274 unprofitable for spammers yet not overly expensive for real 275 callers. Consequently, by tying the cost strictly to the price 276 of computation, we reduce (though certainly do not fully 277 eliminate!) the risks of highly variable currency and allow for 278 relatively low cost microtransactions. 280 o Non Privileged: The system should not require centralized entities 281 to have access to telecom databases or other information which 282 requires governmental or regulatory access. This constraint in 283 the system makes it incrementally deployable without waiting for 284 the centralized bureaucracy of telco operations. Any centralized 285 capabilities must be an easy incremental add to existing services 286 (e.g., a change to current cerificate authorities). 288 o Phone Numbers or SIP URI: The system should not require phone 289 numbers to operate. It should work with traditional domain-based 290 SIP URI as tell as tel URI phone numbers. 292 o Predictable Cost: The system must enable a call agent to perform a 293 certain amount of computation and be able to predict the amount of 294 calling which it can perform for a given amount of computation 295 performed in advance of the call. Without this property, an agent 296 runs a risk it cannot service real-time requests for calls from 297 its users because it doesn't have enough crypto currency. This 298 property is related to the non-transferability requirement; if the 299 crypto currencies were transferrable, an agent could instantly 300 purchase crypto currency to place a call. Without 301 transferability, predictable computation is required to ensure the 302 ability to place a call. 304 o Managed Governance: Since adjustments will need to be made in the 305 computational costs required, the system must support a managed 306 governance model under the authority of a standards body, such as 307 the IETF or ITU. 309 5. Applicability of Traditional Cryptocurrencies 311 One immediate question is - why not just use Bitcoin or one of the 312 other crypto currencies? This would be easy to do. Each SIP INVITE 313 would contain a reference to a transaction that passes the required 314 costs from the caller to the callee. 316 Putting aside for a moment the non-transferability requirement - 317 which rules out all existing cryptocurrency - other requirements make 318 Bitcoin and similar cryptocurrencies non viable. 320 Firstly, they fail on the privacy requirement. Usage of Bitcoin 321 would require transactions in the ledger to identify the caller and 322 called parties, thus leaking information about who is calling who. 324 Secondly, the systems do not provide predictable or managed costs, 325 which are essential for this application. The cost of Bitcoin is 326 highly variable, and subject to (sometimes wild) market swings. 327 These costs cannot be managed by any consensus organization, and 328 indeed the cost may collapse entirely, completely destroying the 329 benefit of the system. 331 Finally, Bitcoin is too slow. It, and similar cryptocurrencies, rely 332 on ledgers which post infrequently, causing transactions to take 333 minutes or even hours to eventually post and be verified. This 334 system requires a transaction - the spending of a coin to place a 335 call - to happen fast enough that it can be spent by the caller, and 336 verified by the callee, within one to two seconds. 338 6. Applicability of Challenge Based Solutions 340 The second question to ask is - why not just have the callee 341 challenge the caller to perform a computational puzzle at time of 342 call setup, and the caller returns the results? 344 The primary problem with this class of solution is the time it takes 345 to perform enough computation to serve as an economic disincentive 346 for placing spam calls. To get a general feel for the costs using 347 modern compute, consider Amazon EC2 on demand pricing. For a middle 348 of the road compute optimized node - say - the c4.large instance - as 349 of February 25, 2018, Amazon is charging USD 10 cents per hour (.0027 350 cents per second) of computation for an instance in US East. We can 351 imagine that our goal for disincentivizing an attacker is somewhere 352 between a .1 cent per call, and perhaps as high as a 10 cents per 353 call, this would require computation on this particular instance type 354 of between 37 seconds (for .1 cent of cost) and 1.01 hours (for one 355 dollar). 357 Of course, modern Bitcoin mining no longer uses CPUs or even GPUs for 358 that matter, but rather ASICs. Though these can perform far more 359 computation per unit time interval than a CPU for specialized 360 hashing. However, the raw cost per hour of operation - regardless of 361 the amount of computation that can be performed - is the question at 362 hand for analyzing the viability of a challenge/response approach. 363 ASIC and GPU based systems are higher cost per hour to operate due 364 largely to their scarcity. [[OPEN ISSUE: hmm, not sure this argument 365 works owing to asymmetry issues]] 367 37 seconds - and certainly one hour - is far too long to wait before 368 a call can be forwarded to the called party. For this reason, this 369 class of technique does not work. The solution requires the 370 performance of the computation ahead of the call. 372 [[TODO: go through all EC2 instance types, price out a more 373 normalized compute cost - dollars per Ghz per hour. Such a metric 374 normalizes against number of CPUs as well as variations in the 375 performance of the CPUs.]] 377 7. Overview of SIPCoin 379 This section provides an overview of SIPCoin, a new cryptocurrency 380 used for placing SIP calls over the global SIP network. 382 SIPCoin differs from Bitcoin significantly in that it does not rely 383 on completely decentralized trust. Rather, it bootstraps itself on 384 the existing certification authorities which power the modern web. 385 As such, the system has two distinct actors - clients, and servers. 386 Clients are entities which perform computation in order to create 387 SIPCoins, and then "burn" those coins in order to place a call. 388 Consequently, SIPCoin supports only two types of transactions - a 389 "create" transaction which creates a Bitcoin through the solution of 390 computational puzzles, and then a "burn" transaction which destroys a 391 coin by binding it to a particular SIP call. Since the create and 392 burn transactions are localized - they affect only the client itself 393 - there is never a need for sharing of the ledger. Consequently, 394 clients actually maintain their own ledgers for these transactions, 395 as described below. A client needs to provide proof that it has 396 burned a token; that proof is performed with a different object - a 397 Burn Receipt - constructed by the client using data returned from the 398 server. 400 7.1. SIPCoin Roles 402 Clients are uniquely identified by their public key. There is no 403 need for a certificate to be associated with the public/private key 404 pair. Indeed, typically a single administrative entity - such as a 405 telco operator - would have hundreds or thousands of clients, each 406 with its unique public/private keypair. An administrative entity can 407 create and destroy client instances at will, without any centralized 408 configuration or provisioning. 410 Servers - typically run by, or co-resident with certificate 411 authorities - are responsible for verification of ledger pages 412 created by clients, and issuing of data needed by clients to 413 construct burn receipts for coins that are verifiably burned on the 414 ledger. The protocol puts the burden of storage of all ledger 415 information entirely in the hands of clients, such that servers 416 require a tiny amount of storage per client. Since servers are run 417 by certificate authorities, their verification of ledger pages and 418 issuance of data to construct burn receipts relies on their private 419 keying material, trusted by all other actors. 421 7.2. Creation and Maintenance of the Self Ledger 423 Each client is responsible for maintenance of a ledger of its own 424 create and burn transactions, the only two types of transactions 425 permitted in the system. The ledger is broken into a series of 426 pages. The client posts transactions into the current page of the 427 ledger, called the active page. Each page starts with a page key, 428 which is a hash of the prior page, forming a chain. Following the 429 hash are a series of transactions. The pages prior to the active one 430 will all - through the LDP protocol - be signed by the server. These 431 pages are called closed pages, and the server's signature over the 432 page forms the final element in a closed page. The client is 433 responsible for storing the prior pages in the ledger persistently. 435 Clients do not need to maintain prior pages indefinitely. Recall 436 that each page is composed of a series of create and burn 437 transactions. For a particular page, a client can delete a page from 438 storage when all of the following conditions are met: 440 1. All the prior pages have been deleted 442 2. All of the create transactions in the page have been burnt in a 443 subsequent page which has been closed 445 3. All of the Create transactions in the page have a subsequent 446 Create transaction in a page which has been closed 448 In essence, the client maintains a sliding window of pages, with the 449 tail being the current active page, and the head being the newest 450 page that still contains an unburnt coin or Create transaction that 451 formed the seed of the hash for the current, in-progress one. 453 The client is required to maintain these pages because they will need 454 to be presented to the server to sign the current page, transitioning 455 it from active to closed. 457 If a client should lose its pages, it forfeits any coin which it may 458 have created. This is a significant difference compared to 459 traditional Bitcoin, which uses a distributed storage system to 460 provide a global ledger based on consensus, shared by all 461 participants. In SIPCoin, there are many parallel ledgers, and each 462 is stored locally only to that participant. This also means that all 463 partiicpants in SIPCoin can mine coins; it is not a competition. 464 Competitive mining favors the largest and most invested players, 465 preventing others from being able to mine at all, in some cases. 466 Since it is not possible to transfer SIPCoin, such a situation would 467 mean that a SIP entity might not be able to place a call since it 468 never won a lottery. 470 When a new client is created by an administrative entity, it needs to 471 begin a new ledger. Each ledger and ledger page must be unique, 472 ensureing that the proof of work transactions on one ledger cannot be 473 copied into any other ledger. To create a new ledger, the client 474 transacts with the server to obtain a first page. The first page is 475 signed by the server - like all other pages. However, unlike 476 subsequent pages, it contains no transcations - just a page key. The 477 server will choose a crypto-random value for the page key, ensuring 478 that no two ledger pages start with the same value. 480 7.3. Transaction Types 482 SIPCoin supports only two types of transactions that can be placed 483 into the ledger. These are the create transaction and the burn 484 transaction. 486 7.3.1. Create Transaction 488 The create transaction is composed of the following elements: 490 1. The challenge. This is a number that forms the seed of the 491 hashing. For the first transaction in a page, the challenge is 492 equal to the page key. For all subsequent create transactions, 493 the challenge is a hash of the prior Create transaction in the 494 ledger. 496 2. The solution. This is a number which demonstrates that the proof 497 of work has been done. Each proof of work is a hash function 498 Ht() which takes as input two numbers, and returns a hashed 499 result. The proof is demonstrated by providing a value S for the 500 solution which, when hashed with the challenge C, forms a result 501 H(S,C) which has N_Zero consecutive zeroes in the result. N_Zero 502 is a global configuration parameter, and is discussed in more 503 detail later on. Its adjustment is a principle part of the 504 governance of the operation of SIPCoin. 506 3. The Coin ID: This is computed by the client as a hash over its 507 public key, the challenge, and the solution. It serves as a 508 unique identifier for the Coin produced by this create 509 transaction. 511 7.3.2. Burn Transaction 513 The Burn transaction is created by the client when it wishes to place 514 a SIP call. Consequently, each burn transaction is bound with a SIP 515 INVITE. To perform this linkage, the burn transaction is composed of 516 the Coin ID (obtained from a prior create transaction for an unspent 517 coin) along with a hash over several fields of the SIP INVITE. The 518 fields incude the From, To, Call-ID and fields from the SDP, such as 519 media encryption keys. The hash also includes the timestamp for the 520 burn transaction. 522 Beacuse the burn transaction is a hash over these various parameters, 523 when it is sent to the server for signature, the server has no way to 524 invert the hash. Consequently, the server learns nothing about the 525 originator of the call, the recipient of the call, the type of media 526 in the call, or anything else. All that the server learns is that a 527 call was placed, and that it was placed by the administrative entity 528 that has a relationship with the server. This does mean that 529 servers, through the observation of burn transaction rates, will know 530 the call volume being emitted by the entity, but thats it. 532 The SIP agent running the client will not be able to send the SIP 533 INVITE until it has received a burn receipt from the server. In 534 essence, it needs to hold the INVITE until the ledger page is 535 complete. For this reason, in SIPCoin, ledger pages close very fast. 536 A client can post a ledger page for closure at a frequency on the 537 order of one every 250ms to 500ms. 539 7.4. Closing Ledger Pages 541 A client closes the active ledger page when one of two conditions is 542 met: 544 1. The ledger page contains N_trans transactions in it 546 2. The client requires a burn receipt for a burn transaction on the 547 page, and it has not posted a ledger to the server within the 548 last T_min seconds 550 A client is not required to close a ledger every T_min seconds; if it 551 has no pending burn transactions in the ledger (only creates), it can 552 wait. T_min specifies the minimum interval, and it is nominally 553 enforced on the server to ensure the server is not overloaded. 555 To actually close the page, the client signs the active page with its 556 public key, and then transmits the active page to the server, along 557 with the public key. The first time it closes a page, it will also 558 need to post all closed pages to the server. The server will 559 validate the transactions in the current page, including insuring 560 that the client has not double burnt the same coin. That particular 561 check requires the server to have all active pages for the client, 562 which is why they must be sent. 564 Once the server performs its checks, it will send back a signed 565 version of the page, closing it. This enables the client to start a 566 new active page in the ledger. The server also returns a signature 567 over the now-closed page, using its trusted certificate. 569 The server also returns a signed hash, described below, that allows 570 the client to compute burn receipts for each SIPCoin that was burned. 572 7.5. Server Validation 574 The server follows a standardized process for validating the page 575 submitted by the client. At a high level, it composes the following 576 steps: 578 1. The server authenticates the client; typically this is done using 579 an administrative credential for the administrative entity 580 responsible for the client. [[NOTE: Use ACME techniques for 581 this??]]. LVP technically speaking does not require the server 582 to actually authenticate the client if it chooses not to. 584 2. The server checks the signature on all pages sent by the client 585 to ensure that they have been signed by itself. 587 3. The server validates that the pages form a sequential chain. It 588 starts at the first page, computes it hash, and ensures that the 589 result matches the page key of the subsequent page. 591 4. The server keeps stored, for each unique client (as indexed by 592 public key), the hash of the most recently signed active page 593 from that client, thus closing it. It checks that the active 594 page that is to be signed is the successor, by comparing the page 595 key in the active page to the stored value. This prevents 596 malicious clients from forking the ledger and placing the same 597 burn transaction, but for different INVITEs, into each fork. 599 5. The server examines every burn transaction in all pages sent by 600 the server, and makes sure it matches exactly one create 601 transaction. This ensures that the server has received all pages 602 from the client (omission of a page from the client would enable 603 it to double burn). 605 6. The server processes the transactions in order in the active page 606 which is to be signed. If a transaction is ia create 607 transaction, it verifies that the challenge is either the page 608 key (for the first ever Create transaction) or the hash of the 609 prior Create transaction in the ledger otherwise. The server 610 stores, indexed by the public key of the client, the hash of the 611 most recent Create transaction. It verifies this Create 612 transaction has used that value as the challenge. It then takes 613 H(), and uses it with the challenge and solution values. It 614 verifies that the result has N_zero consecutive zeros. It then 615 hashes the client public key with the challenge and solution, and 616 makes sure it matches the Coin ID. If the transaction is a burn 617 transaction, the server takes the CoinID and searches through all 618 burn transactions in all pages sent by the client, and makes sure 619 it doesnt match the Coin ID in any other burn transaction. 621 Once these validation steps pass, the server generates a signature 622 over the active page using its certificate. It then stores the hash 623 of this closed page to enable it to validate the next one, and stores 624 the hash of the last Create transaction in the page to validate the 625 next Create transaction. 627 To enable the client to create and send burn receipts, the server 628 computes a balanced binary merkle tree, where the leaf nodes in the 629 tree represent the Burn transactions from the page which was just 630 closed. The head of the merkle tree is the signed by the CA with its 631 private key. The signed head is returned to the client, along with 632 the signed page that was just closed. 634 For purposes of performance optimization, the server can elect the 635 cache the inactive pages, avoiding the need for the client to resend 636 them each time. To do that, the server stores the pages and 637 generates a cache key, which is an opaque parameter chosen by the 638 server. The client, in subsequent validation requests, can include 639 this key. It can then be used by the server to route those requests 640 to the server instance which is holding the cache, and then used to 641 extract the cached pages indexed by that key. If the server has a 642 cache miss, it can reject the request and force the client to 643 resubmit all its inactive pages. 645 7.6. Constructing Burn Receipts 647 To construct burn receipts, the client computes the merkle tree 648 identically to the algorithm used by the server. It then verifes the 649 signature over the head. This will normally be valid, since the CA 650 is trusted in this architecture. The burn receipt for a SIPCoin is a 651 digital object composed of: 653 1. All of the nodes in the merkle tree, starting at the leaf for the 654 burn transaction for the coin in question, to the head of the 655 tree. 657 2. For each node in the list above, the sibling of that node. 659 3. The signature over the head, as provided by the server. 661 This object is readily verified by having the receiving call agent 662 hash upwards through the merkle tree and compare the result against 663 the signature on the head. This burn receipt is included in the SIP 664 INVITE. The usage of a merkle tree reduces the number of signing 665 operations at the CA and also reduces the amount of data that must be 666 transferred back to the client. 668 8. Usage of SIPCoin with SIP 670 The usage of SIPCOin with SIP is relatively straightforward. We say 671 that a "SIPCoin is included in the INVITE" when the INVITE includes a 672 Burn receipt for that coin; in this architecture coins are not 673 actually transfer, only proof of their destruction. SIPCoins can be 674 included in a SIP INVITE proactively with a Burn receipt, or they can 675 be inserted reactively at request of the receiving agent. Its 676 easiest to understand through the reactive flow. 678 The generating agent sends an INVITE normally, without any SIPCoin in 679 it. This arrives at the receiving agent. Ideally, the receiving 680 agent will verify the caller ID (see [draft-rosenberg-stir-callback] 681 for a solution to enable this to occur). Once verified, the 682 receiving agent checks whether the caller is known to be acceptable 683 to the called party. The definition of acceptable is a matter of 684 local policy and depends on the physical entities performing the 685 receiving agent role, as discussed below. 687 If the caller is acceptable, the call is passed to the called party. 688 If the nature of the caller is unknown (which is again a matter of 689 local policy), the receiving agent rejects the INVITE with a response 690 code 4xx which challenges for SIPCoin in order to accept the call. 692 When this is received at the generating agent, it constructs a new 693 INVITE, burns a coin, constructs the burn receipt, and places those 694 into the INVITE. This passes to the same receiving agent. If the 695 caller ID is verified (whcih would have been done from the prior 696 step) and it continues to be unknown, the receiving agent validates 697 the burn receipt. 699 To validate it, the receiving agent performs the hashing through the 700 merkle tree and verifies the signature on the hash at the top. The 701 certificate verification requires the generating and calling agents 702 to share a common trust anchor. This specification mandates that all 703 agents trust the same set of CAs present in the Mozilla Firefox 704 browser. This allows SIPCoin to be rooted in a well vetted, 705 continuously maintained set of trust anchors which is proven to work 706 globally. 708 If the signature is valid, the receiving agent considers the burnt 709 coin as a sufficient proof of work to allow the call to proceed to 710 the called party. 712 In the proactive model, which can be used by the caller to speed up 713 call setup if they desire, they burn a SIPCoin prior to the challenge 714 and include it in the INVITE straight away. 716 9. Deployment Considerations 718 There are many ways in which SIPCoin can be used. And in fact, the 719 hardest part of rolling out a solution like SIPCoin is handling the 720 intermediate states where it is only partially deployed on the 721 Internet. This document proposes a phased rollout where each step is 722 motivated by economic benefit to the parties at hand. 724 9.1. Enterprise SIP Trunks 726 The easiest deployment topology, and the best way to start, is on SIP 727 trunks between a customer and their provider. In this model, the 728 generating agent is that of the administrative entity which is using 729 the SIP trunk, and the receiving agent is that of the provider. 730 These are adjacent agents connected by a single SIP hop. As an 731 example, the generating agent could be an enterprise, and the 732 receiving agent would be a traditional telco offering enterprise SIP 733 trunks. This would also be combined with the reverse role, where the 734 service provider also runs a generating agent and the enterprise runs 735 a receiving agent. 737 This arrangement provides a value proposition for the enterprise to 738 protect itself from inbound spam calls which are received through 739 their SIP trunk provider. If the spammer is another enterprise 740 customer of the same provider, that enterprise becomes disincented 741 from spamming due to costs. If the spammer is farther away - and in 742 this phase they are most likely to be - the SP eats the cost and 743 genreates the SIPCoin. 745 In such a service model, the service provider would - through its 746 bilateral relationships with its customers, insist its customers 747 implement the Outbound SIP Trunk role. As a result, the service 748 provider itself would not need to generate SIPCoin for intra-provider 749 calls. However, it would genreate them for inter-provider calls. 750 This provides a benefit to the enterprise, who are now protected from 751 spammers connected to the same SP, and the fact that the SP creates 752 and burns calls for transit calls means that the enterprise gets the 753 benefit of only ever accepting inbound calls which have SIPCoins 754 burned. 756 In this model, the SP can save itself money in one of two ways. 757 Firstly is through whitelisting. As part of the SIP trunk 758 specification, enterprises on the receiving side should maintain a 759 database of callers they 'trust'. A caller ID is trusted if the 760 caller ID has been verified [draft-rosenberg-stir-callback], and the 761 enterprise had previously, in the last few weeks, placed multiple 762 calls to that number, those calls having connected and had a duration 763 of at least a few minutes. This provides a simple model of: I'll 764 trust your inbound call if I've called you previously. The 765 enterprise PBX can also use contact lists from employees contianing 766 phone numbers to populate this list. 768 This means the SP cost is reduced for trusted callers, and not for 769 others. To further reduce costs, the SPs are incented therefore to 770 establish bilateral peering with each other over Inter-carrier 771 trunks. 773 9.2. Inter-Carrier Trunks 775 These work identically to the enterprise SIP trunks; the carriers on 776 each side of an inter-carrier peering link implement both the 777 generating and terminating roles of the call agents. When a 778 terminating enterprise challenges its SP for a coin, if the call 779 arrived via an inbound trunk from another carrier, the SP can 780 propagate the request for a coin upstream to save itself costs. If 781 the upstream provider doesnt support SIPCoin, the SP must burn the 782 coin itself, creating costs, and thus incentive for each side to 783 insist on implementation to reduce costs. 785 In this way, SIPCoin implementations propagate outwrads, ultimately 786 reaching the originating carriers for consumer services and 787 enterprises. This brings us to the final phases. 789 9.3. Consumer provider to Mobile Phone 791 This specification recommends that the terminating role be 792 implemented in smartphones implementing the IMS specifications. 793 Consider now an enterprise which placed a call towards a consumer 794 mobile phone. This call is received at the terminating mobile 795 provider. Since it knows that the mobile callee SIP UA supports 796 SIPCoin (from the SUpported header field in the REGISTER), it 797 propagates the INVITE towards the called phone after verifying the 798 caller ID. The callee, seeing that the caller ID is verified, checks 799 its local contact list. If the caller is on the contact list, it 800 doesnt challenge for coin. If it isnt, it challenges for the coin. 801 This propagates all the way back to the originating enterprise, which 802 burns a coin to place the call, which is then accepted by the callee. 804 The generting role is not appropriate for implementation on mobile 805 phones, and as such the consumer mobile operator cannot pass its 806 costs upstream. However, as part of bilateral peering arrangements 807 and standards coordination, the SP can insist that each other require 808 their mobile phones to comply with the specs that mandate 809 implementation of the terminating role. That will save each other 810 money in proportion to the balance of their inbound to outbound 811 calls. 813 This then provides the final economic incentive to achieve the target 814 architectural model. 816 9.4. Target Model 818 In the idealized model, the terminating role is implemented by the 819 receiving phones, and the generating role implemented by the call 820 agents operating on their behalf. The entire SIP core network 821 supports these roles, but as this target deployment architecture is 822 reached, they never need to generate or verify SIPCoin since it is 823 fully handled e2e. This minimize cost for all parties and 824 concentrates it on the entites generating calls to numbers which are 825 never called back, and not on the contact lists of mobile phones. 827 10. Governance 829 In order for SIPCoin to be an effective tool against spammers, it 830 requires ongoing governance. This governance takes three forms: 832 1. Updating of this specification 834 2. Periodic adjustment of the value of N_Zero 836 The first of these is fairly routine for the IETF, but new for 837 cryptocurrencies, which rely on distribued consensus amongst majority 838 implementations. SIPCoin is more managed than those networks, and as 839 such we propose the IETF, in essence, manage the behavior of the 840 system through the published RFC. 842 The second of these is more interesting. In order to deal with 843 changes in the cost of computation over time, it is necessary to 844 adjust the value of N_Zero periodically. This specification suggests 845 that the IETF consensus process be used for this purpose. To speed 846 up implementation, the value of N_Zero must be loaded dynamically by 847 all clients and servers from an IETF maintained and verified website. 848 This allows IETF governance to decide on a new value, and for that 849 new value to be used instantly across the entirety of the SIP based 850 telephone network. 852 11. Economic Analysis and Parameter Tuning 854 11.1. Cost Targets 856 The goal of SIPCoin is to incur cost to callers, in such a way that 857 it erodes the profitability of the spammers to the point of making it 858 no longer viable, and, at the same time, representing only a small 859 increase in the cost to legitimate callers. This represents an 860 operating window in which the system needs to operate. 862 Let us first consider the tolerable costs to legitimate callers. In 863 most cases we anticipate the costs to be borne by the service 864 providers, and then passed on to consumers or perhaps absorbed if the 865 costs do not merit it. Its important to point out that the cost of 866 SIPCoin is metered per call regardless of destination or duration of 867 call. This tends to penalize entities that make many short calls (as 868 telemarketers do) while benefit those who make fewer, long, 869 international calls (which is more typical of users paying high costs 870 today to call friends and family abroad). 872 As a back of the envelope analysis - the average phone bill in the 873 U.S. is approximately $100 for a mobile phone each month. According 874 to [PR Newswire][], the 877 average American makes or answers six phone calls per day. Assuming 878 this is symmetric, thats 3 placed calls per day, 90 per month. With 879 a three percent increase in their bill as an upper bound, this means 880 $3 per month, or 3 cents per call. 882 On the other side of the house - the spammers. Its hard to get 883 precise data - but here is a back of the envelope. A recent [Boston 884 Globe article][] cites that in the US, 2.5B robocalls were placed in the 887 US in April of 2017. Later in the article, it quotes a cost to 888 Americans of $350 million between 2011 and 2013. If we assume this 889 translates directly to the profits of the spammers, over that 36 890 month period thats $9.7M profit per month. If it took 2.5B robocalls 891 per month to achieve that profit, that is a profit of 0.38 cents per 892 call. 894 This means there is - on the surface - a viable operating point here. 895 Assuming a 50% erosion in profit is enough to make a dent in 896 telemarketing, our lower bound on the cost of SIPCoin is 0.19 cents 897 per call, and our upper bound is 3 cents per call. This represents 898 an order of magnitude spread. That is without consideration to the 899 addition of whitelists. 901 When combined with the whitelist and verified caller ID, we can 902 signicantly shift the cost to the spammers. As a back of the 903 envelope, costs are incurred to non-spammers when a user makes a call 904 to a number that the user has never received a call from nor is on 905 the contact list of the callee. There are real use cases for this - 906 a call to a contact center is one such case. Another is a call to a 907 new contact number learned via business card or personal 908 introduction. These are, relativey few. If we assume that, of the 909 100 or so calls made each month perhaps one is like that, this adds 910 another two order of magnitude to the spread, resulting in a three 911 order of magnitude improvement. This means that, as long as we can 912 keep the economics of calling such that it is not three times cheaper 913 for a spammer than an SP to mine SIPCoin, the system can be 914 effective. 916 11.2. Impact of Compute Variability 918 The hardest challenge in building a system that operates in the cost 919 targets is dealing with the highly variable costs of computation. To 920 give some perspective on this, a somewhat dated article on Bitcoin 921 compute costs [] shows a spread of three orders of 923 magnitude in hashing performance across a range of Intel CPUs (from 924 0.245 Mhash/s (million hashes per second), up to 140 million). It 925 cites the performance of GPUs as sitting in a range from 1 MHash/s up 926 to 2568 MHash/s, and quotes ASICs as being able to reach 1000 GHash/s 927 (Billion hashes per second). The performance spread is therefore 928 seven orders of magnitude. Though there is surely a spread in cost 929 as well, it is assuredly not as large. This means that in SIPCoin, 930 the spammers will be incentivized to buy high performance compute 931 which is viable economically only at high scale. 933 However, considering the deployment architecture described above, the 934 generating role is implemented by enterprises that have SIP trunks to 935 their carriers, and the carriers. The low end computational devices 936 - mobile phones - actually delegate their generating role to the call 937 agent acting on their behalf. If we imagine that small home networks 938 and small businesses would similarly delegate their generating role 939 to their service provider, we end up in a model where trust 940 relationships primarily put the burden of computation on larger 941 entities, which can in general afford to just all use ASICs, which 942 can eliminate the disparity between the spammers and the good guys. 944 In other words, if the spammer can afford some ASIC-based machines, 945 Verizon can too. 947 11.3. Load Analysis on the CAs 949 This proposal introduces a new role to be played by a CA, in the 950 verification of SIPCoin ledgers. This process is, fortunately, 951 almost stateless, requiring a query for just two hash value indexed 952 by a public key. There are no user records, payment systems, 953 cryptographic storage (beyond what they already implement). However, 954 it is extremely high volume. 956 Assume a large carrier is about 100 million subscribers. Assume that 957 they do an average of about 10 calls attempts per day per user. 959 Assume volume at peak is 3x average (ignoring things like earthquakes 960 in California ). For calculation purposes, lets say we we are 961 closing ledger ever 0.5 seconds. That gives us (100,000,000 * 10 * 3 962 / 246060 / 0.5) = 70,000 entries per close in busy case. Lets say 963 our EC signature are 100 bytes and that a burn or create transaction 964 fit in 256 bytes total and that a given page has about equal number 965 of create and burn. This gives me that the CA, even it it only goes 966 back a 2 pages, needs to look at 3 pages * 70,000 entries * 2 (for 967 create and burn ) * 256 bytes = 100 Mbyte each half second or about 968 1.6 Gbps. 970 Is this too much? Its a lot. But not out of the realm of 971 reasonableness. 973 12. Alternative Consensus Techniques 975 The proposal here uses the CAs as trusted third parties to verify the 976 ledger. This is owing to the challenges in achieving rapid consensus 977 in large scale distributed blockchains. However, a variant on the 978 proposal here is to elect randomly a small subset of the entities 979 participating in bitcoin and require consensus only amongst a subset. 980 The size of the subset needs to only be larger than twice the number 981 of malicious entities we wish to tolerate. One can argue that the 982 incentives for being malicious in SIPCoin are smaller (just 983 spammers), perhaps they only represent 5% of call agents in the 984 network (whcih would be a lot!). So we only need 10% of the nodes 985 for consensus. 987 If the set of elected nodes can be small, and they are very well 988 connected to each other, we can run full-mesh consensus protocols 989 which are potenitally fast enough to achieve consensus and sign 990 results and then distribute them at a speed which meets the 991 requirements here. These elected agents would exactly implement the 992 server side role of LVP, and validation is by looking at consensus 993 view rather than verifying signatures. 995 13. Security Considerations 997 There are many attacks possible in this system. THe primary ones to 998 prevent are the clients acting maliciously in order to either create 999 additional SIPCoin without doing the hashing work, or use the same 1000 SIPCoin for multiple SIP INVITEs. We consider both forms of attack. 1002 13.1. Creating Additional SIPCoin 1004 A client might maliciously obtain a SIPCoin from another client in 1005 some way (perhaps eavesdropping or theft of databaase), and then use 1006 it for itself. However, it cannot do that. Since the challenge in 1007 the SIPCoin is bound to the ledger in which it lies, by using the 1008 page key, and then the page key is linked to the entire ledger chain 1009 for the same client, it is not possible to insert SIPCoins into 1010 different ledgers. 1012 A client might try and perform the hashing and then insert the same 1013 SIPCoin twice into the same ledger page. However, this is not 1014 possible because the server will confirm each Create transaction 1015 derives from a unique predecssor. In a similar way, a client might 1016 try to insert the same create transaction into two different ledgers. 1017 Since the server maintains an index of the most recent Create 1018 transaction, it would detect this. 1020 13.2. Burning a SIPCoin Multiple Times 1022 One way in which a client might try and burn the same coin twice is 1023 to literally have the same burn transaction reference the same coin 1024 in its sequential ledger chain. This is prevented through the core 1025 validation steps performed by server, which looks for such 1026 duplicates. 1028 Another way in which a client might try and burn the same coin twice 1029 is to fork the ledger, and put the same Burn event in different 1030 pages. This is prevented because the server will verify and then 1031 sign the first such forked page presented to it. When it does, the 1032 server basically advances the pointer it maintains to the most 1033 recently closed page in the ledger. When the client tries to fool 1034 the server into verifying the second fork, the server will reject it 1035 because the currently active page is not the direct descendant of the 1036 previously closed page. Thus, the client can only maintain a single, 1037 sequential ledger. 1039 THe client might try and use the same Burn Receipt in two different 1040 SIP transactions. This is not possible, because the Burn receipt 1041 includes a hash over the fields in the INVITE which cannot be 1042 duplicated by the call agent without for differnt calls - the called 1043 party and timestamp. Narrow timestamp windows (say, 2 seconds), 1044 prevent even calls to the same number with the same Call-ID within 1045 that window. 1047 A client might try and take burn receipts from INVITEs it reuses, and 1048 replay them in different INVITEs. The binding of the burn receipt to 1049 the called user prevents this. 1051 [[TODO: lot more rigor needed here]] 1053 14. IANA Considerations 1055 TODO 1057 15. Acknowledgments 1059 Many thanks to Ram Jagadeesan and Richard Barnes for their input. 1061 16. References 1063 16.1. Normative References 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, 1067 DOI 10.17487/RFC2119, March 1997, 1068 . 1070 16.2. Informative References 1072 [draft-rosenberg-stir-callback] 1073 Rosenberg, J. and C. Jennings, "Bootstrapping STIR 1074 Deployments with Self-Signed Certs and Callbacks", March 1075 2018, . 1078 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1079 A., Peterson, J., Sparks, R., Handley, M., and E. 1080 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1081 DOI 10.17487/RFC3261, June 2002, 1082 . 1084 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1085 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 1086 January 2008, . 1088 Authors' Addresses 1090 Jonathan Rosenberg 1091 Cisco Systems 1093 Email: jdrosen@jdrosen.net 1095 Cullen Jennings 1096 Cisco Systems 1098 Email: fluffy@iii.ca