[asterisk-dev] SRTP key lifetime bug

[Alex Villací­s Lasso]

El 05/09/13 03:57, Olle E. Johansson escribió:
> https://issues.asterisk.org/jira/browse/ASTERISK-17899
>
> I've done a lot of research about this and find a worrysome amount of pages where people explain that this is a bug in Asterisk and a few different patches floating around. That's not a good situation. It does break communication in a customer platform 
> I'm working with.
>
> The story is this:
>
> In SDES we send master crypto keys in clear text (don't laugh, please). The keys can have attributes for the lifetime - number of packets we can use this key for - and a master key index. In asterisk, if someone sends us this attribute which quite a lot 
> of servers and phones seems to do, we break the call and do not accept - even if the lifetime is 2^31 packets which is quite a long call, spanning decades, with a rate of 50 packets per second.
>
> We do not have to answer with any attributes on our key. The key attributes are just declarative, not an offer/answer item.
>
> I consider this a bug that we need to fix in all release versions. There's a correct way of solving it - using packet counters and forcing a re-invite and a key reset beforehand or a quick and dirty where we accept all lifetimes above a treshold, like 
> 2^20 and assume no calls will be that long or that if they are, the other end will start a key reset.
>
> My questions to the esteemed reader of this list:
> - can we agree that the current behaviour is a bug?
> - which solution should we code for?
>
If I understand correctly, the SRTP lifetime is the same issue covered in https://issues.asterisk.org/jira/browse/ASTERISK-20233 , and that bug was closed as "Not A Bug", since this was a "feature request" and therefore better discussed in the mailing list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130905/e77bfbc3/attachment.htm>