[AVT] Re: RFC3711 non-zero key derivation rate and the logic to update key derivation

[Mats Näslund <mats.naslund at ericsson.com>]

Hi Guoqiang,

This is by far the most common "FAQ" for SRTP ;-)

You are right, due e.g. to packet re-oredering it may not suffice
to only perform derivation when "index mod r equals zero". This is
informative text that describes the *principle*, but not the
actual way to implement it.

The normative text (later) is:

"Key derivation SHALL be defined as follows
 ...
 The n-bit SRTP key (or salt) for this packet SHALL
 then be derived ...  as follows:"

Please notice the text "for *this* packet" which is intended
to indicate that this is potentially a per-packet issue.

Best,

/Mats


Guoqiang Lu wrote:
> I have a few questions about the key derivation as specified in RFC 3711.
>
> 1. What is the "r" in the sentence "...when r > 0, a key derivation is 
> performed whenever index mod r equals zero ... "? Is it the one later 
> defined:  r = index DIV key_derivation_rate?
>
> 2. The logic for performing a new key derivation is only mentioned in 
> the RFC 3711 as " .. a key derivation is performed whenever index mod r 
> equals zero ". In reality, more complicated logic is probably needed 
> considering the following scenarios:
>
> Assume: Key_derivation_rate = 4, ROC = 0
> Scenario 1:
> For pakcet seq = 16, index = 16, r = 16 DIV 4 = 4, so 16 mod 4 = 0 a new 
> key is derived on the receiver side. But then packet seq = 14 arrived, r 
> = 14 DIV 4 = 3, but 14 mod 3 is not 0 so no new key derivation is 
> performed. But we can't use the key derived for seq = 16, the old key 
> should be used. So we need more complicated logic than the " index mod r 
> = = 0 " to determine whether to use the old key for seq = 14 
>
> Scenario 2: Same as above but assume packet 16 is lost and never reached 
> the receiver, then for packet 17, r = 17 DIV 4 = 4, 17 mod 4 is not zero 
> and no new key is derived for packet 17 but on the sender side, packet 
> 17 uses the new key.
>
> Am I understanding it correctly?
>
> Thanks!
>
> Regards,
>
> Guoqiang



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt