Time 3
(Active Speaker)       ______________           
 Endpoint A >a>a>a>a>a>|            |>a>a>a>a>a> Endpoint C
            <b<b<b<b<b<|            |
                       | RTP        |
                       | Translator |
(Prev Speaker)         | Forwarding |
 Endpoint B <a<a<a<a<a<| Switch     |>a>a>a>a>a> Endpoint D
            >b>b>b>b>b>|____________|

Figure 3: RTFS Media Flow for Active Speakers

Meeting the objective of scalability and simplicity in this media switching architecture starts with minimizing/eliminating the media processing performed by the media switching device, but can also to be extended to cryptography, where crypto processing and crypto state maintained by the media switching/RTFS devices are minimized. With the advent of cloud-based services, it is essential to enable deployments where the privacy of the media can be assured even when a third-party service is used for conference switching. Then enterprises can use cloud-based, third-party conferencing services while restricting such from accessing and manipulation of their media content. The ability to eliminate the need of media switching/RTFS devices to decrypt and re-encrypt packets is not merely a scalability and simplicity requirement, but is also a core security requirement in cloud-based conferencing services.

4. RTP header manipulation

A media switching/RTFS device might need to modify some of the RTP header fields to map between different values picked by different endpoints prior to switching. An example is the RTP payload type values which for SIP endpoints calling into the conference are picked by the endpoints. Different endpoints are likely to pick different values for the same media format. The media switching device is responsible for mapping between such different values. In the case of RTP payload types, the conference system might be able to send a SIP reinvite to renegotiate the RTP payload type value down to a shared value hence avoiding the remapping. This mechanism does not always work as endpoints can choose to use asymmetric payload types. Renegotiation also adds complexity and delays to the conferencing system. Other RTP header fields such as RTP extension headers can also be modified, deleted or added as they are negotiated separately with each participants.

On the other hand, two of the RTP fields must not be modified by media switches that do not have access to the media encryption keys. These two fields are the SSRC and the RTP sequence number. Both fields are used in the calculation of the SRTP cipher’s IV, thus requiring a total re-encryption upon modification.

Below is the set of RTP header fields along with whether a media switching/RTFS device might modify them, unlikely to modify them or must not modify them.

• Version (V): This field is unlikely to be modified by the media switching device
• Padding marker (P): This field is unlikely to be modified by the media switching device
• Extension (X): The media switching device might modify this field when it needs to add RTP extension headers where none existed or if it needs to delete existing RTP extension headers
• Contributing sources count (CC): The media switching device is unlikely to modify this field
• Marker bit (M): This field is unlikely to be modified by the media switching device
• Payload Type (PT): The media switching device might modify this field to map between different RTP type values picked by different endpoints
• Sequence Number (SEQ): The media switching device must not modify this field
• Timestamp (TS): This field is unlikely to be modified by the media switching device
• Synchronization Source (SSRC): This field must not be modified by the media switching device
• Extension Header (ExtHDR): The media switching device is likely modify this field either to change its value or to delete it completely

5. Requirements

The following are the security solution requirements for media switching/RTFS device that enable media privacy to be maintained across participant endpoints.

1. Solution needs to maintain all current SRTP security properties.
2. Solution need to extend replay attacks protection to cover cross-participants replay prevention. Packets sent between the media switching device and participant A cannot be retransmitted to participant B undetected.
3. Keys used for encryption and authentication of RTP payloads and other information deemed unsuitable for accessibility by the media switching device must not be generated by or accessible to any of the media switching devices.
4. The media switching devices must be capable, if authorized, of changing any part of an RTP header except for the RTP sequence number and SSRC. This in turn mandates that the media switching devices must have access to the keys used for the authentication of RTP header fields other than SSRC and RTP sequence number when a proper authorization is in place.
5. The SRTP master keys must not be generated by the media switching devices
6. The media switching devices must not be involved in the distribution of the SRTP master keys to participants nor in the authentication of the participants identities for the purpose of key distribution
7. The media switching devices must be able to switch an already active SRTP stream to a new receiver while guaranteeing the timely synchronization between the SRTP context of the transmitter and its old and new receivers. Of special interest is the RoC part pf the SRTP context due to its dynamic nature. It is important to note that media switching devices can not change RTP sequence numbers as that would require packet re-encryption.

6. Example Scenario

The above requirements (especially 3 and 4) imply that there is a need for SRTP ciphersuites that allow a split key and split authentication model. Instead of the current single SRTP master key, this document requires two independent SRTP master keys. The first is an end to end key that is used for the encryption of the RTP payload and other information requiring end-to-end encryption. The end to end key is also used for the authentication of the RTP payload, the RTP sequence number, RoC and SSRC as well as any other information requiring end-to-end authentication. The second key is hop-by-hop key used for the authentication of the RTP packet as well as any other information requiring hop by hop authentication (e.g. RTCP packet authentication). The hop-by-hop key can also be used for encryption of information that the switch is authorized to access and modify, such as encrypted RTCP packets.

RTP Packet 
-----------------------   ^
| CC M | PT | Seq Num |   |  
|     Time Stamp      |   |  Auth( RTP Packet + RoC, HopByHopKey ) 
|        SSRC         |   |
|        CSRCs        |   |
-----------------------   |   ^
|                     |   |   |  Enc( Payload, End2endKey )
|       Pay Load      |   |   |  
|                     |   |   |  Auth( Payload + SSRC + SeqNum + RoC,
-----------------------   V   V        End2endKey )

Note that media from endpoints are flowing in direction of the arrows.

Time 1
    (Prev Speaker)                              (Active Speaker)
C Context Instantiated ______________  A Context Instantiated
 Endpoint A >a>a>a>a>a>|            |>a>a>a>a>a> Endpoint C
            <c<c<c<c<c<|            |<c<c<c<c<c<
                       | RTP        |
                       | Translator |
                       | Forwarding |
 Endpoint B <c<c<c<c<c<| Switch     |>c>c>c>c>c> Endpoint D
C Context Instantiated |____________|  C Context Instantiated

Time 2                                          (Prev Speaker)  
C Context Out of Sync                  A Context Out of Sync 
B Context Instantiated ______________  B Context Instantiated 
 Endpoint A <b<b<b<b<b<|            |>b>b>b>b>b> Endpoint C
                       |            |<c<c<c<c<c<
                       | RTP        |
                       | Translator |
    (Active Speaker)   | Forwarding |
 Endpoint B <c<c<c<c<c<| Switch     |>b>b>b>b>b> Endpoint D
            >b>b>b>b>b>|____________|  C Context Out of Sync 
C Context Up to Date                   B Context Instantiated 

Time 3
    (Active Speaker)   
C Context Out of Sync                   A Context Synchronized
B Context Up to Date   ______________   B Context Out of Sync         
 Endpoint A >a>a>a>a>a>|            |>a>a>a>a>a> Endpoint C
            <b<b<b<b<b<|            |
                       | RTP        |
                       | Translator |
    (Prev Speaker)     | Forwarding |
 Endpoint B <a<a<a<a<a<| Switch     |>a>a>a>a>a> Endpoint D
            >b>b>b>b>b>|____________|   C Context Out of Sync   
C Context Out of Sync                   B Context Out of Sync   
A Context Instantiated                  A Context Instantiated