I believe there are fundamental flaws in H.235 media encryption, i.e., how long the master waits before transmitting a new payload-type after distributing the corresponding key, the directional ambiguity of encryptionUpdate and encryptionUpdateRequest, and conflicts arising from both the slave and master assigning new dynamic payload types for slave-to-master streams. These are discussed in detail, below...
1. After distributing a new key via an encryptionUpdate command for a master-to-slave RTP stream, how long should the master wait before transmitting packets with the new payload type? The problem is that packets with the new payload type (and therefore using the new key) may arrive before the encryptionUpdate command that tells the slave what payload-type/key pair to expect! There are three solutions as I see it: A. The slave discards new packets until the encryptionUpdate command arrives. B. The master uses prior network behavior to predict when the slave will receive the command and then waits so that packets using the new payload type will (hopefully) arrive sometime after that. The slave should still implement A because this prediction is imprecise. C. We require a three-way handshake by adding an encryptionUpdateAck command for master-to-slave streams (would be redundant for slave-to-master streams). This would be backwards compatible because existing implementations would simply ignore this new command which is sent from slave to master.
A and B are local workarounds; C is the ultimate solution. Discarding packets is especially problematic for video because video compression schemes rely on inter-packet dependencies. I believe H.233 anticipated this problem by providing a codepoint in H.245 to define how long the transmitter must wait before using the new key. H.235 also needs something to address this problem, preferably C.
2. H.235 says that "[the slave, acting as] a receiver (or transmitter) may request a new key [from the master]" and "The master may also decide asynchronously to distribute new key(s)." However, there is no codepoint in either the encryptionUpdate or encryptionUpdateRequest command to indicate whether it refers to a slave-to-master or master-to- slave RTP stream. The MiscellaneousCommand.logicalChannelNumber field is no help either because its values are assigned independently by each transmitter--both EPs may be using the same LCN.
For example, assume that both EPs are transmitting audio on their respective LCN 5. The master intends to asynchronously update the key for its outgoing audio by sending this command to the slave: MiscCmd(lCN=5,encrUpdate=(synFlag=200,h235Key=X)) How should the slave interpret this command? Does this refer to the slave's own, outgoing audio channel or the master's audio channel? Likewise, if the slave sends MiscCmd(lCN=5,encrUpdateReq=sharedSecret), how should the master interpret this? Does the slave want the master to update the key for the slave's audio channel or the master's audio channel?
As it is, IMO, key resynchs should not be attempted for channels that have the same LCN; however, that would be difficult for equipment from the same vendor because, depending on the LCN-assignment scheme, the same values may always be used.
3. When the master sends an encryptionUpdate command, it specifies the new dynamic payload type, or DPT, in the synchFlag field; however, this presents problems for a slave-to-master stream because the transmitter otherwise manages its own DPTs. For example, what if the master sends an encryptionUpdate command for the slave-to-master audio stream, specifying new DPT, 102, but before the slave receives it, the slave sends a video OLC with the same DPT--102? How do we resolve this conflict? Maybe the master should reject the OLC because it knows that it just assigned that DPT to the audio channel, but what cause should the master return? cause=masterSlaveConflict? Is this enough for the slave to figure out what's wrong and retry the OLC with another DPT? We should define how to resolve these kinds of conflicts, but it would be really great if we could revamp this whole key-resynch area due to all of the problems I have described here.
Paul