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

["Hakim Mehmood (naim)" <[e-mail]>]

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