[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00

Network Working Group                                       J. Rosenberg
Internet-Draft                                               C. Jennings
Intended status: Standards Track                           Cisco Systems
Expires: September 3, 2018                                 March 2, 2018


    SIPCoin: A Cryptocurrency for Preventing RoboCalling on the PSTN
                    draft-rosenberg-stir-sipcoin-00

Abstract

   Robocalling has become an increasing problem in the Public Switched
   Telephone Network (PSTN).  While techniques like verified caller ID
   can help reduce its impact, ultimately robocalling will continue
   until economically it is no longer viable.  This document proposes a
   new type of cryptocurrency, called SIPCoin, which is used to create a
   tax - in the form of computation - that must be paid before placing
   an inter-domain call on the SIP-based public telephone network.
   SIPCoin maintains complete anonymity of calls, is non-transferable
   between users avoiding its usage as an exchangeable currency, causes
   minimal increase call setup delays, and makes use of traditional
   certificate authority trust chains to validate proofs of work.
   SIPCoin is best used in concert with whitelist based techniques to
   minimize costs on known valid callers.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 3, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Rosenberg & Jennings    Expires September 3, 2018               [Page 1]


Internet-Draft                   SIPCoin                      March 2018


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Reference Architecture  . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Applicability of Traditional Cryptocurrencies . . . . . . . .   7
   6.  Applicability of Challenge Based Solutions  . . . . . . . . .   8
   7.  Overview of SIPCoin . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  SIPCoin Roles . . . . . . . . . . . . . . . . . . . . . .   9
     7.2.  Creation and Maintenance of the Self Ledger . . . . . . .   9
     7.3.  Transaction Types . . . . . . . . . . . . . . . . . . . .  11
       7.3.1.  Create Transaction  . . . . . . . . . . . . . . . . .  11
       7.3.2.  Burn Transaction  . . . . . . . . . . . . . . . . . .  11
     7.4.  Closing Ledger Pages  . . . . . . . . . . . . . . . . . .  12
     7.5.  Server Validation . . . . . . . . . . . . . . . . . . . .  13
     7.6.  Constructing Burn Receipts  . . . . . . . . . . . . . . .  14
   8.  Usage of SIPCoin with SIP . . . . . . . . . . . . . . . . . .  15
   9.  Deployment Considerations . . . . . . . . . . . . . . . . . .  16
     9.1.  Enterprise SIP Trunks . . . . . . . . . . . . . . . . . .  16
     9.2.  Inter-Carrier Trunks  . . . . . . . . . . . . . . . . . .  17
     9.3.  Consumer provider to Mobile Phone . . . . . . . . . . . .  17
     9.4.  Target Model  . . . . . . . . . . . . . . . . . . . . . .  18
   10. Governance  . . . . . . . . . . . . . . . . . . . . . . . . .  18
   11. Economic Analysis and Parameter Tuning  . . . . . . . . . . .  18
     11.1.  Cost Targets . . . . . . . . . . . . . . . . . . . . . .  18
     11.2.  Impact of Compute Variability  . . . . . . . . . . . . .  20
     11.3.  Load Analysis on the CAs . . . . . . . . . . . . . . . .  20
   12. Alternative Consensus Techniques  . . . . . . . . . . . . . .  21
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  21
     13.1.  Creating Additional SIPCoin  . . . . . . . . . . . . . .  21
     13.2.  Burning a SIPCoin Multiple Times . . . . . . . . . . . .  22
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     16.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23



Rosenberg & Jennings    Expires September 3, 2018               [Page 2]


Internet-Draft                   SIPCoin                      March 2018


1.  Problem Statement

   Robocalling (also known as SPAM, voice SPAM, and so on) has become an
   increasing problem in the Public Switched Telephone Network (PSTN).
   Efforts to prevent it - such as the do-not-call list - have so far
   proven ineffective.  Recently, robocallers have gotten even more
   crafty, and are tailoring the caller ID of incoming calls to match
   the area codes and exchanges of the recipients in order to increase
   the likelihood that targets pick up the phone.

   This problem is not new, and ultimately the techniques for its
   prevention have been known for some time.  [RFC5039] outlines a
   number of techniques for prevention of SPAM in Session Initiation
   Protocol (SIP) [RFC3261] based systems.

   Ultimately, SPAM calls are a matter of economics.  Each call costs
   the spammer a certain amount of money to perform.  However, a small
   fraction of calls produce a successful result, generating economic
   returns.  As long as the profit is positive, spammers will continue
   and will likely work around legal hurdles, blacklists, reputation
   systems, black lists, and so on.  Consequently, the only true way to
   end robocalling is to use economics - to make it no longer
   profitable.

   This can be achieved in two ways.  One is by the exchange of actual
   monies across all access and peering points in the public telephone
   network.  As the telephone network continues to grow, this becomes
   increasingly difficult.  Furthermore, it only requires a single point
   of failure at one peering point, and calls have a way to enter the
   network.  Indeed, this is exactly why we see robocalling today
   despite the fact that monies are in fact exchanged within the PSTN.

   An alternative solution is to use computational puzzles, as described
   in Section 3.9 of [RFC5039].  The original concept described there is
   the a callee passes a computation test back to the caller, which
   performs it, and then passes the results towards the callee.  This
   suffers from two problems.  One, described in the document, is that
   there is high variability in the computation capabilities of
   individual calling devices and systems.  Secondly, performing the
   computation at call initiation time increases call setup delays.
   This increase is likely to be large, owing to the amount of
   computation required to act as an economic disincentive.

   Consequently, the problem to be solved is to provide a system that
   requires callers to demonstrate a proof of work towards callees in a
   way which does not suffer these problems.  Fortunately, in the
   intervening years since the publication of [RFC5039], blockchain
   technology was invented, and along with it, a wealth of



Rosenberg & Jennings    Expires September 3, 2018               [Page 3]


Internet-Draft                   SIPCoin                      March 2018


   cryptocurrencies (BitCoin, Ethereum, etc).  The goal is to apply
   these technologies in a way to solve the unique requirements of the
   problem at hand.

2.  Reference Architecture

   The reference architecture for SIPCoin is:

     +----------+
     |  Ledger  |
     |  Server  |
     |          |
     |          |
     +----+-----+
          ^
          |
          | Ledger
          | Verification
          | Protocol
          |
          |
   a.com  |                     b.com
    +-----+------+                +------------+
    |  Ledger    |     SIP        |            |
    |  Client    +---------------^+            |
    |            |                |            |
    |Call Agent  |                |Call Agent  |
    +------------+                +------------+

       +-+  +-+                      +-+  +-+
       | |  | |                      | |  | |
       +-+  +-+                      +-+  +-+

   In this architecture, users associated with one call agent
   (representing a.com) wish to communicate with users associated with a
   different agent, reachable through b.com, using the Session
   Initiation Protocol (SIP) [RFC3261].  The b.com agent wishes to gate
   incoming calls based on proof of computational work provided by the
   a.com call agent.  To perform this, the a.com agent implements the
   client component of the Ledger Verification Protocol (LVP).  In LVP,
   clients - in this case embedded into the call agent - perform hashing
   operations, and maintain a self-generated ledger of transactions.  To
   validate pages in the ledger, the ledger client accesses a ledger
   server through LVP.  Through this protocol, the ledger client can
   obtain information to include int the SIP INVITE.  A call agent will
   typically implement many instances of the ledger client, since each
   instance has an upper bound on the amount of calls per second it can
   perform.



Rosenberg & Jennings    Expires September 3, 2018               [Page 4]


Internet-Draft                   SIPCoin                      March 2018


   In this architecture, there are two call agent roles - the generating
   agent and the receiving agent.  Though, in the picture as shown, they
   represent the registrar of record for the caller and callee
   respectively, this need not be the case.  Rather, the two roles can
   be implemented at differing paths along the actual call setup, and
   indeed occur multiple times along the call.  Later sections in this
   document map the architecture to recommended points of physical
   implementation.

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Generating Agent
      The SIP proxy, user agent or B2BUA which wishes to demonstrate
      proof of work in order to pass a call downstream towards a
      receiving agent which will ultimately validate the proof of work.

   Receiving Agent
      The SIP proxy, user agent or B2BUA which will only accept incoming
      calls under demonstration of proof of work.

4.  Requirements

   o  Unlimited Participants: The system must allow for an unlimited
      number of call agents to participate.  New agents should be able
      to come and go on demand.  This allows the system to extend to
      agents representing carriers, enterprises, home networks, and so
      on.

   o  Low Latency: The system should not significantly increase the call
      setup delay for calls.  This is a big constraint, since it means
      that proof-of-work computations must be performed in advance of
      placing the actual call.  One to two seconds is acceptable, but
      not more than that.

   o  Privacy Protection: There must not be any sharing of logs of
      calls, personally identifiable information (PII), phone numbers,
      or similar information.  Sharing includes passing this information
      between entites which would otherwise not have access to it, or
      storing it in some kind of ledger.

   o  Non-Transferrable: Any currency used for placing calls must be
      limited in scope to only allow placing of calls, and not be
      transferrable amongst participants in the system, or exchangeable
      for traditional or crypto currencies.  This is a significant



Rosenberg & Jennings    Expires September 3, 2018               [Page 5]


Internet-Draft                   SIPCoin                      March 2018


      requirement since it rules out all existing cryptocurrencies by
      definition.  Why is this requirement important for this use case?

      *  Enable small players: SIP was designed to enable an open
         interconnection amongst anyone on the Internet.  A SIP domain
         can be a single device supporting a single user.  It can be a
         home network.  It can be a small business.  It can be a large
         enterprise.  It can be a small telco, a large telo, or a
         massive global provider.  In order to enable the most open
         access possible, barriers to entry must be small.
         Consequently, we want to retain the property of SIP that a two
         person domain can install an open source SIP server, and be off
         and able to make calls.  Transferability would mean that the
         currency has real value, and thus to operate a system, the
         agent must be able to connect to currency exchange systems,
         payment processing platforms, and so on, in order to obtain the
         currency before being able to place the first call.  This makes
         it difficult for small players to participate.

      *  Fraud: The entire purpose of this system is to prevent
         fraudulent entities from placing calls into the global SIP
         network.  If it was based on transferrable cryptocurrencies, it
         would likely be susceptible to fraud and thus benefit the very
         entities we are trying to stop.

      *  Managed Costs: Today's cryptocurrencies have highly variable
         exchange rates, sufficiently variable that they are difficult
         to use as a payment vehicle, and even more difficult to use for
         microtransactions.  However, that is exactly the opposite of
         our case - we require high volume, extremely low cost
         microtransactions, at a price point which hits a particular
         operating point that is just high enough to make it
         unprofitable for spammers yet not overly expensive for real
         callers.  Consequently, by tying the cost strictly to the price
         of computation, we reduce (though certainly do not fully
         eliminate!) the risks of highly variable currency and allow for
         relatively low cost microtransactions.

   o  Non Privileged: The system should not require centralized entities
      to have access to telecom databases or other information which
      requires governmental or regulatory access.  This constraint in
      the system makes it incrementally deployable without waiting for
      the centralized bureaucracy of telco operations.  Any centralized
      capabilities must be an easy incremental add to existing services
      (e.g., a change to current cerificate authorities).






Rosenberg & Jennings    Expires September 3, 2018               [Page 6]


Internet-Draft                   SIPCoin                      March 2018


   o  Phone Numbers or SIP URI: The system should not require phone
      numbers to operate.  It should work with traditional domain-based
      SIP URI as tell as tel URI phone numbers.

   o  Predictable Cost: The system must enable a call agent to perform a
      certain amount of computation and be able to predict the amount of
      calling which it can perform for a given amount of computation
      performed in advance of the call.  Without this property, an agent
      runs a risk it cannot service real-time requests for calls from
      its users because it doesn't have enough crypto currency.  This
      property is related to the non-transferability requirement; if the
      crypto currencies were transferrable, an agent could instantly
      purchase crypto currency to place a call.  Without
      transferability, predictable computation is required to ensure the
      ability to place a call.

   o  Managed Governance: Since adjustments will need to be made in the
      computational costs required, the system must support a managed
      governance model under the authority of a standards body, such as
      the IETF or ITU.

5.  Applicability of Traditional Cryptocurrencies

   One immediate question is - why not just use Bitcoin or one of the
   other crypto currencies?  This would be easy to do.  Each SIP INVITE
   would contain a reference to a transaction that passes the required
   costs from the caller to the callee.

   Putting aside for a moment the non-transferability requirement -
   which rules out all existing cryptocurrency - other requirements make
   Bitcoin and similar cryptocurrencies non viable.

   Firstly, they fail on the privacy requirement.  Usage of Bitcoin
   would require transactions in the ledger to identify the caller and
   called parties, thus leaking information about who is calling who.

   Secondly, the systems do not provide predictable or managed costs,
   which are essential for this application.  The cost of Bitcoin is
   highly variable, and subject to (sometimes wild) market swings.
   These costs cannot be managed by any consensus organization, and
   indeed the cost may collapse entirely, completely destroying the
   benefit of the system.

   Finally, Bitcoin is too slow.  It, and similar cryptocurrencies, rely
   on ledgers which post infrequently, causing transactions to take
   minutes or even hours to eventually post and be verified.  This
   system requires a transaction - the spending of a coin to place a




Rosenberg & Jennings    Expires September 3, 2018               [Page 7]


Internet-Draft                   SIPCoin                      March 2018


   call - to happen fast enough that it can be spent by the caller, and
   verified by the callee, within one to two seconds.

6.  Applicability of Challenge Based Solutions

   The second question to ask is - why not just have the callee
   challenge the caller to perform a computational puzzle at time of
   call setup, and the caller returns the results?

   The primary problem with this class of solution is the time it takes
   to perform enough computation to serve as an economic disincentive
   for placing spam calls.  To get a general feel for the costs using
   modern compute, consider Amazon EC2 on demand pricing.  For a middle
   of the road compute optimized node - say - the c4.large instance - as
   of February 25, 2018, Amazon is charging USD 10 cents per hour (.0027
   cents per second) of computation for an instance in US East.  We can
   imagine that our goal for disincentivizing an attacker is somewhere
   between a .1 cent per call, and perhaps as high as a 10 cents per
   call, this would require computation on this particular instance type
   of between 37 seconds (for .1 cent of cost) and 1.01 hours (for one
   dollar).

   Of course, modern Bitcoin mining no longer uses CPUs or even GPUs for
   that matter, but rather ASICs.  Though these can perform far more
   computation per unit time interval than a CPU for specialized
   hashing.  However, the raw cost per hour of operation - regardless of
   the amount of computation that can be performed - is the question at
   hand for analyzing the viability of a challenge/response approach.
   ASIC and GPU based systems are higher cost per hour to operate due
   largely to their scarcity.  [[OPEN ISSUE: hmm, not sure this argument
   works owing to asymmetry issues]]

   37 seconds - and certainly one hour - is far too long to wait before
   a call can be forwarded to the called party.  For this reason, this
   class of technique does not work.  The solution requires the
   performance of the computation ahead of the call.

   [[TODO: go through all EC2 instance types, price out a more
   normalized compute cost - dollars per Ghz per hour.  Such a metric
   normalizes against number of CPUs as well as variations in the
   performance of the CPUs.]]

7.  Overview of SIPCoin

   This section provides an overview of SIPCoin, a new cryptocurrency
   used for placing SIP calls over the global SIP network.





Rosenberg & Jennings    Expires September 3, 2018               [Page 8]


Internet-Draft                   SIPCoin                      March 2018


   SIPCoin differs from Bitcoin significantly in that it does not rely
   on completely decentralized trust.  Rather, it bootstraps itself on
   the existing certification authorities which power the modern web.
   As such, the system has two distinct actors - clients, and servers.
   Clients are entities which perform computation in order to create
   SIPCoins, and then "burn" those coins in order to place a call.
   Consequently, SIPCoin supports only two types of transactions - a
   "create" transaction which creates a Bitcoin through the solution of
   computational puzzles, and then a "burn" transaction which destroys a
   coin by binding it to a particular SIP call.  Since the create and
   burn transactions are localized - they affect only the client itself
   - there is never a need for sharing of the ledger.  Consequently,
   clients actually maintain their own ledgers for these transactions,
   as described below.  A client needs to provide proof that it has
   burned a token; that proof is performed with a different object - a
   Burn Receipt - constructed by the client using data returned from the
   server.

7.1.  SIPCoin Roles

   Clients are uniquely identified by their public key.  There is no
   need for a certificate to be associated with the public/private key
   pair.  Indeed, typically a single administrative entity - such as a
   telco operator - would have hundreds or thousands of clients, each
   with its unique public/private keypair.  An administrative entity can
   create and destroy client instances at will, without any centralized
   configuration or provisioning.

   Servers - typically run by, or co-resident with certificate
   authorities - are responsible for verification of ledger pages
   created by clients, and issuing of data needed by clients to
   construct burn receipts for coins that are verifiably burned on the
   ledger.  The protocol puts the burden of storage of all ledger
   information entirely in the hands of clients, such that servers
   require a tiny amount of storage per client.  Since servers are run
   by certificate authorities, their verification of ledger pages and
   issuance of data to construct burn receipts relies on their private
   keying material, trusted by all other actors.

7.2.  Creation and Maintenance of the Self Ledger

   Each client is responsible for maintenance of a ledger of its own
   create and burn transactions, the only two types of transactions
   permitted in the system.  The ledger is broken into a series of
   pages.  The client posts transactions into the current page of the
   ledger, called the active page.  Each page starts with a page key,
   which is a hash of the prior page, forming a chain.  Following the
   hash are a series of transactions.  The pages prior to the active one



Rosenberg & Jennings    Expires September 3, 2018               [Page 9]


Internet-Draft                   SIPCoin                      March 2018


   will all - through the LDP protocol - be signed by the server.  These
   pages are called closed pages, and the server's signature over the
   page forms the final element in a closed page.  The client is
   responsible for storing the prior pages in the ledger persistently.

   Clients do not need to maintain prior pages indefinitely.  Recall
   that each page is composed of a series of create and burn
   transactions.  For a particular page, a client can delete a page from
   storage when all of the following conditions are met:

   1.  All the prior pages have been deleted

   2.  All of the create transactions in the page have been burnt in a
       subsequent page which has been closed

   3.  All of the Create transactions in the page have a subsequent
       Create transaction in a page which has been closed

   In essence, the client maintains a sliding window of pages, with the
   tail being the current active page, and the head being the newest
   page that still contains an unburnt coin or Create transaction that
   formed the seed of the hash for the current, in-progress one.

   The client is required to maintain these pages because they will need
   to be presented to the server to sign the current page, transitioning
   it from active to closed.

   If a client should lose its pages, it forfeits any coin which it may
   have created.  This is a significant difference compared to
   traditional Bitcoin, which uses a distributed storage system to
   provide a global ledger based on consensus, shared by all
   participants.  In SIPCoin, there are many parallel ledgers, and each
   is stored locally only to that participant.  This also means that all
   partiicpants in SIPCoin can mine coins; it is not a competition.
   Competitive mining favors the largest and most invested players,
   preventing others from being able to mine at all, in some cases.
   Since it is not possible to transfer SIPCoin, such a situation would
   mean that a SIP entity might not be able to place a call since it
   never won a lottery.

   When a new client is created by an administrative entity, it needs to
   begin a new ledger.  Each ledger and ledger page must be unique,
   ensureing that the proof of work transactions on one ledger cannot be
   copied into any other ledger.  To create a new ledger, the client
   transacts with the server to obtain a first page.  The first page is
   signed by the server - like all other pages.  However, unlike
   subsequent pages, it contains no transcations - just a page key.  The




Rosenberg & Jennings    Expires September 3, 2018              [Page 10]


Internet-Draft                   SIPCoin                      March 2018


   server will choose a crypto-random value for the page key, ensuring
   that no two ledger pages start with the same value.

7.3.  Transaction Types

   SIPCoin supports only two types of transactions that can be placed
   into the ledger.  These are the create transaction and the burn
   transaction.

7.3.1.  Create Transaction

   The create transaction is composed of the following elements:

   1.  The challenge.  This is a number that forms the seed of the
       hashing.  For the first transaction in a page, the challenge is
       equal to the page key.  For all subsequent create transactions,
       the challenge is a hash of the prior Create transaction in the
       ledger.

   2.  The solution.  This is a number which demonstrates that the proof
       of work has been done.  Each proof of work is a hash function
       Ht() which takes as input two numbers, and returns a hashed
       result.  The proof is demonstrated by providing a value S for the
       solution which, when hashed with the challenge C, forms a result
       H(S,C) which has N_Zero consecutive zeroes in the result.  N_Zero
       is a global configuration parameter, and is discussed in more
       detail later on.  Its adjustment is a principle part of the
       governance of the operation of SIPCoin.

   3.  The Coin ID: This is computed by the client as a hash over its
       public key, the challenge, and the solution.  It serves as a
       unique identifier for the Coin produced by this create
       transaction.

7.3.2.  Burn Transaction

   The Burn transaction is created by the client when it wishes to place
   a SIP call.  Consequently, each burn transaction is bound with a SIP
   INVITE.  To perform this linkage, the burn transaction is composed of
   the Coin ID (obtained from a prior create transaction for an unspent
   coin) along with a hash over several fields of the SIP INVITE.  The
   fields incude the From, To, Call-ID and fields from the SDP, such as
   media encryption keys.  The hash also includes the timestamp for the
   burn transaction.

   Beacuse the burn transaction is a hash over these various parameters,
   when it is sent to the server for signature, the server has no way to
   invert the hash.  Consequently, the server learns nothing about the



Rosenberg & Jennings    Expires September 3, 2018              [Page 11]


Internet-Draft                   SIPCoin                      March 2018


   originator of the call, the recipient of the call, the type of media
   in the call, or anything else.  All that the server learns is that a
   call was placed, and that it was placed by the administrative entity
   that has a relationship with the server.  This does mean that
   servers, through the observation of burn transaction rates, will know
   the call volume being emitted by the entity, but thats it.

   The SIP agent running the client will not be able to send the SIP
   INVITE until it has received a burn receipt from the server.  In
   essence, it needs to hold the INVITE until the ledger page is
   complete.  For this reason, in SIPCoin, ledger pages close very fast.
   A client can post a ledger page for closure at a frequency on the
   order of one every 250ms to 500ms.

7.4.  Closing Ledger Pages

   A client closes the active ledger page when one of two conditions is
   met:

   1.  The ledger page contains N_trans transactions in it

   2.  The client requires a burn receipt for a burn transaction on the
       page, and it has not posted a ledger to the server within the
       last T_min seconds

   A client is not required to close a ledger every T_min seconds; if it
   has no pending burn transactions in the ledger (only creates), it can
   wait.  T_min specifies the minimum interval, and it is nominally
   enforced on the server to ensure the server is not overloaded.

   To actually close the page, the client signs the active page with its
   public key, and then transmits the active page to the server, along
   with the public key.  The first time it closes a page, it will also
   need to post all closed pages to the server.  The server will
   validate the transactions in the current page, including insuring
   that the client has not double burnt the same coin.  That particular
   check requires the server to have all active pages for the client,
   which is why they must be sent.

   Once the server performs its checks, it will send back a signed
   version of the page, closing it.  This enables the client to start a
   new active page in the ledger.  The server also returns a signature
   over the now-closed page, using its trusted certificate.

   The server also returns a signed hash, described below, that allows
   the client to compute burn receipts for each SIPCoin that was burned.





Rosenberg & Jennings    Expires September 3, 2018              [Page 12]


Internet-Draft                   SIPCoin                      March 2018


7.5.  Server Validation

   The server follows a standardized process for validating the page
   submitted by the client.  At a high level, it composes the following
   steps:

   1.  The server authenticates the client; typically this is done using
       an administrative credential for the administrative entity
       responsible for the client.  [[NOTE: Use ACME techniques for
       this??]].  LVP technically speaking does not require the server
       to actually authenticate the client if it chooses not to.

   2.  The server checks the signature on all pages sent by the client
       to ensure that they have been signed by itself.

   3.  The server validates that the pages form a sequential chain.  It
       starts at the first page, computes it hash, and ensures that the
       result matches the page key of the subsequent page.

   4.  The server keeps stored, for each unique client (as indexed by
       public key), the hash of the most recently signed active page
       from that client, thus closing it.  It checks that the active
       page that is to be signed is the successor, by comparing the page
       key in the active page to the stored value.  This prevents
       malicious clients from forking the ledger and placing the same
       burn transaction, but for different INVITEs, into each fork.

   5.  The server examines every burn transaction in all pages sent by
       the server, and makes sure it matches exactly one create
       transaction.  This ensures that the server has received all pages
       from the client (omission of a page from the client would enable
       it to double burn).

   6.  The server processes the transactions in order in the active page
       which is to be signed.  If a transaction is ia create
       transaction, it verifies that the challenge is either the page
       key (for the first ever Create transaction) or the hash of the
       prior Create transaction in the ledger otherwise.  The server
       stores, indexed by the public key of the client, the hash of the
       most recent Create transaction.  It verifies this Create
       transaction has used that value as the challenge.  It then takes
       H(), and uses it with the challenge and solution values.  It
       verifies that the result has N_zero consecutive zeros.  It then
       hashes the client public key with the challenge and solution, and
       makes sure it matches the Coin ID.  If the transaction is a burn
       transaction, the server takes the CoinID and searches through all
       burn transactions in all pages sent by the client, and makes sure
       it doesnt match the Coin ID in any other burn transaction.



Rosenberg & Jennings    Expires September 3, 2018              [Page 13]


Internet-Draft                   SIPCoin                      March 2018


   Once these validation steps pass, the server generates a signature
   over the active page using its certificate.  It then stores the hash
   of this closed page to enable it to validate the next one, and stores
   the hash of the last Create transaction in the page to validate the
   next Create transaction.

   To enable the client to create and send burn receipts, the server
   computes a balanced binary merkle tree, where the leaf nodes in the
   tree represent the Burn transactions from the page which was just
   closed.  The head of the merkle tree is the signed by the CA with its
   private key.  The signed head is returned to the client, along with
   the signed page that was just closed.

   For purposes of performance optimization, the server can elect the
   cache the inactive pages, avoiding the need for the client to resend
   them each time.  To do that, the server stores the pages and
   generates a cache key, which is an opaque parameter chosen by the
   server.  The client, in subsequent validation requests, can include
   this key.  It can then be used by the server to route those requests
   to the server instance which is holding the cache, and then used to
   extract the cached pages indexed by that key.  If the server has a
   cache miss, it can reject the request and force the client to
   resubmit all its inactive pages.

7.6.  Constructing Burn Receipts

   To construct burn receipts, the client computes the merkle tree
   identically to the algorithm used by the server.  It then verifes the
   signature over the head.  This will normally be valid, since the CA
   is trusted in this architecture.  The burn receipt for a SIPCoin is a
   digital object composed of:

   1.  All of the nodes in the merkle tree, starting at the leaf for the
       burn transaction for the coin in question, to the head of the
       tree.

   2.  For each node in the list above, the sibling of that node.

   3.  The signature over the head, as provided by the server.

   This object is readily verified by having the receiving call agent
   hash upwards through the merkle tree and compare the result against
   the signature on the head.  This burn receipt is included in the SIP
   INVITE.  The usage of a merkle tree reduces the number of signing
   operations at the CA and also reduces the amount of data that must be
   transferred back to the client.





Rosenberg & Jennings    Expires September 3, 2018              [Page 14]


Internet-Draft                   SIPCoin                      March 2018


8.  Usage of SIPCoin with SIP

   The usage of SIPCOin with SIP is relatively straightforward.  We say
   that a "SIPCoin is included in the INVITE" when the INVITE includes a
   Burn receipt for that coin; in this architecture coins are not
   actually transfer, only proof of their destruction.  SIPCoins can be
   included in a SIP INVITE proactively with a Burn receipt, or they can
   be inserted reactively at request of the receiving agent.  Its
   easiest to understand through the reactive flow.

   The generating agent sends an INVITE normally, without any SIPCoin in
   it.  This arrives at the receiving agent.  Ideally, the receiving
   agent will verify the caller ID (see [draft-rosenberg-stir-callback]
   for a solution to enable this to occur).  Once verified, the
   receiving agent checks whether the caller is known to be acceptable
   to the called party.  The definition of acceptable is a matter of
   local policy and depends on the physical entities performing the
   receiving agent role, as discussed below.

   If the caller is acceptable, the call is passed to the called party.
   If the nature of the caller is unknown (which is again a matter of
   local policy), the receiving agent rejects the INVITE with a response
   code 4xx which challenges for SIPCoin in order to accept the call.

   When this is received at the generating agent, it constructs a new
   INVITE, burns a coin, constructs the burn receipt, and places those
   into the INVITE.  This passes to the same receiving agent.  If the
   caller ID is verified (whcih would have been done from the prior
   step) and it continues to be unknown, the receiving agent validates
   the burn receipt.

   To validate it, the receiving agent performs the hashing through the
   merkle tree and verifies the signature on the hash at the top.  The
   certificate verification requires the generating and calling agents
   to share a common trust anchor.  This specification mandates that all
   agents trust the same set of CAs present in the Mozilla Firefox
   browser.  This allows SIPCoin to be rooted in a well vetted,
   continuously maintained set of trust anchors which is proven to work
   globally.

   If the signature is valid, the receiving agent considers the burnt
   coin as a sufficient proof of work to allow the call to proceed to
   the called party.

   In the proactive model, which can be used by the caller to speed up
   call setup if they desire, they burn a SIPCoin prior to the challenge
   and include it in the INVITE straight away.




Rosenberg & Jennings    Expires September 3, 2018              [Page 15]


Internet-Draft                   SIPCoin                      March 2018


9.  Deployment Considerations

   There are many ways in which SIPCoin can be used.  And in fact, the
   hardest part of rolling out a solution like SIPCoin is handling the
   intermediate states where it is only partially deployed on the
   Internet.  This document proposes a phased rollout where each step is
   motivated by economic benefit to the parties at hand.

9.1.  Enterprise SIP Trunks

   The easiest deployment topology, and the best way to start, is on SIP
   trunks between a customer and their provider.  In this model, the
   generating agent is that of the administrative entity which is using
   the SIP trunk, and the receiving agent is that of the provider.
   These are adjacent agents connected by a single SIP hop.  As an
   example, the generating agent could be an enterprise, and the
   receiving agent would be a traditional telco offering enterprise SIP
   trunks.  This would also be combined with the reverse role, where the
   service provider also runs a generating agent and the enterprise runs
   a receiving agent.

   This arrangement provides a value proposition for the enterprise to
   protect itself from inbound spam calls which are received through
   their SIP trunk provider.  If the spammer is another enterprise
   customer of the same provider, that enterprise becomes disincented
   from spamming due to costs.  If the spammer is farther away - and in
   this phase they are most likely to be - the SP eats the cost and
   genreates the SIPCoin.

   In such a service model, the service provider would - through its
   bilateral relationships with its customers, insist its customers
   implement the Outbound SIP Trunk role.  As a result, the service
   provider itself would not need to generate SIPCoin for intra-provider
   calls.  However, it would genreate them for inter-provider calls.
   This provides a benefit to the enterprise, who are now protected from
   spammers connected to the same SP, and the fact that the SP creates
   and burns calls for transit calls means that the enterprise gets the
   benefit of only ever accepting inbound calls which have SIPCoins
   burned.

   In this model, the SP can save itself money in one of two ways.
   Firstly is through whitelisting.  As part of the SIP trunk
   specification, enterprises on the receiving side should maintain a
   database of callers they 'trust'.  A caller ID is trusted if the
   caller ID has been verified [draft-rosenberg-stir-callback], and the
   enterprise had previously, in the last few weeks, placed multiple
   calls to that number, those calls having connected and had a duration
   of at least a few minutes.  This provides a simple model of: I'll



Rosenberg & Jennings    Expires September 3, 2018              [Page 16]


Internet-Draft                   SIPCoin                      March 2018


   trust your inbound call if I've called you previously.  The
   enterprise PBX can also use contact lists from employees contianing
   phone numbers to populate this list.

   This means the SP cost is reduced for trusted callers, and not for
   others.  To further reduce costs, the SPs are incented therefore to
   establish bilateral peering with each other over Inter-carrier
   trunks.

9.2.  Inter-Carrier Trunks

   These work identically to the enterprise SIP trunks; the carriers on
   each side of an inter-carrier peering link implement both the
   generating and terminating roles of the call agents.  When a
   terminating enterprise challenges its SP for a coin, if the call
   arrived via an inbound trunk from another carrier, the SP can
   propagate the request for a coin upstream to save itself costs.  If
   the upstream provider doesnt support SIPCoin, the SP must burn the
   coin itself, creating costs, and thus incentive for each side to
   insist on implementation to reduce costs.

   In this way, SIPCoin implementations propagate outwrads, ultimately
   reaching the originating carriers for consumer services and
   enterprises.  This brings us to the final phases.

9.3.  Consumer provider to Mobile Phone

   This specification recommends that the terminating role be
   implemented in smartphones implementing the IMS specifications.
   Consider now an enterprise which placed a call towards a consumer
   mobile phone.  This call is received at the terminating mobile
   provider.  Since it knows that the mobile callee SIP UA supports
   SIPCoin (from the SUpported header field in the REGISTER), it
   propagates the INVITE towards the called phone after verifying the
   caller ID.  The callee, seeing that the caller ID is verified, checks
   its local contact list.  If the caller is on the contact list, it
   doesnt challenge for coin.  If it isnt, it challenges for the coin.
   This propagates all the way back to the originating enterprise, which
   burns a coin to place the call, which is then accepted by the callee.

   The generting role is not appropriate for implementation on mobile
   phones, and as such the consumer mobile operator cannot pass its
   costs upstream.  However, as part of bilateral peering arrangements
   and standards coordination, the SP can insist that each other require
   their mobile phones to comply with the specs that mandate
   implementation of the terminating role.  That will save each other
   money in proportion to the balance of their inbound to outbound
   calls.



Rosenberg & Jennings    Expires September 3, 2018              [Page 17]


Internet-Draft                   SIPCoin                      March 2018


   This then provides the final economic incentive to achieve the target
   architectural model.

9.4.  Target Model

   In the idealized model, the terminating role is implemented by the
   receiving phones, and the generating role implemented by the call
   agents operating on their behalf.  The entire SIP core network
   supports these roles, but as this target deployment architecture is
   reached, they never need to generate or verify SIPCoin since it is
   fully handled e2e.  This minimize cost for all parties and
   concentrates it on the entites generating calls to numbers which are
   never called back, and not on the contact lists of mobile phones.

10.  Governance

   In order for SIPCoin to be an effective tool against spammers, it
   requires ongoing governance.  This governance takes three forms:

   1.  Updating of this specification

   2.  Periodic adjustment of the value of N_Zero

   The first of these is fairly routine for the IETF, but new for
   cryptocurrencies, which rely on distribued consensus amongst majority
   implementations.  SIPCoin is more managed than those networks, and as
   such we propose the IETF, in essence, manage the behavior of the
   system through the published RFC.

   The second of these is more interesting.  In order to deal with
   changes in the cost of computation over time, it is necessary to
   adjust the value of N_Zero periodically.  This specification suggests
   that the IETF consensus process be used for this purpose.  To speed
   up implementation, the value of N_Zero must be loaded dynamically by
   all clients and servers from an IETF maintained and verified website.
   This allows IETF governance to decide on a new value, and for that
   new value to be used instantly across the entirety of the SIP based
   telephone network.

11.  Economic Analysis and Parameter Tuning

11.1.  Cost Targets

   The goal of SIPCoin is to incur cost to callers, in such a way that
   it erodes the profitability of the spammers to the point of making it
   no longer viable, and, at the same time, representing only a small
   increase in the cost to legitimate callers.  This represents an
   operating window in which the system needs to operate.



Rosenberg & Jennings    Expires September 3, 2018              [Page 18]


Internet-Draft                   SIPCoin                      March 2018


   Let us first consider the tolerable costs to legitimate callers.  In
   most cases we anticipate the costs to be borne by the service
   providers, and then passed on to consumers or perhaps absorbed if the
   costs do not merit it.  Its important to point out that the cost of
   SIPCoin is metered per call regardless of destination or duration of
   call.  This tends to penalize entities that make many short calls (as
   telemarketers do) while benefit those who make fewer, long,
   international calls (which is more typical of users paying high costs
   today to call friends and family abroad).

   As a back of the envelope analysis - the average phone bill in the
   U.S. is approximately $100 for a mobile phone each month.  According
   to [PR Newswire][<https://www.prnewswire.com/news-releases/no-time-
   to-talk-americans-sendingreceiving-five-times-as-many-texts-compared-
   to-phone-calls-each-day-according-to-new-report-300056023.html>], the
   average American makes or answers six phone calls per day.  Assuming
   this is symmetric, thats 3 placed calls per day, 90 per month.  With
   a three percent increase in their bill as an upper bound, this means
   $3 per month, or 3 cents per call.

   On the other side of the house - the spammers.  Its hard to get
   precise data - but here is a back of the envelope.  A recent [Boston
   Globe article][<https://www.bostonglobe.com/ideas/2017/05/11/the-
   onslaught-spam-calls-will-keep-getting-worse/2w1tyrSnzEj8NPO81hUUBK/
   story.html>] cites that in the US, 2.5B robocalls were placed in the
   US in April of 2017.  Later in the article, it quotes a cost to
   Americans of $350 million between 2011 and 2013.  If we assume this
   translates directly to the profits of the spammers, over that 36
   month period thats $9.7M profit per month.  If it took 2.5B robocalls
   per month to achieve that profit, that is a profit of 0.38 cents per
   call.

   This means there is - on the surface - a viable operating point here.
   Assuming a 50% erosion in profit is enough to make a dent in
   telemarketing, our lower bound on the cost of SIPCoin is 0.19 cents
   per call, and our upper bound is 3 cents per call.  This represents
   an order of magnitude spread.  That is without consideration to the
   addition of whitelists.

   When combined with the whitelist and verified caller ID, we can
   signicantly shift the cost to the spammers.  As a back of the
   envelope, costs are incurred to non-spammers when a user makes a call
   to a number that the user has never received a call from nor is on
   the contact list of the callee.  There are real use cases for this -
   a call to a contact center is one such case.  Another is a call to a
   new contact number learned via business card or personal
   introduction.  These are, relativey few.  If we assume that, of the
   100 or so calls made each month perhaps one is like that, this adds



Rosenberg & Jennings    Expires September 3, 2018              [Page 19]


Internet-Draft                   SIPCoin                      March 2018


   another two order of magnitude to the spread, resulting in a three
   order of magnitude improvement.  This means that, as long as we can
   keep the economics of calling such that it is not three times cheaper
   for a spammer than an SP to mine SIPCoin, the system can be
   effective.

11.2.  Impact of Compute Variability

   The hardest challenge in building a system that operates in the cost
   targets is dealing with the highly variable costs of computation.  To
   give some perspective on this, a somewhat dated article on Bitcoin
   compute costs [<https://en.bitcoin.it/wiki/Non-
   specialized_hardware_comparison>] shows a spread of three orders of
   magnitude in hashing performance across a range of Intel CPUs (from
   0.245 Mhash/s (million hashes per second), up to 140 million).  It
   cites the performance of GPUs as sitting in a range from 1 MHash/s up
   to 2568 MHash/s, and quotes ASICs as being able to reach 1000 GHash/s
   (Billion hashes per second).  The performance spread is therefore
   seven orders of magnitude.  Though there is surely a spread in cost
   as well, it is assuredly not as large.  This means that in SIPCoin,
   the spammers will be incentivized to buy high performance compute
   which is viable economically only at high scale.

   However, considering the deployment architecture described above, the
   generating role is implemented by enterprises that have SIP trunks to
   their carriers, and the carriers.  The low end computational devices
   - mobile phones - actually delegate their generating role to the call
   agent acting on their behalf.  If we imagine that small home networks
   and small businesses would similarly delegate their generating role
   to their service provider, we end up in a model where trust
   relationships primarily put the burden of computation on larger
   entities, which can in general afford to just all use ASICs, which
   can eliminate the disparity between the spammers and the good guys.

   In other words, if the spammer can afford some ASIC-based machines,
   Verizon can too.

11.3.  Load Analysis on the CAs

   This proposal introduces a new role to be played by a CA, in the
   verification of SIPCoin ledgers.  This process is, fortunately,
   almost stateless, requiring a query for just two hash value indexed
   by a public key.  There are no user records, payment systems,
   cryptographic storage (beyond what they already implement).  However,
   it is extremely high volume.

   Assume a large carrier is about 100 million subscribers.  Assume that
   they do an average of about 10 calls attempts per day per user.



Rosenberg & Jennings    Expires September 3, 2018              [Page 20]


Internet-Draft                   SIPCoin                      March 2018


   Assume volume at peak is 3x average (ignoring things like earthquakes
   in California ).  For calculation purposes, lets say we we are
   closing ledger ever 0.5 seconds.  That gives us (100,000,000 * 10 * 3
   / 246060 / 0.5) = 70,000 entries per close in busy case.  Lets say
   our EC signature are 100 bytes and that a burn or create transaction
   fit in 256 bytes total and that a given page has about equal number
   of create and burn.  This gives me that the CA, even it it only goes
   back a 2 pages, needs to look at 3 pages * 70,000 entries * 2 (for
   create and burn ) * 256 bytes = 100 Mbyte each half second or about
   1.6 Gbps.

   Is this too much?  Its a lot.  But not out of the realm of
   reasonableness.

12.  Alternative Consensus Techniques

   The proposal here uses the CAs as trusted third parties to verify the
   ledger.  This is owing to the challenges in achieving rapid consensus
   in large scale distributed blockchains.  However, a variant on the
   proposal here is to elect randomly a small subset of the entities
   participating in bitcoin and require consensus only amongst a subset.
   The size of the subset needs to only be larger than twice the number
   of malicious entities we wish to tolerate.  One can argue that the
   incentives for being malicious in SIPCoin are smaller (just
   spammers), perhaps they only represent 5% of call agents in the
   network (whcih would be a lot!).  So we only need 10% of the nodes
   for consensus.

   If the set of elected nodes can be small, and they are very well
   connected to each other, we can run full-mesh consensus protocols
   which are potenitally fast enough to achieve consensus and sign
   results and then distribute them at a speed which meets the
   requirements here.  These elected agents would exactly implement the
   server side role of LVP, and validation is by looking at consensus
   view rather than verifying signatures.

13.  Security Considerations

   There are many attacks possible in this system.  THe primary ones to
   prevent are the clients acting maliciously in order to either create
   additional SIPCoin without doing the hashing work, or use the same
   SIPCoin for multiple SIP INVITEs.  We consider both forms of attack.

13.1.  Creating Additional SIPCoin

   A client might maliciously obtain a SIPCoin from another client in
   some way (perhaps eavesdropping or theft of databaase), and then use
   it for itself.  However, it cannot do that.  Since the challenge in



Rosenberg & Jennings    Expires September 3, 2018              [Page 21]


Internet-Draft                   SIPCoin                      March 2018


   the SIPCoin is bound to the ledger in which it lies, by using the
   page key, and then the page key is linked to the entire ledger chain
   for the same client, it is not possible to insert SIPCoins into
   different ledgers.

   A client might try and perform the hashing and then insert the same
   SIPCoin twice into the same ledger page.  However, this is not
   possible because the server will confirm each Create transaction
   derives from a unique predecssor.  In a similar way, a client might
   try to insert the same create transaction into two different ledgers.
   Since the server maintains an index of the most recent Create
   transaction, it would detect this.

13.2.  Burning a SIPCoin Multiple Times

   One way in which a client might try and burn the same coin twice is
   to literally have the same burn transaction reference the same coin
   in its sequential ledger chain.  This is prevented through the core
   validation steps performed by server, which looks for such
   duplicates.

   Another way in which a client might try and burn the same coin twice
   is to fork the ledger, and put the same Burn event in different
   pages.  This is prevented because the server will verify and then
   sign the first such forked page presented to it.  When it does, the
   server basically advances the pointer it maintains to the most
   recently closed page in the ledger.  When the client tries to fool
   the server into verifying the second fork, the server will reject it
   because the currently active page is not the direct descendant of the
   previously closed page.  Thus, the client can only maintain a single,
   sequential ledger.

   THe client might try and use the same Burn Receipt in two different
   SIP transactions.  This is not possible, because the Burn receipt
   includes a hash over the fields in the INVITE which cannot be
   duplicated by the call agent without for differnt calls - the called
   party and timestamp.  Narrow timestamp windows (say, 2 seconds),
   prevent even calls to the same number with the same Call-ID within
   that window.

   A client might try and take burn receipts from INVITEs it reuses, and
   replay them in different INVITEs.  The binding of the burn receipt to
   the called user prevents this.

   [[TODO: lot more rigor needed here]]






Rosenberg & Jennings    Expires September 3, 2018              [Page 22]


Internet-Draft                   SIPCoin                      March 2018


14.  IANA Considerations

   TODO

15.  Acknowledgments

   Many thanks to Ram Jagadeesan and Richard Barnes for their input.

16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

16.2.  Informative References

   [draft-rosenberg-stir-callback]
              Rosenberg, J. and C. Jennings, "Bootstrapping STIR
              Deployments with Self-Signed Certs and Callbacks", March
              2018, <https://tools.ietf.org/html/
              draft-rosenberg-stir-callback-00>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC5039]  Rosenberg, J. and C. Jennings, "The Session Initiation
              Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
              January 2008, <https://www.rfc-editor.org/info/rfc5039>.

Authors' Addresses

   Jonathan Rosenberg
   Cisco Systems

   Email: jdrosen@jdrosen.net


   Cullen Jennings
   Cisco Systems

   Email: fluffy@iii.ca




Rosenberg & Jennings    Expires September 3, 2018              [Page 23]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/