Flaws in H.235 media encryption

Paul Long plong at PACKETIZER.COM
Mon Aug 12 13:39:16 EDT 2002

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

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.


More information about the sg16-avd mailing list