<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 5, 2013 at 2:46 PM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>5 sep 2013 kl. 21:34 skrev Matthew Jordan <<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>>:</div>
<div class="im"><br><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" target="_blank">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>So, I'll start with "how should this behave" and move on from there.</div><div><br></div><div>First, we should never ignore a lifetime request. Either we support it, or we don't. </div>
</div></div></div></blockquote></div>You always do, but you may not signal it.</div><div><div class="im"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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><br></div><div>(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><br></div><div>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><br></div><div>If we do implement key lifetimes, I would assume we would behave in the following way:</div><div><br></div><div>1. When we receive a key lifetime, we set limits on the number of packets we'll receive. </div>
</div></div></div></blockquote></div>SEND! We receive a key and the lifetime for that key when we encrypt with it and send to the other side.</div><div><div class="im"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>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></div>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.<div class="im">
<br></div></div></div></blockquote><div><br></div><div style>Blech, you're right. Reverse my positions there.</div><div style><br></div><div style>I'd be fine if we never sent a key lifetime, and was merely tolerant of it being sent to us.</div>
<div style><br></div><div style>Matt</div><div style><br></div></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>