Using RTX with Privacy Enhanced RTP Conferencing (PERC)
draft-grozev-perc-double-rtx-00

Abstract

This document describes the use of the RTX format for RTP packet retransmission in the context of a PERC (Privacy Enhanced RTP Conferenceing) conference.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 29, 2017.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Terminating RTX
• 4. RTP Padding
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

In multi-endpoint RTP conferences it is desired for middleboxes (e.g. Selecting Forwarding Units (SFUs), or in the case of PERC Media Distributors (MDs)) to terminate RTP packet retransmission, because this can reduce the retransmission delay and the unnecessary retransmission of packets. In the context of PERC, if RTX is handled as a regular media stream, then an MD can not terminate packet retransmission.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Terminating RTX

The RTX format (RFC 4588) uses the first two bytes of the RTP payload (the Original Sequence Number field (OSN)) to transport the RTP sequence number of the retransmitted packet.

If the procedure used for regular media streams is also used for RTX, the MD does not have access to the OSN field, because it is E2E encrypted as part of the RTP payload, and this prevents it from terminating retransmissions.

In the context of PERC, RTX should be performed only HBH. That is, the payload of the RTX packet must be encrypted with the HBH context, but not with the E2E context.

Specifically, when an entity retransmits a packet using RTX it:

1. Takes an E2E encrypted packet to be retransmitted.
2. Applies the RTX transformation (replaces the SSRC, payload type and sequence number, and inserts the OSN field in the payload.
3. Performs the HBH SRTP transformation.

4. RTP Padding

RFC3550 allows an RTP packet to contain only padding, and no payload. The number of padding bytes is contained in the last byte of the payload, and it is encrypted by SRTP.

In the context of PERC, an MD does not have access to the padding length field of an RTX packet, and therefore it can not determine whether the packet contains non-padding payload or not.

RTX packets with padding only are currently used by some bandwidth estimation algorithms when probing for additional bandwidth availability. Bandwidth estimations have a strictly hop-by-hop context, so MDs therefore usually terminate them by recognizing and dropping all incoming probe packets. They then generate new ones for their own estimations.

In order to recognize an incoming packet as a probe-only one, an MD needs to inspect its last octet and compare it to the overall length of the payload. Yet, in a PERC scenario this last octet is protected by PERC's end-to-end encryption and will hence be unreadable to the MD. The MD will therefore have no choice but to treat this as a regular RTX packet: replace its sequence number, payload type, and SSRC and forward it to receivers that would likely fail in unpredictable ways (e.g., either failing SRTP authentication or maybe even feeding garbage data to their decoders).

A similar problem also exists for probe packets the the MD generates and that receivers have no way to reliably recognize.

In order for MDs and receivers to properly terminate bandwidth estimation, it is therefore necessary for an MD to reliably recognize such padding-only packets.

The use of a single "padding-only" bit in any new or existing RTP header extension is ony way to achieve this. PERC MDs are already likely to rely on the framemarking header extension [I-D.ietf-avtext-framemarking] and we propose transporting this bit there. We propose to use the first bit of the unused bits in the format for non-scalable streams, which is marked as the P bit in the diagram below.

            
  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  ID=? |  L=0  |S|E|I|D|P 0 0 0|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+