[asterisk-dev] [Code Review] 4419: SDES-SRTP: Handle SRTP keys negotiated with key lifetime/MKI (oej branch lingon-srtp-key-lifetime-1.8) - Asterisk 11

[Matt Jordan]

> On Feb. 18, 2015, 1:57 p.m., Mark Michelson wrote:
> > /branches/11/channels/sip/sdp_crypto.c, line 290
> > <https://reviewboard.asterisk.org/r/4419/diff/1/?file=71388#file71388line290>
> >
> >     Would
> >     
> >     if (!strncmp(lifetime, "2^", 2))
> >     
> >     accomplish the same thing here?

It should - fixed.


> On Feb. 18, 2015, 1:57 p.m., Mark Michelson wrote:
> > /branches/11/channels/sip/sdp_crypto.c, line 304
> > <https://reviewboard.asterisk.org/r/4419/diff/1/?file=71388#file71388line304>
> >
> >     Since we're only concerned about an integer value here, would the following work:
> >     
> >     sdes_lifetime = 2UL << n_lifetime;
> >     
> >     ?
> >     
> >     pow() probably has a built-in optimization for raising 2 to integer powers, but the fact that it returns a double means that there is still the issue of type conversion when using it.
> >     
> >     Also I have a question here: since n_lifetime can be as large as 48, does this have the possibility of overflow on 32-bit architectures? The double returned by pow() can hold the value just fine, but when casting to unsigned long, what happens?
> 
> rmudgett wrote:
>     I think that would be:
>     sdes_lifetime = 1UL << n_lifetime;
>     :)
> 
> Mark Michelson wrote:
>     Ah yes, my mistake.
> 
> Matt Jordan wrote:
>     Unfortunately, the default recommended max lifetime for SRTP is 2^48, which means we probably should just use a double for storage and comparisons.
>     
>     Tha also means using pow, and not using a bit shift.

As far as the inevitable rounding errors involved with floating point numbers: in general, all we care is that the result is less than an already very large number. Since we aren't comparing for equality, all we really care is that the result of pow(2, n_lifetime) is within some reasonable bounds of the max lifetime we are willing to accept, 18000000. Since 2^20 < 1800000 < 2^21 - even if those numbers are represented by floating point numbers - there's very little risk of the floating point comparisons having an issue.


> On Feb. 18, 2015, 1:57 p.m., Mark Michelson wrote:
> > /branches/11/channels/sip/sdp_crypto.c, lines 306-311
> > <https://reviewboard.asterisk.org/r/4419/diff/1/?file=71388#file71388line306>
> >
> >     Should the decimal lifetime reading also ensure that the value is not greater than 2^48?

To avoid overflows and other weird number boundaries on a 32-bit system, I'll probably have to use log, but sure, I guess.

This is one of those things that is needed in theory, but pointless in practice since we only care that the lifetime is greater than 1800000.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4419/#review14486
-----------------------------------------------------------


On Feb. 13, 2015, 9:26 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4419/
> -----------------------------------------------------------
> 
> (Updated Feb. 13, 2015, 9:26 p.m.)
> 
> 
> Review request for Asterisk Developers and Olle E Johansson.
> 
> 
> Bugs: ASTERISK-17721, ASTERISK-17899 and ASTERISK-22748
>     https://issues.asterisk.org/jira/browse/ASTERISK-17721
>     https://issues.asterisk.org/jira/browse/ASTERISK-17899
>     https://issues.asterisk.org/jira/browse/ASTERISK-22748
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Note that this patch is a forward port of oej's lingon-srtp-key-lifetime-1.8 branch, with a few small modifications to reduce block indentation and a few improvements made to surrounding existing code.
> 
> To quote Olle from ASTERISK-17721:
> 
> {quote}
> The Lingon branch now handle lifetime and MKI parameters.
> 
> We only accept lifetimes up to max for the crypto and higher than 10 hours for packetization of 20 ms (50 pps).
> 
> We only handle MKI with index 1.
> 
> We do not really bother with counting packets and reinviting at end of lifetime, so the min of 10 hours kind of takes care of most calls. If there are longer ones, we rely on the other side for re-invites.
> 
> It's still not perfect, but I personally think this is an improvement. A configuration option for minimum lifetime accepted could be added.
> {quote}
> 
> I personally don't think the minimum lifetime option is needed, as in practice, every instance of an SDP offer for SDES-SRTP with lifetime I've seen offers a lifetime of 2^32 - but it could be added in the future if necessary.
> 
> Note that since the sdp_crypto code was moved to the core in 12+, a separate review (r4418) has been made for the Asterisk 13 variant. It is essentially identical to this review.
> 
> 
> Diffs
> -----
> 
>   /branches/11/channels/sip/sdp_crypto.c 431750 
> 
> Diff: https://reviewboard.asterisk.org/r/4419/diff/
> 
> 
> Testing
> -------
> 
> Tests were added for chan_sip and updated for chan_pjsip - see https://reviewboard.asterisk.org/r/4420 . This includes both nominal and off-nominal offers negotiating SDES-SRTP.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150220/6b071c6a/attachment-0001.html>