[asterisk-dev] AstriDevCon Recap - IAX2 RENEW for encryption

[Russell Bryant]

Steve Kann wrote:
> 1) At the IAX2 transport protocol level, like any other frame, RENEW 
> would be acknowledged by either an explicit or implicit ACK -- no need 
> for much discussion there.

Fair enough.  So, there doesn't need to be any extra text in the RFC 
about this.

> 2) Semantically, though, the receiver of the RENEW should probably reply 
> with an ACCEPT.  This is mainly because we also have discussed using 
> RENEW as a means of renegotiating formats (incl codecs and a better 
> mechanism for defining these).  The ACCEPT would be necessary for that 
> negotiation process.

That's true, if RENEW was also used for renegotiating formats, it would 
require an ACCEPT.  I propose that we proceed using RENEW only for 
things that MUST be accepted, and thus do not require an ACCEPT.  When 
we get to planning the specifics for format renegotiation, we can just 
pick a different frame type.

If RENEW is a bad name here, I'm open to suggestions for changes.  I 
don't really care what it is.  It may be, since it sort of implies 
behavior similar to that of NEW, which in the case of this discussion, 
it is not.

> 3) I'm not sure when we'd actually want to switch encryption keys, in 
> each direction.   We would need to consider that there is some latency 
> between when we send packets, and when they're received, and the latency 
> is often going to be larger than the inter-packet interval.  
> RENEW+ACCEPT probably handles this properly, but not in a backwards 
> compatible way:

Note that I don't think maintaining backwards compatibility is a 
requirement in this case.  There are so few people trying to use IAX2 
encryption at this point since it has not been well documented, that it 
is more important that we get it right than we maintain compatibility 
with the original implementation.

>    a) When a sender sends a RENEW packet with a new ENCKEY IE, it shall 
> be encrypted with the old key.  Subsequent packets shall be encrypted 
> with the new encryption key.
>    b) When the recipeient of a RENEW packet with an ENCKEY IE receives 
> that key, it shall expect subsequent packets from that sender to be 
> encrypted with the new key.  It also shall send an ACCEPT packet, 
> encoded with the old ENCKEY, and then send subsequent packets encrypted 
> with the new encryption key.
>    c) When the sender of a RENEW packet receives an ACCEPT packet from 
> it's peer, it shall expect all subsequent packets to be encrypted with 
> the new key.
> 
> I think this covers cases except for these:
> 
>    1) If packets are delivered out-of-order, they may not be able to be 
> properly decrypted.  (but, can we even tell that they're out-of-order, 
> and reorder them without being able to decrypt them?).

Let's just say in the worst case, the RENEW gets lost in transit.  Since 
it is a full frame, it will get retransmitted.  There will be a short 
period where frames can not be properly decrypted, but this would not be 
the normal case.  I'm not sure if there is a way to solve this possibility.

>    2) If you send a RENEW to a peer who hasn't yet implemented this, it 
> will send back and INVAL;  But, if you're using the new key after that, 
> it will also no longer be able to decrypt.

I say that we just don't worry about backwards compatibility.

>    3) We probably want to define which end of the call is responsible 
> for, and allowed to send RENEW with ENCKEY -- and, if both sides are 
> allowed, there may be "stare" race conditions we need to account for, 
> where both sides send RENEW at the same time?

I'm sorry for not making this clear the first time, but I propose that 
when a peer sends a RENEW, they immediately use the new key for 
encrypting their transmissions.  A peer will not change the key used to 
decrypt frames until it receives a RENEW with the ENCKEY element.  If 
the RENEW arrives out of order, then some media frames will not be able 
to be decrypted, but I think this may be an edge case we can't really 
account for.  Besides, hopefully PLC will be available and make it so 
you don't even notice that it happens.

-- 
Russell Bryant
Software Engineer
Digium, Inc.