[asterisk-dev] [Code Review] IAX2 retransmit with encryption enabled fix

[Tim Panton]

On 12 Mar 2009, at 12:21, Russell Bryant wrote:

>
> On Mar 11, 2009, at 4:07 PM, Tim Panton wrote:
>
>> I don't understand the cause of the problem.
>> Why does the iseq have to be updated?
>
> I think strictly speaking, it does not _have_ to be updated.  The
> problem being fixed is that the existing code tried to update it, but
> the way it did it was totally broken, as it was writing it into a
> frame that was already encrypted.  So, as a result, retransmissions
> within an encrypted call were totally broken.
>
>> I realize that _strictly_ the iseq indicates all the packets that we
>> have seen to date,
>> but since it is only treated as an ack why would it be bad if re-
>> transmit just re-sent the
>> original packet unaltered (except for the retransmit bit flag -
>> which isn't in the encrypted
>> part of the packet) ?
>
>
> I would agree that just removing the line of code that attempted to
> update the iseqno would have fixed the problem.  However, would you
> agree that it is ideal that we send an updated iseqno when we do a
> retransmission?
>
> That way, the other side doesn't bother retransmitting frames that we
> have already received and processed.

I'm not convinced. In my book a retry ideally should be identical
to the original. (apart from the retry flag) In SNMP they are identical.

There is also the crypto angle - as pointed out by philipp at vklitzing.com
in  an off-list email.
A retry with a few different bits in known locations  within the  
encrypted part is a gift to the
cryptanalyst - especially since we are kind enough to flag it in the
unencrypted part as a retry.

So if you are going to change the encrypted portion at all, you need to
be sure to use new random padding.

I'm tempted to say that if it's an encrypted frame we are retrying, skip
the iseq update and fire it off as-is.

Tim.


Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2419 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20090312/668d2d7c/attachment.bin