[VOIPSEC] SIP B2BUA and Digest Authentication using

[Randell Jesup]

Simon Horne <s.horne at packetizer.com> writes:
>>         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.

        From a security-person's perspective, that makes sense, and from
the perspective of a user who's intent is "I want to make a secure call".
They might wait seconds to get the security they're asking for.

        From the perspective of a general user, if it makes a normal
call slow or otherwise painful to set up, they won't like it/use it.
And when it does come time when a secure call might be wanted, they
will have either: 

1. set up/answered the call already or
2. not even remember how to setup a secure call.

Not to mention that in that situation, enabling security for just those
calls leaks important information to an eavesdropper, even if they can't
listen into the call.  A MiTM could also block the encrypted calls and
let others go through, and the user might just think that encryption never
works or they didn't figure out how to enable it.

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

        Yes, they might, if the market demands it.  Right now, with no
standards worth speaking of (or more to the point too many, with few of
them actually in use by more than very small isolated groups), there's no
win for hardware manufacturers to do so.

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

        Right, my point was really more targeted at the end-user psychology
aspect.  It's easy to design a system that works (both technically and
usage-wise) for cases where security is a per-call, actively engaged thing
that's part of the user's thinking.  It's much harder for it to be a
background, automatically invoked, ubiquitous, bothers the user only when
there's an issue sort of thing.

        People get worried about their privacy when stuff goes over the
net.  And that worry goes up exponentially once video is involved.  

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)