Re: [VIPR] Agenda for 2011/09/23

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

A fundamental question:
Why would a provider want to advertise routes for a number for which neither of the enterprises is willing to pay for? Isn't ViPR based on the fact the provider is trusted for the first (PSTN) call? If the provider is fooling with the enterprise, won't the enterprise switch to a different provider? Or are we concerned about the security implications around routing subsequent calls through the provider? Aren't they applicable to the first call as well?

If the enterprise doesn't trust the provider then ViPR in its current form doesn't seem to make sense.

Muthu

|-----Original Message-----
|From: Hakim Mehmood (naim)
|Sent: Wednesday, September 28, 2011 11:16 PM
|To: Marc Petit-Huguenin; Dean Willis; Michael Procter; John Ward; 'Mary Barnes'; Muthu Arul Mozhi
|Perumal (mperumal); Daryl Malas; Jon Peterson
|Cc: [e-mail]
|Subject: RE: Agenda for 2011/09/23
|
|My action item was to think about use case B 3.2, I have not spend a whole lot of time on it, however
|if we are ok with the basic premise of trusting a publisher that validates a route, the capabilities
|associated with the route the attached text might be a starting point.
|This is to start a discussion here to solicit ideas
|
|Hakim
|
|-----Original Message-----
|From: Marc Petit-Huguenin [mailto:[e-mail]]
|Sent: Thursday, September 22, 2011 10:18 AM
|To: Dean Willis; Hakim Mehmood (naim); Michael Procter; John Ward; 'Mary Barnes'; Muthu Arul Mozhi
|Perumal (mperumal); Daryl Malas; Jon Peterson
|Cc: [e-mail]
|Subject: Agenda for 2011/09/23
|
|-----BEGIN PGP SIGNED MESSAGE-----
|Hash: SHA1
|
|A. Agenda for 2011/09/23
|
|- - Introduction (5 min)
|- - PSTN origination over SIP (5 min)
|- - PSTN termination over SIP (10 min)
|- - RELOAD registration (5 min)
|- - PVP privacy (10 min)
|- - PVP method priority and registration (10 min)
|- - PVP method entropy (10 min)
|- - Replacement ticket by client certificate (10 min)
|- - Ticket renewal (10 min)
|
|Note that the sum of the time allocated to each topic exceed the time allocated
|to the whole call.  The topics that cannot make it to the discussion will be
|postponed to the next conference call if they are not subsequently decided in
|the mailing-list.
|
|Because the conference bridge as a limited capacity, an individual invitation to
|the conference will be sent shortly after this email to each member of the
|design team.  Please send me an email if you are not on this list and want to
|receive an invitation.
|
|Note that the design team conference call is not a way to short-circuit the
|normal process, but a way to accelerate it by increasing face to face time.  All
|decisions made must be confirmed on the mailing-list.
|
|This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated
|by RFC 4879).
|
|On this subject, please note that some of the things that will be discussed
|below may or may not be relevant to some IPR owned by my company, Stonyfish Inc.
|If this IPR makes its way in one of the VIPR drafts, we will fulfill our
|obligations by timely filling an IPR disclosure.
|
|B. Handout (reading time: 20 minutes)
|
|B.1. Introduction
|
|In Quebec City the proposal to reorganize the VIPR drafts was accepted.  The
|idea is to remove from -overview the parts that go beyond overview and
|requirements, and to combine them with an abstraction of the -vap draft into a
|new draft tentatively called -framework.  This draft will present a more generic
|architecture than what is currently described in -vap, and will focus
|exclusively on the protocol interactions between VIPR domains.  -vap will later
|be retrofitted to describe a specific VIPR architecture (based on the notion of
|VIPR server) and the VAP protocol used inside a VIPR domain supporting this
|specific architecture.  Discussing VIPR at an higher level of abstraction will
|permit to be sure that there can be a full spectrum of implementations, from
|everything in one box (e.g. a VIPR enabled fax machine) to an architecture where
|each component is instantiated multiple times and deployed in multiple data
|centers all over the world.  We will use this abstraction for the remaining of
|this text, focusing exclusively on interactions between VIPR domains, and keep
|discussions about interactions inside a VIPR domain for another day.
|
|B.2. PSTN Interactions
|
|We will start with the interactions between the VIPR domain and the PSTN.  The
|current specification talks only about PSTN calls but there is in fact a larger
|set of interactions with the PSTN that are available:
|
|- - voice call,
|- - video call (H.320),
|- - short messages (SMS),
|- - faxes (T.30),
|- - data connections (V.21, V.22, V.23, V.22bis, V27ter, V.32, V.32bis, V.34, V.90
|and V.92).
|
|Depending on the capabilities of the VIPR domain, all or a subset of these PSTN
|interactions are implemented for phone number verification and so the text in
|the specification should be extended to cover these cases.
|
|B.3. PSTN over SIP
|
|The reality is that not all VIPR domains have a direct connection to the PSTN
|and the one that does generally does not use the service of a VoIP provider to
|reach the PSTN (e.g. with a SIP trunk).  This indirect connection generally uses
|the same protocol, SIP, that will be used after a successful PSTN validation,
|but the two usages must not be confused.  Using an intermediary to reach the
|PSTN adds some complexity to VIPR, complexity that is not fully addressed in the
|current specification.
|
|B.3.1 PSTN origination over SIP
|
|The first case is for calls initiated by the VIPR domain.  Let's imagine that an
|Enterprise is using ProviderA to route its calls. The following diagram shows
|what happen in this case.  Note that the RELOAD overlay is shown as one network
|element as the only feature that we care about here is its distributed database.
|Also I used different lines symbols for different protocols:
|
|  PhoneA    Enterprise     ProviderA       RELOAD       ProviderB   PhoneB
|    |           | Store        |              |             |         |
|1   |           |---------------------------->|       Store |         |
|2   |           |              | Store        |<------------|         |
|3   |           |              |------------->|             |         |
|    :           :              :              :             :         :
|    | INVITE    |              |              |             |         |
|4   |==========>| INVITE       |              |             |         |
|5   |           |=============>| SETUP        |             |         |
|6   |           |              |~~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE  |
|7   |           |              |              |             |========>|
|    :           :              :              :             :     BYE :
|8   |           |              |              |        DISC |<========|
|9   |           |          BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~~|         |
|10  |       BYE |<=============|              |             |         |
|11  |<==========|              | Fetch        |             |         |
|12  |           | Fetch        |------------->|             |         |
|13  |           |---------------------------->|             |         |
|    |           |              | ValExchange  |             |         |
|14  |           | ValExchange  |:::::::::::::::::::::::::::>|         |
|    |           |::::::::::::::::::::::::::::::::::::::::::>|         |
|    :           :              :              :             :         :
|    | INVITE    |              |              |             |         |
|15  |==========>| INVITE       |              |             |         |
|16  |           |==========================================>| INVITE  |
|17  |           |              |              |             |========>|
|    |           |              |              |             |         |
|
|Independently, Enterprise and ProviderA decide to deploy VIPR, so they both
|register (1, 3) the same phone number for PhoneA in the RELOAD distributed
|database.  Separately ProviderB also registers (2) the phone number of PhoneB in
|the RELOAD database.
|
|PhoneA makes a call (4) which is not in the route database of Enterprise, so it
|is proxied (5) to ProviderA.  ProviderA does not have a route either, so the
|call is routed through the PSTN (6) to ProviderB and over IP to PhoneB (7).
|
|After some time the call ends, so PhoneB sends a BYE (8) that is routed over the
|PSTN (9) and IP (10, 11) to PhoneA.  ProviderB uploads a terminating VCR and
|*both* Enterprise and ProviderA upload an originating VCR, which *both* will
|trigger the establishment of a PVP connection and a ValExchange transaction.
|
|In the example above both PVP transactions succeed because the text now says
|that the terminating VCR must not be removed until the end of the 48 hours
|period, even if a PVP transaction succeeded.  In this case, the route stored by
|Enterprise is used for the next call (15, 16, 17) because it is the first call
|agent in the path, but if for some reason this route would fail the call would
|still be VoIP end to end, thanks to the route stored in ProviderA.
|
|Without this rule, we cannot predict which one of the two ValExchange
|transactions will start first (and we do not want to start a race by using
|priorities), so we now are sure that it is always the closer route to the caller
|that will be used and that the others routes will be used as backup.
|
|Note that if only ProviderA route is created (as it would happen in 50% of the
|case with the old text), the Enterprise route will still be created on the
|second call.  Using the new text permits to have only one PSTN call (from the
|point of view of the Enterprise) and maximize the number of backup routes at all
|times (we probably want to set the ticket expiration value to the same for all
|VIPR servers to be sure that the next PSTN call will re-validate all the routes).
|
|B.3.2 PSTN termination over SIP
|
|Now let switch to the scenario in the other PSTN direction:
|
|  PhoneA    Enterprise     ProviderA       RELOAD       ProviderB   PhoneB
|    |           | Store        |              |             |         |
|1   |           |---------------------------->|       Store |         |
|2   |           |              | Store        |<------------|         |
|3   |           |              |------------->|             |         |
|    :           :              :              :             :         :
|    |           |              |              |             |  INVITE |
|4   |           |              |              |       SETUP |<========|
|5   |           |       INVITE |<~~~~~~~~~~~~~~~~~~~~~~~~~~~|         |
|6   |    INVITE |<=============|              |             |         |
|7   |<==========|              |              |             |         |
|    : BYE       :              :              :             :         :
|8   |==========>| BYE          |              |             |         |
|9   |           |=============>| DISC         |             |         |
|10  |           |              |~~~~~~~~~~~~~~~~~~~~~~~~~~~>| BYE     |
|11  |           |              |              |       Fetch |========>|
|12  |           |              |              |<------------|         |
|    |           |              |              | ValExchange |         |
|13  |           |              |<:::::::::::::::::::::::::::|         |
|    |           |              |              | ValExchange |         |
|14  |           |<::::::::::::::::::::::::::::::::::::::::::|         |
|    :           |              :              :             :  INVITE :
|15  |           |              |              |      INVITE |<========|
|16  |           |       INVITE |<===========================|         |
|17  |    INVITE |<============ |              |             |         |
|18  |<==========|              |              |      INVITE |         |
|19  |           |<==========================================|         |
|    |    INVITE |              |              |             |         |
|20  |x==========|              |              |             |         |
|    |           |              |              |             |         |
|
|The first 3 steps are identical to the first diagram, but now PhoneB calls
|PhoneA, call that goes through the PSTN and reaches ProviderA before Enterprise
|(4, 5, 6,7).  The call ends the same way than in the previous diagram (8, 9, 10,
|11), excepted that now it is ProviderB that initiates the verification.  When it
|fetches the Node-Ids responsible for PhoneA (12), it receives two of them, which
|is not an abnormal case.  As per the rules in VIPR, it will initiates a PVP
|connection to both of them, but what is new is that *both* will succeed.  Per
|the current rules, only the last one will be kept, but again there is a 50%
|chance that the route kept is not the best.  Instead I suggest to keep *both*
|and to use *both* for the subsequent call, by forking it to the two destinations
|(15, 16 and 19).  In the best case, both requests will reach PhoneA (17, 18, 20)
|and the second will be rejected (20), thanks to the "Merged Requests" rule in
|RFC 3261 section 8.2.2.
|
|An additional problem that need to be fixed in the spec is that we need to
|clearly defines which SIP error codes are used to simply signal that the route
|does not work at the time of the call, and which one are used to remove a route
|from the VIPR database.
|
|B.4. RELOAD registration
|
|Let's now move to the interactions between the VIPR domain and the RELOAD
|overlay.  The current specification states that a phone number must be
|registered 3 times, which with the underlying replication done by the CHORD
|RELOAD algorithm, means that the mapping between a PVP server and a phone number
|is stored 9 times.  The problem discussed in Quebec City was what to do when the
|3 copy retrieved from the overlay are not identical, and the proposal was to use
|the copy that appears at least twice, so no peer can alone create a denial of
|service for a specific number.  The discussion moved to the reasons for having 3
|copies in the first place.
|
|The proposal is to drop the requirement for the 3 copies from VIPR, but to add
|the requirement that the node requesting the phone number MUST also fetch (or
|stat) the 2 additional replicas and use the value that matches at least one
|other copy (using a majority vote prevents a rogue peer to block the access to
|the phone numbers currently stored here).  If not all 3 copies are equals, then
|an incident must be logged.  The PVP client must retrieve the 2 replicas in
|addition to the original registration and use the voting algorithm to choose one
|and log an incident if all 3 are not equal.
|
|B.5. PVP Privacy
|
|As reported by Michael Procter, there is ways with the current PVP methods to
|discover valuable information about a competitor.  But first let's add some
|common vocabulary related to PVP:
|
|- - The PVP selector is a list of parameters that are sent by the PVP client side
|to retrieve a set of call records in the PVP server side.  The set can be empty,
|in which case the validation fails, can contain one element, or can contain
|multiple elements in which case the method description must also defines what
|call record should be selected (e.g. in the case of method "a", the most recent
|call record is selected).  One important point is that the selector is always
|passed from the PVP client to the PVP server in clear, and so this is where the
|privacy leakage happens.
|
|- - The PVP parameter is a list of name/value pairs that are passed in clear
|between the PVP client and PVP server to aid the verification.  Examples are the
|rounding value and the vservice id for methods "a" and "b".
|
|- - The PVP secret is the information that each side of the PVP transaction tries
|to verify.  The algorithm used (SRP) uses a zero-knowledge password proof, so
|neither side can deduce the secret if the verification fails.  In the case of
|methods "a" and "b" the secret is the rounded start and end time for the call,
|but there is a lot of other possible secrets that can be used in new methods
|(DTMF, UUIE, fingerprint, SMS hash, etc...).
|
|In the privacy issue, the problem is that callee number and caller numbers are
|disclosed in the PVP selector for method "a" and the callee number is disclosed
|in the PVP selector for method "b".
|
|One proposed solution would be to hash these numbers, but finding the phone
|numbers would still be trivial for a determined competitor.  Passing the hash
|salt as a PVP parameter and using an adaptive hash method like bcrypt will force
|the PVP server to rehash all the current terminating call record, but will force
|a competitor to rehash probably half of the total E.164 space to find the
|numbers.  This is still possible but can provide an adequate privacy protection
|level.
|
|Another possibility would be to invert the selector and the secret.  After all
|the star/stop time of a call is not as sensitive as the caller/callee phone
|numbers.  In this method the PVP selector would be the start/stop time and the
|secret would be the caller/callee numbers.  The problem is that it will be more
|difficult to design an algorithm to select a unique call record if the returned
|set contains more than one.  One solution could be to add more data in the PVP
|selector, for example by adding the call initiation time and the direction of
|the termination.
|
|B.6. PVP Methods Registry
|
|On the PVP subject, The VIPR specification currently defines two methods for the
|PSTN validation:  Method "a", which is used when the Caller-ID is available and
|method "b", which is used when it is not.  The PVP draft also permits to define
|new validation methods, but it does not explain when and how to use this
|extended methods.
|
|This proposal is in two parts.  First we need to establish a IANA registry for
|the PVP methods, and to assign a priority to each of these method.  Let's say
|for now that the priority is between -∞ (lowest priority) to +∞ (highest
|priority) and that priorities should be assigned by steps of 100.  With this
|scale, we could assign priority 0 to method "b" and priority 100 to method "a".
|Then we say in the spec that a VIPR server must try available methods starting
|from the highest priority to the lowest priority, until one succeeds or all
|fail.  This implements the same algorithm that is currently in -pvp ("a" first,
|then "b").
|
|Now the problem with this is that the number of methods will increase in the
|future, but we may not want that the PVP client tries all the methods available
|each time.  So the second part of this proposal is to have each VIPR domain
|publishing the list of methods supported by each of its phone numbers in the
|RELOAD distributed database, in the existing VIPR-REGISTRATION resource record.
|
|With this information, the PVP client immediately knows what methods to try from
|the VIPR-REGISTRATION record, and the order to try them from the IANA registry,
|and can also accumulate statistics on the usage of unsupported methods.
|
|The PVP server can use this mechanism to simplify the process.  For example if
|it knows that it will never receive the Caller-ID, it just have to never
|advertize the "a" method.  Another example is with analog FXO ports that cannot
|be used with either method "a" or "b".  In this case the VIPR server can still
|advertize a new method using DTMF or fingerprint.
|
|Note that because the methods supported per phone number are stored in the
|RELOAD distributed database, the SIP call agent cannot retrieve them to decide
|what method to use when starting a call, as it would take too much time to
|retrieve it (same reason the validation is not done in realtime).  But it can
|query them in the background using the history of calls or just before
|scheduling a re-validation.
|
|I would also propose to move the description of the generic PVP algorithm to the
|- -framework document, to add a section in -framework explaining how to register a
|new method on a IANA registry and to keep the two existing methods ("a" and "b")
|into the -pvp draft.
|
|B.7. PVP Entropy
|
|A second issue related to PVP is the management of entropy (Section 10.1 of the
|- -pvp draft).  The idea is that the fact that one validation succeeds is not
|always enough for a remote VIPR server to give back routes and ticket for this
|destination.  For example a VIPR domain could decide that at least 3 different
|calls validated with method "b" are needed to let a SIP call reach the endpoint.
|
|This proposal describes a mechanism for PVP to implement this.  The idea is that
|when a PVP validation succeeds, the PVP server will return a ticket but may not
|return the list of routes if the entropy threshold is not reached.  The ticket
|will contain an opaque value set by the PVP server that contain the level of
|entropy that this caller has reached.  The PVP client stores the ticket but does
|not notify the call agent as there is no routes available.  The next time the
|PVP client has a successful validation with the same destination, it sends the
|saved ticket in addition to the domain.  The PVP server then evaluates the
|ticket, increases the entropy value stored and sends back a new ticket.  If the
|threshold has been reached, then the PVP server sends back the routes at the
|same time, routes that the PVP client can now send with the ticket to the SIP
|element.
|
|When renewing the routes/ticket, the PVP client also sends the existing ticket,
|so the PVP server can decide to lower the threshold based on the entropy
|collected the previous time and the date of the ticket.
|
|This can be combined with the proposal for method priority.  If multiple methods
|are available for a destination but the first that succeeds does not return the
|routes then the PVP client can use the next available methods in the list to try
|to increase the entropy and receive them.
|
|A PVP server may even use different thresholds, depending on the domains to
|validate.  This then becomes an extension to the white/black list, where a
|blacklist is implemented as a default threshold of X and an infinite threshold
|for the domains blacklisted, and where a whitelist is implemented as a default
|infinite threshold and a threshold of X for the domains whitelisted.
|
|B.8. Ticket vs Client certificate
|
|In the current specification, the PVP server builds and signs a VIPR ticket, and
|sends it back to the PVP client, which passes it to the SIP element.  The SIP
|element will insert this ticket in the next SIP method to the remote SIP
|element, which will check the validity of the ticket and the domain of the TLS
|client.
|
|There is multiple problems with this process:
|
|- - The verification of the ticket use HMAC-SHA1, and so the same password has to
|be provisioned in both the SIP element (to verify the ticket) and the PVP server
|(to generate the ticket).
|- - The ticket can be used without TLS, and we all know that implementers think of
|MUST as SHOULD and SHOULD as MAY.
|
|So the proposal would be to replace the ticket by a client certificate, which
|could work like this:
|
|Instead of using a symmetrical key, the local PVP server generates an RSA key
|pair, with the public key distributed to the SIP element(s).  After a successful
|PVP connection, the remote PVP client sends a PKCS#10 certificate request,
|containing the domain name and signed with a private key.  The local PVP server
|generates a new certificate, sign it with its private key and send it back to
|the remote PVP client, which pass it back to the remote SIP element.
|
|The remote SIP element will use the certificate received to establish the TLS
|connection for the SIP transactions to the local SIP element, which will use a
|standard CA based certificate for its own domain.  The local SIP element will be
|able to verify with the PVP server public key that it issued the certificate,
|then will validate the standard parts of the certificate (expiration date and so
|on).
|
|There is multiple advantages to this proposal:
|
|- - The private key is stored only in the PVP server, or better in a physical token.
|- - VIPR does not work without TLS for the SIP connection.
|- - There is plenty of commercial or free TLS and X.509 implementations that have
|years of experience and testing, which is not the case for the ticket proposal.
|- - Security agility is provided by TLS.
|- - No additional SIP Header.
|- - Because the ticket verification process is folded into the client certificate
|verification, less processing resources are needed.
|
|B.9. Ticket renewal
|
|Another thing that was discussed in Quebec City was the "First Call Problem",
|i.e. the problem that it takes up to 48 hours to verify a call and been able to
|use enhanced media.  I think the conclusion of the discussion was that it was
|not too annoying for the first call, as it did not degrade the user experience.
|On the other hand, the cryptographic ticket granted after the first has an
|expiration date and so need to be renewed, and that will degrade the user
|experience as it would mean that for each destination, the end-user will
|periodically not be able to use enhanced media for the duration of a call.
|
|There was multiple proposals at the microphone to solve this problem, but I
|would like to detail the one I proposed.
|
|The idea is, sometimes before the expiration of the ticket, to make in parallel
|a PSTN call and a SIP call using the existing SIP route and ticket for the
|enhanced media (let's say video for the remaining of this discussion).  There is
|already an existing I-D that can be use for this, draft-ietf-mmusic-sdp-cs.  The
|way it could work is that the call agent, after retrieving the SIP route and
|ticket for a destination, will decide that it is time to revalidate the route,
|based for example on the frequency of calls to this number and the remaining
|validity of the ticket.  The SIP element then adds an additional m= line to the
|SDP that contains a PSTN address.  The offered SDP then looks something like this:
|
|v=0
|o=- 2890844526 2890842807 IN IP4 10.47.16.5
|s=
|c=IN IP4 10.47.16.5
|t=0 0
|m=audio 49170 RTP/AVP 0
|m=audio 9 PSTN -
|c=PSTN - -
|a=setup:active
|a=connection:new
|a=cs-correlation: uuie callerid dtmf
|m=video 51372 RTP/AVP 99
|a=rtpmap:99 h263-1998/90000
|
|The SIP element on the other side verifies the ticket then starts to process the
|SDP.  If it does not support this feature then, as per the rules in RFC 3264, it
|will reject the second m= line by using port 0 in the answer SDP (In this case
|the end user will have to have PSTN only calls for th e48 hours after the
|expiration of the ticket).  If the remote SIP element supports this extension
|then it will send back an offer like this:
|
|v=0
|o=- 0 1 IN IP4 192.168.2.1
|s=
|c=IN IP4 192.168.2.1
|t=0 0
|m=audio 8000 RTP/AVP 0
|m=audio 9 PSTN -
|c=PSTN E164 [phone]
|a=setup:passive
|a=connection:new
|a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3
|m=video 9000 RTP/AVP 99
|a=rtpmap:99 h263-1998/90000
|
|The local SIP element checks that the c= line contains the right number, then
|establishes the audio and video media over IP, as usual, but also starts a PSTN
|call following the rules in draft-ietf-mmusic-sdp-cs (i.e. sending the
|correlation value as needed).  The remote SIP eleemnt will receive the PSTN
|call, and correlate it with the existing SIP connection.  Both parties must send
|audio on both the IP and the PSTN side, but the receivers can choose to play the
|audio coming from either the IP or PSTN connection (this is because we may want
|to use in the future fingerprint methods for the validation).  The PSTN call is
|ended at the same time than the IP connection if the methods used for validation
|are based on the call duration (other methods may permit to end the call
|before), so the VCRs are processed as for an initial call.  The local party
|marks the route as been under revalidation, so to not use the renewal method for
|the next 48 hours.  The VIPR server will send a notification before the end of
|the 48 hours if there is still a PSTN route to this destination.
|
|- --
|Marc Petit-Huguenin
|Personal email: [e-mail]
|Professional email: [e-mail]
|Blog: http://blog.marc.petit-huguenin.org
|-----BEGIN PGP SIGNATURE-----
|Version: GnuPG v1.4.11 (GNU/Linux)
|
|iEYEARECAAYFAk57UY8ACgkQ9RoMZyVa61fC7wCeMvf3WWwQrkQrOCFrsKs9Ob3h
|K6AAn03ucyFddSp7wz8RTgpXAsiTkU8d
|=DW23
|-----END PGP SIGNATURE-----