[asterisk-dev] SRTP key lifetime bug

[Matthew Jordan]

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

2. If we send a key lifetime, we also enable period transmits that refresh
the master key. Those periodic retransmits should be based on the key
lifetime, and set up to ensure that we generate a new key before the old
key expires. This will probably require some tweaking in the rtp_engine and
res_srtp, as how keys are associated with an RTP stream is a bit tricky
(particularly since we use wild card policies for remote keys and stream
specific policies for local keys). We could rely on RFC 4028 support;
however, there's nothing that says that you must have SIP session timer
support in order to support re-freshing the master key. I'd prefer the two
to be independent myself.

Now, is this a bug?

I'll quote myself here:

{quote}

This is not a bug but a feature request.


Asterisk at this time does not support lifetime for cryptographic keys
(which is the part after the | in the key). As such, this issue will be
closed out unless a patch is provided which actually adds support in
Asterisk for lifetime.
{quote}

And now I shall sort of disagree with myself.

Most phones I've run into support disabling lifetime of keys (SNOMs, in
particular). There are some devices out there, however, that do not and
this does become a compatibility issue for those devices. We've certainly
done heavy lifting in the SRTP support for compatibility problems in the
past (most notably when certain devices would changes the keys on
re-INVITEs, regardless of having a lifetime parameter in the negotiation).
I'd lay it out this way:

* Any solution should be backwards compatible with Asterisk itself, such
that Asterisk with lifetime support can send an INVITE request with an SDP
containing SDES-SRTP keys to another Asterisk instance without that support
and have the call work.

* Any solution should actually -support- key lifetimes.

* Tests verifying lifetime support would be needed to ensure that it's
actually functional and doesn't introduce any regressions. Since most
endpoints don't send lifetimes that are realistic, the only way you can
verify that Asterisk will actually kill SRTP packets if a lifetime is
violated or re-fresh the key appropriately is if the lifetime is set to
something low.

If we hit all three of those points, I'm good with it going into 1.8 and 11.

[1] https://issues.asterisk.org/jira/browse/ASTERISK-17899

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/c009d038/attachment-0001.htm>