Subject: [VIPR] Minutes for 2012/01/13 conference call

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 16 Jan 2012 07:26:10 -0800

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

o Attendees:
  Mary Barnes
  Daryl Malas
  Hakim Mehmood
  Marc Petit-Huguenin
  Jon Peterson
  Michael Procter
  John Ward
  Dean Willis

o Regrets

  Muthu Arul Mozhi Perumal

o Agenda

- - Action item list from Taipei
- - PVP Entropy
- - VIPR troubleshooting
- - Infrastructure overlays
- - ICE support in VIPR

o Action items

- - Mary to talk to Eric Burger about his review of -overview.
- - Methods priorities will be in documents, not in registry.
- - SIP intermediaries discussions postponed.
- - Add the probability equation in -proportional-quota.
- - Blacklist methods in configuration file.
- - Add text to say that client must check the replicas at write time.
- - Fix the multiplier in reload-usage when proportional-quota is finished.
- - Add text for entropy processing on server side.
- - Modify ticket to support crypto agility.
- - Chairs/Mary to talk to Richard Barnes about security review.
- - Add text or new I-D about ticket renewal using the -cs draft.
- - Request time in DISPATCH agenda for the infrastructure-overlay draft.
- - Work on troubleshooting document with input from Cisco developer.

o Minutes

- - Action item list from Taipei

Marc: It was requested in Taipei for more reviews for the -overview draft
before adopting it as a WG item.  Eric Burger volunteered.

Mary: I'll talk to him.

Marc: Do we want more reviews?

Mary: That would be great.  Do we want an early security review to have their
feedback?

Marc: Richard Barnes volunteered to do a security review.

Mary: I'll talk to him too.

Marc: Any other volunteer?

[no volunteer on the design team]

Marc: Next item; the idea of having a method priority was well receiving. One
comment from Jon was if we want the priority on the registry or on the document.

Jon: The registry can change but not the documents.

Marc: OK, let keep the priority in the document.

Marc: I propose that we continue to postpone the discussion about SIP
intermediaries.

[no comment]

Marc: We still need to add the probability equation in -proportional-quota.

[no comment]

Marc: Someone in Taipei suggested to add the possibility of blacklisting PVP
methods, perhaps also in the registry.

Jon: Is it implementation specific?

Marc: We need first the method registry, to give a name to methods, then we
can put the name in a section of the XML configuration file, so neither a PVP
client or server use it.  This way at least the two sides have to agree to do
bad things.

Marc: There was support to have the PVP methods inside the RELOAD overlay.

[no comment]

Marc: We had the final decision on the multiple copies in Taipei, but there
was no consensus on what to do about the voting algorithm, which is to use a
RELOAD entry only if we retrieve at least two identical copies.

Hakim: The idea was to have some sort of redundancy.

Marc: Cullen explained in Taipei that it was done because there was very
little experience about this, but he did not see any problem, so it's not
necessary to keep that.  There was also a discussion about making it
configurable, and that was not accepted.  The only remaining question is about
the voting algorithm.  A rogue node can fake only the entries it has, so the
probability of having two replicas controlled by the same rogue node is low.
On the other hand we do not want one rogue node to prevent access to an entry.

Michael: If the rogue node is the primary for that key, it could just not
propagate the replicas.

Marc: Right, so we need to add some text saying that when a node write an
entry, it should read back the 3 copies and log an error if the 3 are not
identical.

Marc: I need to fix the multiplier in reload-usage as soon proportional-quota
is done

[no comment]

Marc: Method A was changed to use bcrypt hash for the caller-id, so it is no
longer in clear.  We need to add some security text explaining the
shortcomings.  We still need to decide what is the minimum cost we want for
cracking one caller-id.

[no comment]

Marc: People were interested in the idea of a new method that inverts the
selector and the secret and there was an agreement that a new document should
be prepared for this.  There was also some interesting comments about
dynamically allocating parts of the caller-id into the selector.

[no comment]

Marc: There was consensus in Taipei that entropy should be used, but there was
concerns about the minimum entropy so we agreed that the minimum default value
must be in the configuration file.  What was not decided was between the
server side and client side processing.

Jon: We should discuss this.

Marc: OK, let's finish the discussion about Taipei, then we will go back to
this topic.

Marc:  We agreed in Taipei that the ticket need to be modified to support
crypto agility, but must have a recommended algorithm.  The X.509 proposal was
rejected in Taipei, so the proposal is withdrawn. Another discussion was about
asymmetrical keys vs symmetrical keys, but there was no conclusion.  Richard
Barnes proposed to do a security review.

Jon:  The chairs will talk to him.

Mary: I will too.

Marc: I will modify the specification about the crypto agility.

Marc: Last topic was renewal of ticket.  The solution proposed was to use the
- -cs draft from MMUSIC.  I will either write a new spec or modify one.

[no comment]

Marc: Next topic was infrastructure overlay.  We had one slide in DISPATCH,
but no comments.  There was also no comment in the VIPR mailing-list.  The
document currently only have the requirements but I have a proposal on how to
do this. What should we do?

Mary: The focus of the DISPATCH discussion will be on the problem and
requirements, but sometimes having a solution proposal helps people understand
the problem.

Marc: I will put my solution inside an appendix of the draft, and I will send
an official request to DISPATCH for time in Paris.  Any volunteer to help?

[no comment]

Marc: About troubleshooting, there was one additional request from Cullen to
have a way to trigger the PVP process immediately after the call, which is
useful not only for troubleshooting but also for demo.  We probably need to
put this in a separate document, informational or bcp.  Is there a volunteer
for this?

Hakim:  We did implement a set of functions to troubleshoot, and I can
schedule a call with the developer who implemented this.

Marc: That would be very helpful.

Marc: Back to the PVP entropy discussion about server side vs client side.

Mary: What is the big advantage you see on having it distributed?

Marc: The server does not have to manage an additional storage.  Also it
solved the problem of knowing when to remove old logs.

Michael: Does the client present the ticket it received the last time?

Marc: Yes.  We have to change the protocol in both cases, because the PVP
transaction may succeed, but the subsequent ValExchange transaction will not
return any ticket and SIP route.

Jon: Calling it a ticket is confusing.  It more a provisional material.  My
problem with this is that it does not make much difference, but it's probably
not a small change.

Marc: To advance the discussion, I propose to add the text for the server-side
processing, and we can define the client-side processing as an extension.

Michael: I am interested in the proposal as the client can convince itself
that it is worth trying a new call with the same server.

Marc: Yes, it is part of the common specification.

Hakim: OK

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org