[asterisk-dev] SRTP key lifetime bug

[Matthew Jordan]

On Thu, Sep 5, 2013 at 2:46 PM, Olle E. Johansson <oej at edvina.net> wrote:

>
> 5 sep 2013 kl. 21:34 skrev Matthew Jordan <mjordan at digium.com>:
>
>
> On Thu, Sep 5, 2013 at 12:28 PM, James Cloos <cloos at jhcloos.com> wrote:
>
>> >>>>> "OEJ" == Olle E Johansson <oej at edvina.net> writes:
>>
>> OEJ> even if the lifetime is 2^31 packets which is quite a long call,
>> OEJ> spanning decades, with a rate of 50 packets per second.
>>
>> Side note:  2^31 packets at 50 packets/s == 497.1 days.
>>
>> OEJ> We do not have to answer with any attributes on our key. The key
>> OEJ> attributes are just declarative, not an offer/answer item.
>>
>> Given that,
>>
>> OEJ> assume no calls will be that long or that if they are, the other end
>> OEJ> will start a key reset.
>>
>> and the possibility of assuming that the other side will start a reset
>> when the advisory timeout which they specified occurs, it seems like it
>> would be enough just to accept the nego w/o bothering to confirm that
>> the other side holds to their advised key timeout, yes?
>>
>> Ie, do nothing more than a verbose() or debug() call with the timeout
>> info and proceed as though it were not speficied?
>>
>> OTOH, for performance and quality reasons, rejecting nego when the
>> timeout is less than a few seconds seems useful.  For some definition
>> of a few.
>>
>
> So, I'll start with "how should this behave" and move on from there.
>
> First, we should never ignore a lifetime request. Either we support it, or
> we don't.
>
> You always do, but you may not signal it.
>
> Yes, most endpoints send a ludicrously high lifetime request - which by
> itself should inform us all about how worthwhile this particular feature is
> - but if it sends us a key lifetime, we need to honor it. We could go down
> the road of parsing the lifetime and, if it is suitably high, lie to the UA
> and say that we do support it; if it is suitably low, respond with a 488.
> However, that road feels fraught with peril. What is the magic level that
> Asterisk allows? Do we make that configurable as well?
>
> (And let's face it, someone will run a SIP device connected to Asterisk
> for 480 some odd days. Then there's a bug report of no audio.)
>
> To date, all patches [1] have been of the 'ignore' variety; hence why they
> haven't received a very high priority. It doesn't feel like the correct
> solution.
>
> If we do implement key lifetimes, I would assume we would behave in the
> following way:
>
> 1. When we receive a key lifetime, we set limits on the number of packets
> we'll receive.
>
> SEND! We receive a key and the lifetime for that key when we encrypt with
> it and send to the other side.
>
> After we hit that limit - for both SRTP and SRTCP - we just start dropping
> the packets on the floor, preferably with a nice WARNING. If we get a
> re-INVITE that refreshes the master key, we reset the counter. We do not
> issue a re-INVITE ourselves.
>
> THis is for the lifetime we send - which we might not do.
> When we hit the other side's lifetime we should stop sending. But before
> that, we should send a re-INVITE to hint that we need a new key. That part
> doesn't seem well documented.
>
>
Blech, you're right. Reverse my positions there.

I'd be fine if we never sent a key lifetime, and was merely tolerant of it
being sent to us.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130905/3d8f7e69/attachment-0001.htm>