Re: [VIPR] PVP entropy

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

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

The discussion on the subject of PVP entropy on the last conference call did not
reach consensus.  The -pvp draft already contains a placeholder for discussing
entropy (section 10.1), so we need to do something about this.  The various
proposals were:

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.

My proposal is 3, as detailed below.  I think that 1 would exclude too many
participants in VIPR, so I oppose it.

On 09/04/2011 01:53 PM, Marc Petit-Huguenin wrote:
> Section 10.1 of the -pvp draft is an empty section that is supposed to describe
> how to aggregate entropy.  The idea is that the fact that one validation
> succeeds could not be enough for a remote VIPR server to give back routes and
> ticket for this destination.  For example a site could decide that 3 different
> calls validated with method "b" are needed to let a SIP call reach the endpoint.
> 
> This proposal describes a mechanism for PVP to implement this.  The idea is that
> when a PVP validation succeeds, the PVP server will return a ticket[1] but may
> not return the list of routes if the entropy threshold is not reached.  The
> ticket will contain an opaque value set by the PVP server that contain the level
> of entropy that this caller has reached.  The PVP client stores the ticket but
> does not notify the call agent as there is no routes available.  The next time
> the PVP client has a successful validation with the same destination, it sends
> the saved ticket in addition to the domain.  The PVP server then evaluates the
> ticket, increases the entropy value stored and send back a new ticket back.  If
> the threshold has been reached, then the PVP server sends back the routes at the
> same time, routes that the PVP client can now send with the ticket to the call
> agent.
> 
> When renewing the routes/ticket, the PVP client also sends the existing ticket,
> so the PVP server can decide to lower the threshold based on the entropy
> collected the previous time and the date of the ticket.
> 
> This can be combined with my proposal for method priority.  If multiple methods
> are available for a destination but the first that succeeds does not return the
> routes then the PVP client can use the next available methods in the list to try
> to increase the entropy and receive them.
> 
> A PVP server may even use different thresholds, depending on the domains to
> validate.  This become then an extension to the white/black list, where a
> blacklist is implemented as a default threshold of X and a infinite threshold
> for the domains blacklisted, and where a whitelist is implemented as a default
> infinite threshold and a threshold of X for the domains whitelisted.
> 
> 
> [1] Or a certificate if my other proposal is accepted.
> 

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

iEYEARECAAYFAk6doAoACgkQ9RoMZyVa61eFWQCgpPz2uKruKPkQlG0X9vMrppm8
ZMwAoKZ3VL1T7UtCEoHrrIKujEmxs4Ek
=mVG9
-----END PGP SIGNATURE-----