Re-keying RTP streams
John H Wilson <John_H_Wilson@ccm.jf.intel.com> Wed, 13 November 1996 18:31 UTC
Received: from cnri by ietf.org id aa19185; 13 Nov 96 13:31 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa18035; 13 Nov 96 13:31 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23213 for ipsec-outgoing; Wed, 13 Nov 1996 13:13:54 -0500 (EST)
Date: Wed, 13 Nov 1996 10:12:00 -0800
From: John H Wilson <John_H_Wilson@ccm.jf.intel.com>
Message-ID: <Wed
To: ipsec@tis.com
Subject: Re-keying RTP streams
Sender: owner-ipsec@ex.tis.com
Precedence: list
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
- Re-keying RTP streams John H Wilson