[asterisk-dev] SRTP and forcing encrypted calls

[Terry Wilson]

On Feb 11, 2010, at 4:01 PM, Olle E. Johansson wrote:
> 11 feb 2010 kl. 22.49 skrev Kevin P. Fleming:
> 
>> Olle E. Johansson wrote:
>> 
>>> I think that the CHANNEL() dialplan function is not the answer. Let's not overload it, let's create a new function and make sure it's channel independent.
>> 
>> That's exactly what CHANNEL is for; a channel-independent interface to
>> (potentially) channel-dependent information and settings. It's only a
>> dispatcher, it has no particular goal or design objectives, other than
>> to be easy to understand and use. It was designed to be "overloaded", in
>> the C++/C#/Java/etc. sense of that word.
>> 
> I fully understand that. But there's also a product design issue here. I think that we have to consider security a separate property from other channel settings  - it will make it easier to communicate, teach and write documentation if there's a specific set of functions, apps and settings that has a name prefix that shows that they belong together and all are used to manage the security properties of sessions. I don't want to say "there are a few settings you can find amongst all settings in CHANNEL, and a few options here and a few chan_sip settings and by the way, a few very different settings in iax.conf."
> 
> This is a very, very important addition to Asterisk and we need to make it very obvious how to manage security properties of the PBX. I don't want to hide it in existing functions and settings. i don't want options in asterisk.conf - I want a new file called PBXSECURITY.CONF or something even more obvious where you control the core security options, your PBX security profile and certificate store.
> 
> I know we can very well have it in a section called [encrypted_media_sessions] in asterisk.conf, but that won't give the effect I want. We have enhanced the security in many areas of Asterisk - manager, channel drivers and coding. Let's tie it all together and communicate, so that people start using it.
> 
> From the Asterisk product marketing dept in a hotel room in Oslo :-)

That's all understandable and I'm sure no one is suggesting that we shove everything into asterisk.conf, but a combination of dialplan and channel-specific config files is the only thing that really makes since to me for this. I think the best we can do is make channel-specific configuration as uniform as possible and encourage people to use the dialplan for as much as possible. There is no way that SRTP is going to wait on a completely new security framework for Asterisk--complete with pbxsecurity.conf, etc. That would definitely be outside the scope of what I'm trying to accomplish. I've personally rescued this code from bit rot 2 or 3 times now. It is painful and has literally wasted months of my time. I'm not doing it again. :-p

If we could somehow move this back to specific suggestions of what the design should look like as opposed to critiques of process, we might move further towards getting this pushed out. Are there specific things about the config file options or dialplan functions that anyone has issues with? We've got the CHANNEL() vs SOME_ENCRYPT_FUNCTION() thing, which seems fairly minor. Then there is the caller-id specific requirements which don't really affect the overall design at all. Anything else? Does anyone other than me, Kevin, and Olle have any more input?

Terry