[VIPR] Minutes for 2011/10/28 conference call

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

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

VIPR Design Team conference call on Friday October 28th, from 9:05am to 9:55am PST.

o Attendees:
  Mary Barnes
  Daryl Malas
  Jon Peterson
  Marc Petit-Huguenin
  Michael Procter

o Regrets:
  Hakim Mehmood
  Muthu Arul Mozhi Perumal
  John Ward
  Dean Willis

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

o Action items

- - Remove method "a" and design method "c" that will hash the Caller-ID.
- - Incorporate some text about ticket renewal.
- - Add more text on ICE, TLS (but no profile).

o Minutes

- - Agenda

Marc: I propose to have one more conference call next week, then to restart the
work on November 28th, after the IETF meeting.

Daryl: No objection.

- - Replacement ticket by client certificate

Marc: The discussion stalled on the certificate vs ticket discussion in the
mailing-list, mostly my fault.

Jon: It's a major change, so we should have a requirement process.  Second
running a CA is really complicated, and requiring all this system to constantly
acting as CA is not optimum.  Created certificates like this really is overkill.
My 3rd point is that binding this with TLS does not seem to fit with SIP.  I
think that putting the signature is an header is a better idea, but there is
thousand of other solutions and this seems disproportionate.

Marc: You have a point that using the ticket as certificate for TLS is a
problem, as it permit people to sell their tickets.  As for the discussion about
CA, the proposal is just to use X.509 as a container for everything that is
already in the ticket.  It's just a format change, and the only difference is
for the developer, where libraries are available for X.509, but not for the
Ticket.  This is not different from what RELOAD is doing.

Jon: [audio garbled]

Marc: Yes in RELOAD you send a key, it send back a certificate, it would be the
same thing.

[audio lost]

- - PVP privacy

[audio lost]

Michael: [...] the data will be significant for someone, so whether it's 48
hours or 2 years, that will be wrong for someone.

Jon: We can design methods to increase the duration.  We just need an argument
that people won't laugh at.  Definitively it can't be two years.

Marc:  What I mean is that it will take 2 years to crack the hash.

Jon: Yes.  We need to say something that we can put defensively in the draft.

Marc: So do we want to keep method "a" as it is and define a method "c" that is
hashing the Caller-ID, or replacing method "a' by hashing the Caller-ID, or do
we want to do sometime else?  My preference is for the first one.

Michael: OK

Mary: OK for method "c".

Jon:  Let's get rid of method "a" and make method "c".

- - PVP method entropy

Marc: We were stuck on the method entropy in the last meeting, so I sent the 3
solutions in the mailing-list.  #1 is we do not care about entropy, #2 we care
but it's done purely on the server side, #3 we care about entropy but the
storage is done in the client side.

Michael: Instead of a cookie, can it be stored in the Ticket?

Marc: This was the plan, and you need this, to authenticate the entropy. The
idea is to add a field that contains the entropy accumulated, and you resent
your ticket for the next PVP transaction.  The server validates, adds entropy
and resends a new ticket.  We need protection against someone using twice the
same call to accumulate entropy.  The easiest way for us is to do everything in
the server, because we do not need text for that.  Or we can make things easier
for deployment, which is to do this on the client side.

Jon: I want to get sufficient entropy, but I am not sure how much we get with
PSTN calls.

Marc:  Yes, that's the first choice, one call, one route.

- - Ticket renewal

Marc: We discussed that in Quebec City, but without conclusion, and I made a
proposal later. The idea is that it is acceptable to have a first call on the
PSTN, but it is not acceptable to have periodical PSTN calls after this to renew
the ticket. My proposal uses a draft which is in last call, and which is named
- -sdp-cs.  This permits to trigger a PSTN call based on an INVITE.  So just
before the expiration of the ticket, one of the call is selected to use PSTN and
Internet in parallel.  The PSTN call is used to trigger a validation.  The
advantage is that you do not switch back to PSTN.  The problem is that you need
to have access to the media, so SIP intermediaries could not use that.

Michael: On this approach, you run the audio on the PSTN?

Marc:  You need to run the audio on both the PSTN and Internet because if we
invent a new validation method in the future, like fingerprint, we need to
recognize it on the PSTN.  And we still need audio on the Internet side, because
of wideband audio.

Michael: Do we use the normal process, or is it more realtime?

Marc: It is possible to use a method based on call duration, and the calling
side can just use a random duration for the call.  If for example the method is
based on fingerprint, the call can hangup immediately.  And this can provide us
a path to a quicker validation.

Jon: This is probably on the right track.

Marc: I will try to incorporate something like this in the document.

- - Infrastructure overlays

Marc: We have to start thinking how VIPR will be deployed. And for VIPR to work,
we absolutely need to have only one overlay.  So the question is how to achieve
this goal.  So I submitted a draft to DISPATCH about Infrastructure Overlays.
This draft contains only requirements.

Michael: On the subject of having one overlay all around the planet, how does
that square with previous discussions where we said that VIPR is not intended to
be used by service providers or international grannies?  We seems to try to make
one universal thing that is not quite universal.

Marc: I do not agree that this thing is not for everybody.

Jon: The IETF is not in the business of mandating this, it is in the business of
mandating what needs to be implemented in order to make interoperability work.
The discussion we had about VIPR not been for service providers has been about
the fact that VIPR is different from ENUM or SPEERMINT is.  The discussion about
this been for theses people is separate from the administrative problem of
having one overlay.  If there is islands of VIPR, then we made a mistake.

Marc: There is some precedents to this in the IETF, like the DNS, ENUM and all
the arpa stuff.  So if someone want to participate in VIPR, how are we sure that
they are all in the same overlay?  Another related problem is that because VIPR
is automatic, you do not have the possibility to do a interop test between VIPR
domains.  So we need to have a profile to make the calls.

Jon: I would hesitate to say that we need a SIP profile.  SIP has negotiation
mechanism and VIPR should not constraint what VIPR should do.  VIPR permits to
do things that cannot be done today, but it should not require to do those
things.  Do you mean that we should profile codecs, or you should not do VIPR if
you do not support Opus?

Marc: Do we want to let people use G.711 after receiving a VIPR route?

Jon: That would be pointless,  But I see profile as a narrow list of things that
need to be supported, There is a bunch of wideband codecs, or video codecs and
other things that we should not have in the future.  We can say that wideband
should be supported, or what the options are, but mandating would be a mistake.

Marc: I agree, but if you say that you need to support wideband, you still need
a baseline.  Do we want to have a SIP call failing after receiving a route?

Jon: But, for example, having presence alone would be worth it, so I would
really hesitate that we would mandate something.

Daryl: I agree with that.

Michael: I agree also.  But we should specify things like TLS or ICE support and
providing more guidelines to improve the probability of successful calls.

Mary: I agree too.

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

iEYEARECAAYFAk6x1x8ACgkQ9RoMZyVa61fFKwCgja8ClzlLVwcr7nhGtHytAD4N
FiMAn1mAOHbVRq22o8B4Be1kBkAITQ0V
=wz++
-----END PGP SIGNATURE-----