Re: [VIPR] An alternative to the VIPR ticket

[Michael Procter <[e-mail]>]

On 12 October 2011 23:53, Marc Petit-Huguenin <[e-mail]> wrote:
> During the last conference call, this proposal was criticized as been a
> significant change from the way SIP is processing TLS requests.  My research
> shows that it is not the case.
[...]
> So in conclusion, my proposal does not change what a normal SIP stack is doing,
> because the specification does not say what a SIP stack should do with a client
> certificate.

What you describe is that the server side of the connection will need
to validate a client certificate whatever happens, and changing the
ticket to a certificate does not substantively change the validation
process.  It does force the ticket validation to the edge of your
network though, which having the ticket in a header field doesn't.
Since ticket validation is a new process introduced with ViPR, this
may be a reasonable change.

However, what is overlooked in this analysis is that the client side
must present a different certificate on a per-call basis.  Most
implementations that I have seen tend to have a fairly statically
configured certificate (or several, but not lots) that is valid for
the duration of the process/between scheduled maintenance.  Having the
certificate change on a per-call basis is a change for these
implementations.  How significant a change depends on their
architecture, but it is a change nonetheless.

Why does this matter?  With the ViPR ticket in a header field, I can
route ViPR traffic out in much the same way as I route other SIP
traffic.  Granted it has an additional header, but that doesn't
substantively change the job my egress points perform.  With a ViPR
certificate instead of a ticket, my egress points need to be
sufficiently ViPR-aware to know to use a dynamically selected
certificate, and how to get hold of that certificate.  Not
insurmountable problems, but ones that are introduced by changing to a
certificate over a simple header field.

There may be other problems (Jon seemed to jump on the change quite
fast so he may have more reasons), but this is the one that struck me.
 I think this change warrants wider discussion before deciding whether
to adopt or not.

Regards,

Michael