[VIPR] Agenda & Handout for 2012/01/13

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

A. Agenda

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

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. Action items list from Taipei

This is the list of decisions and TODO extracted from the minutes and the audio 
recording (The minutes from the meeting in Taipei are available at: 
http://www.ietf.org/proceedings/82/minutes/vipr.txt)

- Eric Burger to send a review of -overview before it can be adopted as WG document.
- PVP method priority accepted, but need to decide if in registry or document.
- SIP intermediaries:  Comments on the list.
- Fix the equation in proportional-quota.
- Add support to blacklist methods in the configuration (and registry).
- OK to store methods in RELOAD.
- Remove 3 copies, and use voting algorithm.
- Fixes multiplier in reload-usage as soon proportional-quota is done.
- Method A: Add text about using EC2 to evaluate the complexity for given 
cost/phone number.
- Create new document for method C: inverted selector/secret, with dynamic 
allocation of entropy.
- General idea of entropy adopted, with minimum default value in configuration. 
  Still need to decide if client support.
- Ticket needs to be modified to support crypto agility, with recommended algo.
- X.509: Rejected.
- Asymmetrical keys: Richard Barnes to do a security review.
- Renewal of ticket:  Solution proposed adopted.
- Infrastructure overlay: will be presented in DISPATCH in Paris.
- Troubleshooting:  Needs also a test mode for immediate PVP processing.

B.2. PVP Entropy

The decision in Taipei was to support the entropy mechanism, and to carry the 
minimal default value in the configuration file.  We still have to decide 
between these two solutions:

1. Entropy is best managed completely in the PVP server.
2. It is best managed in both client and server by using something like a 
cookie, stored in the ticket.

B.3. 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 that we need to
provide help for debugging problems if things go wrong.

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.

There is also a need to have a mode that permit a immediate execution of the PVP 
process, for troubleshooting purpose.

B.4. 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.5. ICE support in VIPR

Section 1.2.1 of draft-procter-vipr-privacy-concerns proposes to use TURN to
anonymise the source of a PVP validation.  This proposal is probably incomplete,
but the main problem is that we still do not know what transports will be used
on the RELOAD overlay used by VIPR.  First here's a list of what we currently
know about this overlay:

- The algorithm is RELOAD-CHORD
- The Node-ID size is 16 bytes (128 bits).
- Clients are not authorized because of the quota algorithm.
- Self-signed certificates are not authorized.
- There will be one or more root-certs.
- There will be one or more bootstrap peers (unicast or anycast - no multicast).
- Clients are not authorized because of the quota algorithm.
- Shared secret are not used.
- The overlay link protocol is TLS.
- There will be a list of kind and configuration signers.
- The urn:ietf:params:xml:ns:p2p:config-chord, urn:ietf:params:xml:ns:p2p:quota
and urn:ietf:params:xml:ns:p2p:vipr extensions are mandatory.
- The Kind VIPR-REGISTRATION will be authorized.

What we do not know yet:

- Do we need to authorize the CERTIFICATE-BY-NODE and CERTIFICATE-BY-USER Kinds?
- Will TURN server deployed in the overlay?
- Will ICE overlay link protocols be used?

The important question for this topic is the support of ICE in the RELOAD overlay:

Pros:  With ICE support the RELOAD nodes, the PVP client and the PVP server can
be installed behind a NAT/Firewall without having to put them on the DMZ or to
open pinholes (the bootstrap servers will still need to be installed in the DMZ
or on the Internet).  TURN servers are required for ICE support, so they would
also be available for anonymising the connections.

Cons:  ICE is complex to implement and debug.

If we decide to exclude ICE, then the TURN servers are no longer available by
default, and the idea of using them for anonymising the connections is moot.

An additional consideration is that the RELOAD transports are currently limited
to UDP and TCP, neither of them being really well suited to carry RELOAD or PVP
messages.  If we decide to exclude ICE support, I will then propose to use
(D)TLS over SCTP instead (and write the I-D for this).

So the initial question is:  Do we need ICE or not?