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

[David Vossel]

----- "Tim Panton" <thp at westhawk.co.uk> wrote:

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


I'd like to keep updating the iseq for encrypted packets.  Its more efficient and I'm planning on doing some work to improve the random padding.  It turns out that the random padding isn't all that random to begin with. I already have plans to improve this, and can make sure it is updated for every encrypted retransmission.  Can we agree that this is an acceptable solution?

~David