[VOIPSEC] SIP B2BUA and Digest Authentication using

[Simon Horne]

At 08:41 PM 8/11/2005, Randell Jesup wrote:
>Simon Horne <s.horne at packetizer.com> writes:
>
> >At 11:34 AM 8/11/2005, Randell Jesup wrote:
> >>         1 second (on what?) is good - except when users expect way less
> >>than 1 second delays.  From what I've seen, 200-300ms would seem to be
> >>the upper bound for a hardphone given user's expectiations.  It's a lot
> >>better than 2-3 seconds, of course.
> >
> >The setup time is for full X.509 Authentication and D-H session key
> >negotiation. Unlike standard TLSv1 which requires several messages to
> >obtain SA (security association), we have compressed these into 2 messages,
> >1 in each direction, greatly reducing setup time.
> >
> >The authentication/encryption setup time is very dependent on the hardware,
> >4-500ms is achievable with P4 3.2Ghz boxes . The exchange is done before
> >either party receives a ring notification, basically in the "connecting"
> >space. People have come to expect 1 to 2 sec from dialing a number to
> >receiving information that the remote phone is ringing. This is of course
> >quite different to answering the call where near instant connection is
> >expected.
>
>         Having it be pre-ring is a very good thing; I think the Mikey stuff
>last time I looked (at least the DH version) was post-pickup.  400-500ms
>of initial call setup time isn't too bad.  People do expect fairly short
>time-to-rings on POTS lines, and an additional 400-500ms may push total
>time out to the point of being more noticable/annoying.

To be honest I have not fully tested to get qualifiable values however I 
don't see 4-500ms delay before the remote rings, being too much of a trade 
off for the benefits it provides.

>         My biggest worry is that 400-500ms is on a P4 3.2GHz.  If you're
>calling to/from a hardphone with a (say) 200MHz ARM (or less), what sort of
>delay might be expected?  The metric for whether using this encryption
>(especially if used all the time) is what the worst-case and common-case
>delays are.

Yes the setup time would be large on low CPU hardphones however as the 
algorithms are pretty much standard, manufacturers can invest in freely 
available low end hardware crypto chip much like currently deployed in 
small VPN boxes. This should give better performance then even the software 
solution on the PC.


>         Obviously encryption is far better when used always (or at least
>anytime both sides support it).  Users having to enable it in a call or on
>a per-call basis just doesn't cut it from a security aspect, and using it
>all or virtually all the time avoids some large pieces of traffic analysis.
>It also makes a failure to encrypt due to bid-down all the more apparent.

The point is you have a choice, you can use it in a mixed environment with 
other standard H.323 phones or you can restrict the policy to only accept 
authenticated callers however still have the ability to call out to legacy 
endpoints, gateways etc. This is just a security policy in the software.

Simon


Simon Horne
Director
Packetizer Labs
www.packetizer.com/labs