[VIPR] Agenda & Handout for 2011/11/04

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

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

A. Agenda

- - Drafts update
- - Replacement ticket by client certificate
- - PVP Entropy
- - VIPR troubleshooting
- - ICE support in VIPR

Note that the topics that cannot make it to the discussion will be postponed to
the IETF meeting 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. Drafts update

The -overview draft is still waiting for some text in the security section.
The -privacy-concerns draft was not updated.
The -proportional-quota draft was moved back to the VIPR WG, but is still
missing the equation for the probability.
The -reload-usage draft was updated as discussed (removed storage 3 times, and
added methods in registration).
The -pvp draft was updated (method "a" use hashed Caller-ID, perhaps should have
been new draft).
The -sip-antispam was not updated (needs ticket renewal, more text on ICE, etc..)
The -overview draft is empty so far (needs at least method registration template)
The -sip-intermediaries was not updated.
The -infrastructure-overlays draft was not updated.

New draft: Inverting secret/selector?

B.2 Replacement ticket by client certificate

The discussion is still stuck on using X.509 certificate as a container for the
Ticket data.

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

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?

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

iEYEARECAAYFAk6yqqUACgkQ9RoMZyVa61eOnQCfQlUrSGJiooaF06q/vdluqLP5
6wYAnjj9GqlT+RLmXcdqLCK4OMR7fMbb
=8IC4
-----END PGP SIGNATURE-----