[VIPR] Agenda & Handout for 2011/10/28

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A. Agenda

- - Replacement ticket by client certificate (10 min)
- - PVP privacy (10 min)
- - PVP method entropy (10 min)
- - Ticket renewal (10 min)
- - Infrastructure overlays (10 min)
- - VIPR troubleshooting (10 min)

Note that the sum of the time allocated to each topic may exceeds 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).


B. Handout (reading time: 10 min)

B.1 Replacement ticket by client certificate

The discussion did not progress since the previous call. Jon position is that
there is ways to have distributed components that does not require replicating
secrets, that TLS brings algorithm agility but we will still have to define a
profile, and that using X.509 certificates does not add any value.

My position is that an X.509 certificate with symmetrical keys is better than an
adhoc cryptographic ticket.

B.2. PVP Privacy

Michael Procter published an Internet-Draft summarizing all the privacy issues.
 Two things were discussed on the mailing-list:

First that restricting a domain to a particular list of methods does not
prevents other domain to use less private methods.  They need to be fixed or
being removed.

Second I proposed to hash the Caller-ID in method "a" in a way that make it
difficult to retrieve, by using bcrypt.

B.3. PVP Entropy

The discussion at the end of the previous conference call stalled on what to do
about entropy.  There is 3 possibilities:

1. We do not need to manage entropy because we do not want to have the user
making multiple PSTN calls before receiving a SIP route.
2. We need to manage entropy, but it is best managed completely in the PVP server.
3. We need to manage entropy, but it is best managed in both client and server
by using something like a cookie.

B.4. 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 re-validate 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 the 48 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 element 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 re-validation, 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.

B.5. Infrastructure overlays

A new draft to discuss infrastructure overlays has been submitted to DISPATCH.

"[RELOAD] is a peer to peer protocol developed by the P2PSIP Working
 Group.  Each RELOAD instance has a unique name, which is used by the
 process in section 10.2 of this specification to find the
 configuration servers, enrollment servers and bootstrap servers
 needed to join the overlay.  The process assumes that the RELOAD
 instance name is a FQDN, and uses the process in [RFC2782] (SRV RR)
 to find the IP address of the HTTPS server that serves the
 configuration document for this overlay.

 This process is adequate when the management of the overlay does not
 need to be distinguished from the owner of the FQDN used as the
 instance name, which is the case most of the time.  But there is a
 special class of overlays that, by definition, requires to be unique
 on the Internet and for which having the possibility of create
 instances would defeat their very purpose.  This specification calls
 the kind of overlays that are not domain specific, but application
 specific "infrastructure overlays".

 [VIPR] is a technology that is being standardized in the VIPR Working
 Group and that aims to build bridges between SIP islands by
 automatically provision SIP routes after the "ownership" of a PSTN
 phone number has been verified by an actual PSTN phone call.  This
 technology uses an RELOAD overlay as a distributed database where
 mappings between phone numbers and servers responsible for the
 validation process are stored.  The promise of VIPR to bridge these
 SIP islands cannot be fulfilled if there is more than one distributed
 database storing these mappings."

B.6. VIPR troubleshooting

One very important point made in draft-jennings-vipr-overview is the
troubleshooting problem (section 2.4).  Because the provisioning of SIP routes
is automatic, there is no possibility to have a interop testing between two
domains before the establishment of the fist call.  This means two things:

- - We will need in the future to define a SIP profile that defines exactly what
SIP extensions and media are supported (I propose to call this profile
SIPbeyond).  I think that we have a common goal here with the RTCWEB WG, and
should probably work with them on this.

- - We need to provide help for debugging problems if things go wrong.

For the latter, the main issue is that it is not always possible to troubleshoot
a problem only by looking on the logs and traces on the sending side - some kind
of cooperation is required by the receiving side.  Having a way to retrieve the
logs and traces automatically would be a good step in this direction, but we now
have a security problem to take care of, as we certainly do not want anybody to
be able to retrieve this information.


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)

iEYEARECAAYFAk6pdrwACgkQ9RoMZyVa61d3igCfTFT/y7CruJ6d8yh6cWr1ISHx
a7QAn1UmIBobhAdgfjeJJ2XtuFx99Qgu
=JReu
-----END PGP SIGNATURE-----