RE: Additional use cases? (Re: Plan for moving forward)

["Dan Wing" <dwing@xxxxxxxxx>]

> Interesting ...  I wondered about the reasoning of multiple 
> serverhellos.  Is the argument that multiple clienthellos are alright 
> since that amounts to lower overhead than multiple 
> serverhellos (if the expected response is HelloVerifyRequest, 
> then the overhead might be similar)? 

The client instantiates its state prior to sending a ClientHello,
and the server instantiates its state when it receives a ClientHello.

If a client were to send a ClientHello in an Invite, and the call
forked, and the client received a bunch of ServerHellos, it wouldn't
be doing DTLS anymore because the client would instantate new state 
for each of those ServerHellos that arrive (and complete the DTLS 
handshake with each of those).

> But that seems to optimize for the forking use case and 
> ignores other use cases.

That = the existing DTLS-SRTP specifications?

I don't see how they are optimized for forking and de-optimized
for the non-forking case.  Do you mean it's much too expensive
for the originator (who may have to deal with a bunch of forked
endpoints) than you'd like?  Or do you mean it's not efficient
over-the-wire (bandwidth?).

> Why is the ClientHello going out-of-band a problem?

In addition to the problem of forking causing multiple ServerHellos,
you'd have to prevent your DTLS implementation from sending its
ClientHello over the wire, grab its data and stick it into a
SIP header or into the SDP or wherever you were thinking it would
go.  Not hard, but not beautiful, either.

> As to why to do this: it seems to allow the use case I was 
> talking about

The use case where someone dials a number and proves their identity
using a PIN?  One thing you mentioned at the bottom of your first
email http://www.imc.org/ietf-rtpsec/mail-archive/msg00751.html is
that "priority call placement use case is similar"; however, it
isn't -- IEPREP isn't requiring someone to connect to a remote
gateway, prove their identity to that remote gateway, and someone
pull that authentication and authorization 'back' into the 
originating network.  The trouble with such an approach is how
you'd get the access to perform that connection to that remote
resource in order to initiate that authorization in the first
place -- the phone system is overloaded and the more components
of it you involve the more likely you'll find overload.

> and Dan was making a case for it too earlier 
> today.

In my email related to directionality?  That was only an idea
to avoid the SDP for directionality.

-d

 
> regards,
> Lakshminath
> 
> On 6/12/2007 12:46 PM, Eric Rescorla wrote:
> > At Tue, 12 Jun 2007 12:39:47 -0700,
> > Lakshminath Dondeti wrote:
> >> Right.  So, why not do it?
> > 
> > Because it involves a number of changes in the DTLS model (having
> > one message happen out of band, having one clienthello elicit
> > multiple serverhellos, etc.) and nobody has described a compelling
> > reason to do this.
> > 
> > -Ekr
> >