<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>5 sep 2013 kl. 21:34 skrev Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 5, 2013 at 12:28 PM, James Cloos <span dir="ltr"><<a href="mailto:cloos@jhcloos.com" target="_blank">cloos@jhcloos.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">>>>>> "OEJ" == Olle E Johansson <<a href="mailto:oej@edvina.net">oej@edvina.net</a>> writes:<br>
<br>
OEJ> even if the lifetime is 2^31 packets which is quite a long call,<br>
OEJ> spanning decades, with a rate of 50 packets per second.<br>
<br>
Side note: 2^31 packets at 50 packets/s == 497.1 days.<br>
<br>
OEJ> We do not have to answer with any attributes on our key. The key<br>
OEJ> attributes are just declarative, not an offer/answer item.<br>
<br>
Given that,<br>
<br>
OEJ> assume no calls will be that long or that if they are, the other end<br>
OEJ> will start a key reset.<br>
<br>
and the possibility of assuming that the other side will start a reset<br>
when the advisory timeout which they specified occurs, it seems like it<br>
would be enough just to accept the nego w/o bothering to confirm that<br>
the other side holds to their advised key timeout, yes?<br>
<br>
Ie, do nothing more than a verbose() or debug() call with the timeout<br>
info and proceed as though it were not speficied?<br>
<br>
OTOH, for performance and quality reasons, rejecting nego when the<br>
timeout is less than a few seconds seems useful. For some definition<br>
of a few.<br></blockquote><div><br></div><div style="">So, I'll start with "how should this behave" and move on from there.</div><div style=""><br></div><div style="">First, we should never ignore a lifetime request. Either we support it, or we don't. </div></div></div></div></blockquote>You always do, but you may not signal it.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">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?</div>
<div style=""><br></div><div style="">(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.)</div><div style=""><br></div><div style="">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.</div>
<div style=""><br></div><div style="">If we do implement key lifetimes, I would assume we would behave in the following way:</div><div style=""><br></div><div style="">1. When we receive a key lifetime, we set limits on the number of packets we'll receive. </div></div></div></div></blockquote>SEND! We receive a key and the lifetime for that key when we encrypt with it and send to the other side.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">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.</div></div></div></div></blockquote>THis is for the lifetime we send - which we might not do. </div><div>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.<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div style=""><br></div><div style="">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.</div>
<div style=""><br></div><div style="">Now, is this a bug?</div><div style=""><br></div><div style="">I'll quote myself here:</div><div><br></div><div style="">{quote}</div><div style="margin: 0px; padding: 0px; font-family: Arial, FreeSans, Helvetica, sans-serif; font-size: 13px; line-height: 17px; ">
This is not a bug but a feature request.</div><div style="margin: 0px; padding: 0px; font-family: Arial, FreeSans, Helvetica, sans-serif; font-size: 13px; line-height: 17px; "><br></div><div style=""><span style="font-family: Arial, FreeSans, Helvetica, sans-serif; font-size: 13px; line-height: 17px; ">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.</span></div>
<div style="">{quote} </div></div><div><br></div><div style="">And now I shall sort of disagree with myself.</div><div style=""><br></div><div style="">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:</div>
<div style=""><br></div><div style="">* 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.</div></div></div></blockquote>We don't have to send. If we don't the default applies.<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div style=""><br></div><div style="">* Any solution should actually -support- key lifetimes.</div></div></div></blockquote>Yes.<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div style=""><br></div><div style="">* 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.</div></div></div></blockquote>Yes.<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div style=""><br></div><div style="">If we hit all three of those points, I'm good with it going into 1.8 and 11.</div></div></div></blockquote>Ok, then we agree. </div><div>Now we need coders and funding for them.</div><div><br></div><div>/O<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div style=""><br></div><div style="">[1] <a href="https://issues.asterisk.org/jira/browse/ASTERISK-17899">https://issues.asterisk.org/jira/browse/ASTERISK-17899</a></div>
<div style=""><br></div><div style="">Matt</div><div style=""><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com/" target="_blank">http://digium.com</a> & <a href="http://asterisk.org/" target="_blank">http://asterisk.org</a></div></div>
</div></div>
--<br>_____________________________________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>---</div><div>* Olle E Johansson - <a href="mailto:oej@edvina.net">oej@edvina.net</a></div><div>* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden</div><div><br class="webkit-block-placeholder"></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>