[asterisk-dev] SRTP configuration and behavior in Asterisk18

[Terry Wilson]

> IMO, the current situation (trunk) includes these short-comings wrt SRTP
> (not necessarily in order of importance):
> a - Asterisk can only offer one crypto-suite in outgoing INVITEs,
> b - The only crypto-suite Asterisk will offer is "AES_CM_128_HMAC_SHA1_80",

This is actually something I was planning on addressing this week sometime. I'll be sure to review your patches.

> c - Asterisk will accept the first crypto-suite offered in incoming INVITEs --
>      no way to accept alternate (2nd/3rd) offered crypto-suite if preferred,

I agree this is something that would be nice to have. For me, it isn't very high priority, so I hope to get patches. :-)

> d - Asterisk has no means to specify use of the NULL cipher for SRTP stream,

This wouldn't be very hard to add. It is more of a priority issue as well.

> e - Asterisk does not have any way to use different crypto suites or keys
>      for audio/video/text streams in the same offer/answer,

True, but adding this would be pretty difficult, I think. Is it really worthwhile?

> f - Asterisk does not understand lifetime or MKI:length parameter,
>      and rejects INVITE if either is present,

This is something I noticed when merging the patch as well. I didn't think we rejected the INVITE, but just ignored the parameter, though. That's what the code looks like anyway. Dealing with timeouts is always a bit of a pain, but this definitely needs to be added at some point.

> I have an opened this issue[1] upon which I have spent some effort.
> So far my efforts/patches only attempt to address letter b above.
> I have been encouraged to "keep it simple, seriously" and only add
>  new  values for the encryption=... param.
> But upon reading (again) from a relevant RFC document[2], and
>  spending some non-negligable time in the code, I think a more
>  intrusive correction is called for.

The patch that was merged in had been sitting around for over 5 years. Trying to keep it updated was a nightmare. We'd love to have someone who was interested in the code helping out with it. I'll take a look at your current patches.

> Since, in the offer/answer model, the crypto-suite is a negotiated
>  parameter, much like codec is, I suggest Asterisk should have a
>  more codec-like behavior in both configuration and negotiation of
>  the SRTP crypto settings.  (allow_encryption|deny_encryption perhaps?)

The problem is that we also try to make the encryption settings configurable in a protocol-agnostic kind of way across both IAX2 and SIP via the dialplan. We'll have to be careful about keeping that in mind when we make changes. This should be doable, though.

> I also welcome any ideas about correcting any other issues related to
> Asterisk18 SRTP capability.

Any changes that aren't actual bug fixes would go into trunk and not 1.8. We'd have to take each change on a case-by-case basis. Missing functionality *can* be a bug, but doesn't always rise to that level. Certainly restructuring into an allow/deny type setup would be considered more of a new feature rather than a bug fix.

Thanks for the contributions. I'll try to take a look at them very soon.