[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re-keying RTP streams


In H.323 (A/V conferencing as defined by the ITU), the media streams are 
transported by RTP; each stream also having a corresponding RTCP 
channel. Both the RTP and the RTCP channels are (of course) unreliable.

H.323 also has a reliable (TCP) control channel (H.245) which is used to 
set up the RTP/RTCP channels and to control the conference. This channel 
remains open for the duration. [In a multipoint conference, each 
endpoint has a separate H.245 channel to the Conference Controller (the 
MC), and the RTP/RTP channels are multicast. In general, the H.245 channel 
cannot be used to communicate amongst endpoints; between transmitter and 
receivers].

In extending H.323 to provide private communications, the H.245 channel 
becomes secure (using TLS), and the security parameters for an RTP 
channel [the RTCP channel is not encrypted] are negotiated on it(them). 
In particular, the keys for the RTP channel are distributed on the H.245 
channel(s) by the MC. All before thr RTP/RTCP sessions are established.

The problem arises when the MC needs to distribute fresh keys after some 
period (or because the old key has been compromised for some reason). 

There's no problem in distributing the new keys (this is done on the 
reliable, secure H.245 channel). But how should the Transmitter and 
Receiver (or multiple receivers, in the multicast case) synchronize on 
the new key?

The H.245 channel cannot be used for this purpose, since it does not 
(at least in the multipoint case) connect the transmitter to all 
receivers.

We are left with just the RTP and RTCP channels.

The RTP headers contain both sequence numbers and timestamps.

There are two proposals:

1. There is a bit in all RTCP packets which flips when a new key starts 
   being used on the RTP stream (and remains in the new state until the 
   next key change). The first packet of the new state also contains the        
   sequence number of the RTP stream at which the new key starts to apply. 
   (This packet could be sent several times). A receiver will always see 
   the bit flip but, if it misses the sequence number, it can immediately 
   start using the new key; some number of RTP packets may have been            
   indecipherable before this point.

2. The bit (as described above) would be in the RTP header (probably 
   requiring an extended header). The receivers would change key as soon 
   as they see the bit flip.

I would very much like to hear opinions on these solutions, but preferrably,
better proposals. 

john_h_wilson@ccm.jf.intel.com