Completely Encrypting RTP Header Extensions and Contributing Sourcesjustin@uberti.nameCiscofluffy@iii.caMillicastsergio.garcia.murillo@cosmosoftware.io
ART
AVTCORESRTPWhile the Secure Real-time Transport Protocol (SRTP) provides confidentiality
for the contents of a media packet, a significant amount of metadata is left
unprotected, including RTP header extensions and contributing sources (CSRCs).
However, this data can be moderately sensitive in many applications. While
there have been previous attempts to protect this data, they have had limited
deployment, due to complexity as well as technical limitations.This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts
header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of
facilitating deployment.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2023 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
() 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 Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Problem Statement
. Previous Solutions
. Goals
. Terminology
. Design
. SDP Considerations
. RTP Header Processing
. Sending
. Receiving
. Encryption and Decryption
. Packet Structure
. Encryption Procedure
. Decryption Procedure
. Backward Compatibility
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. Test Vectors
. AES-CTR
. RTP Packet with One-Byte Header Extension
. RTP Packet with Two-Byte Header Extension
. RTP Packet with One-Byte Header Extension and CSRC Fields
. RTP Packet with Two-Byte Header Extension and CSRC Fields
. RTP Packet with Empty One-Byte Header Extension and CSRC Fields
. RTP Packet with Empty Two-Byte Header Extension and CSRC Fields
. AES-GCM
. RTP Packet with One-Byte Header Extension
. RTP Packet with Two-Byte Header Extension
. RTP Packet with One-Byte Header Extension and CSRC Fields
. RTP Packet with Two-Byte Header Extension and CSRC Fields
. RTP Packet with Empty One-Byte Header Extension and CSRC Fields
. RTP Packet with Empty Two-Byte Header Extension and CSRC Fields
Acknowledgements
Authors' Addresses
IntroductionProblem StatementThe Secure Real-time Transport Protocol (SRTP) mechanism provides message
authentication for the entire RTP packet but only encrypts the RTP payload.
This has not historically been a problem, as much of the information carried
in the header has minimal sensitivity (e.g., RTP timestamp); in addition,
certain fields need to remain as cleartext because they are used for key
scheduling (e.g., RTP synchronization source (SSRC) and sequence number).However, as noted in , the security requirements can be different for
information carried in RTP header extensions, including the per-packet sound
levels defined in and , which are specifically noted as
being sensitive in the Security Considerations sections of those RFCs.In addition to the contents of the header extensions, there are now enough
header extensions in active use that the header extension identifiers
themselves can provide meaningful information in terms of determining the
identity of the endpoint and/or application. Accordingly, these identifiers
can be considered a fingerprinting issue.Finally, the CSRCs included in RTP packets can also be sensitive, potentially
allowing a network eavesdropper to determine who was speaking and when during
an otherwise secure conference call.Previous SolutionsEncryption of Header Extensions in SRTP was proposed in 2013 as a solution to the problem of unprotected
header extension values. However, it has not seen significant adoption and
has a few technical shortcomings.First, the mechanism is complicated. Since it allows encryption to be
negotiated on a per-extension basis, a fair amount of signaling logic is
required. And in the SRTP layer, a somewhat complex transform is required
to allow only the selected header extension values to be encrypted. One of
the most popular SRTP implementations had a significant bug in this area
that was not detected for five years.Second, the mechanism only protects the header extension values and not their identifiers or
lengths. It also does not protect the CSRCs. As noted above, this leaves
a fair amount of potentially sensitive information exposed.Third, the mechanism bloats the header extension space. Because each extension must
be offered in both unencrypted and encrypted forms, twice as many header
extensions must be offered, which will in many cases push implementations
past the 14-extension limit for the use of one-byte extension headers
defined in . Accordingly, in many cases, implementations will need to use
two-byte headers, which are not supported well by some
existing implementations.Finally, the header extension bloat combined with the need for backward
compatibility results in additional wire overhead. Because two-byte
extension headers may not be handled well by existing implementations,
one-byte extension identifiers will need to be used for the unencrypted
(backward-compatible) forms, and two-byte for the encrypted forms.
Thus, deployment of encryption for header extensions will
typically result in multiple extra bytes in each RTP packet, compared
to the present situation.GoalsFrom the previous analysis, the desired properties of a solution are:
Built on the existing SRTP framework (simple to understand)
Built on the existing header extension framework (simple to implement)
Protection of header extension identifiers, lengths, and values
Protection of CSRCs when present
Simple signaling
Simple crypto transform and SRTP interactions
Backward compatibility with unencrypted endpoints, if desired
Backward compatibility with existing RTP tooling
The last point deserves further discussion. While other possible
solutions that would have encrypted more of the RTP
header (e.g., the number of CSRCs) were considered, the inability to parse the
resultant packets with current tools and a generally higher level of
complexity outweighed the slight improvement in confidentiality in
these solutions. Hence, a more pragmatic approach was taken to solve
the problem described in .Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
DesignThis specification proposes a mechanism to negotiate encryption of all
RTP header extensions (ids, lengths, and values) as well as CSRC values. It
reuses the existing SRTP framework, is accordingly simple to implement, and
is backward compatible with existing RTP packet parsing code, even when
support for the mechanism has been negotiated.Except when explicitly stated otherwise, Cryptex reuses all the framework procedures, transforms, and considerations described in .SDP ConsiderationsCryptex support is indicated via a new "a=cryptex" SDP attribute defined in this specification.The new "a=cryptex" attribute is a property attribute as defined in ; it therefore takes no value and can be used at the session level or media level.The presence of the "a=cryptex" attribute in the SDP (in either an offer or an answer) indicates that
the endpoint is capable of receiving RTP packets encrypted with Cryptex, as defined below.Once each peer has verified that the other party supports receiving RTP packets encrypted with Cryptex, senders can unilaterally decide whether or not to use the Cryptex mechanism on a per-packet basis.If BUNDLE is in use as per and the "a=cryptex" attribute is present for a media line, it MUST be present for all RTP-based "m=" sections belonging to the same bundle group. This ensures that the encrypted Media Identifier (MID) header extensions can be processed, allowing RTP streams to be associated with the correct "m=" section in each BUNDLE group as specified in . When used with BUNDLE, this attribute is assigned to the TRANSPORT category .Both endpoints can change the Cryptex support status by modifying the session as specified in . Generating subsequent SDP offers and answers MUST use the same procedures for including the "a=cryptex" attribute as the ones on the initial offer and answer.RTP Header ProcessingA General Mechanism for RTP Header Extensions defines two values for the "defined by profile" field for carrying
one-byte and two-byte header extensions. In order to allow a receiver to determine
if an incoming RTP packet is using the encryption scheme in this specification,
two new values are defined:
0xC0DE for the encrypted version of the one-byte header extensions (instead of 0xBEDE).
0xC2DE for the encrypted versions of the two-byte header extensions (instead of 0x100).
In the case of using two-byte header extensions, the extension identifier with value 256 MUST NOT
be negotiated, as the value of this identifier is meant to be contained in the "appbits" of the
"defined by profile" field, which are not available when using the values above.Note that as per , it is not possible to mix one-byte and two-byte headers on the same RTP packet. Mixing one-byte and two-byte headers on the same RTP stream requires negotiation of the "extmap-allow-mixed" SDP attribute as defined in .Peers MAY negotiate both Cryptex and the Encryption of Header Extensions mechanism defined in via SDP offer/answer as described in , and if both mechanisms are supported, either one can be used for any given packet. However, if a packet is encrypted with Cryptex, it MUST NOT also use header extension encryption , and vice versa. If one of the peers has advertised the ability to receive both Cryptex and
header extensions encrypted as per in the SDP
exchange, it is RECOMMENDED that the other peer use Cryptex
rather than the mechanism in when sending RTP packets
so that all the header extensions and CSRCS are encrypted. However, if there is a
compelling reason to use the mechanism in (e.g., a
need for some header extensions to be sent in the clear so that so they are
processable by RTP middleboxes), the other peer SHOULD use
the mechanism in instead.SendingWhen the mechanism defined by this specification has been negotiated,
sending an RTP packet that has any CSRCs or contains any header extensions follows the steps below. This mechanism MUST NOT be
used with header extensions other than the variety described in .If the RTP packet contains one-byte headers, the 16-bit RTP header
extension tag MUST be set to 0xC0DE to indicate that the encryption
has been applied and the one-byte framing is being used. If the RTP
packet contains two-byte headers, the header extension tag
MUST be set to 0xC2DE to indicate encryption has been applied and the
two-byte framing is being used.
If the packet contains CSRCs but no header extensions, an empty extension block
consisting of the 0xC0DE tag and a 16-bit length field set to zero (explicitly
permitted by ) MUST be appended, and the X bit MUST be set to 1 to
indicate an extension block is present. This is necessary to provide the receiver
an indication that the CSRCs in the packet are encrypted.The RTP packet MUST then be encrypted as described in ("Encryption Procedure").ReceivingWhen receiving an RTP packet that contains header extensions, the
"defined by profile" field MUST be checked to ensure the payload is
formatted according to this specification. If the field does not match
one of the values defined above, the implementation MUST instead
handle it according to the specification that defines that value.Alternatively, if the implementation considers the use of this specification mandatory and the "defined by profile" field does not match one of the values defined above, it MUST stop the processing of the RTP packet and report an error for the RTP stream.If the RTP packet passes this check, it is then decrypted as described in
("Decryption Procedure") and passed to the next layer to process
the packet and its extensions. In the event that a zero-length extension
block was added as indicated above, it can be left as is and will be
processed normally.Encryption and DecryptionPacket StructureWhen this mechanism is active, the SRTP packet is protected as follows:Note that, as required by , the 4 bytes at the start of the extension block are not encrypted.Specifically, the Encrypted Portion MUST include any CSRC identifiers, any
RTP header extension (except for the first 4 bytes), and the RTP payload.Encryption ProcedureThe encryption procedure is identical to that of except for the
Encrypted Portion of the SRTP packet. The plaintext input to the cipher is as follows:
Plaintext = CSRC identifiers (if used) || header extension data ||
RTP payload || RTP padding (if used) || RTP pad count (if used)
Here "header extension data" refers to the content of the RTP extension field,
excluding the first four bytes (the extension header ). The first 4 * CSRC count (CC) bytes of the ciphertext are placed in the CSRC field of the RTP header.
The remainder of the ciphertext is the RTP payload of the encrypted packet.To minimize changes to surrounding code, the encryption mechanism can choose
to replace a "defined by profile" field from with its counterpart
defined in ("RTP Header Processing") and encrypt at the same time.For Authenticated Encryption with Associated Data (AEAD) ciphers (e.g., AES-GCM), the 12-byte fixed header and the four-byte header
extension header (the "defined by profile" field and the length) are considered
additional authenticated data (AAD), even though they are non-contiguous in the packet if CSRCs are present.
Associated Data: fixed header || extension header (if X=1)
Here "fixed header" refers to the 12-byte fixed portion of the RTP header, and
"extension header" refers to the four-byte extension header ("defined
by profile" and extension length).Implementations can rearrange a packet so that the AAD and plaintext are
contiguous by swapping the order of the extension header and the CSRC
identifiers, resulting in an intermediate representation of the form shown in
. After encryption, the CSRCs (now encrypted) and
extension header would need to be swapped back to their original positions. A
similar operation can be done when decrypting to create contiguous ciphertext
and AAD inputs.Note that this intermediate representation is only displayed as reference for implementations and is not meant to be sent on the wire.Decryption ProcedureThe decryption procedure is identical to that of except
for the Encrypted Portion of the SRTP packet, which is as shown in the section above.To minimize changes to surrounding code, the decryption mechanism can choose
to replace the "defined by profile" field with its no-encryption counterpart
from and decrypt at the same time.Backward CompatibilityThis specification attempts to encrypt as much as possible without interfering
with backward compatibility for systems that expect a certain structure from
an RTPv2 packet, including systems that perform demultiplexing based on packet
headers. Accordingly, the first two bytes of the RTP packet are not encrypted.This specification also attempts to reuse the key scheduling from SRTP, which
depends on the RTP packet sequence number and SSRC identifier. Accordingly,
these values are also not encrypted.Security ConsiderationsAll security considerations in are applicable to this specification; the exception is Section , because confidentiality of the RTP Header is the purpose of this specification.The risks of using weak or NULL authentication with SRTP, described in , apply to encrypted header extensions as well.This specification extends SRTP by expanding the Encrypted Portion of the RTP packet,
as shown in ("Packet Structure"). It does not change how SRTP authentication
works in any way. Given that more of the packet is being encrypted than before,
this is necessarily an improvement.The RTP fields that are left unencrypted (see rationale above) are as follows:
RTP version
padding bit
extension bit
number of CSRCs
marker bit
payload type
sequence number
timestamp
SSRC identifier
number of header extensions
These values contain a fixed set (i.e., one that won't be changed by
extensions) of information that, at present, is observed to have low
sensitivity. In the event any of these values need to be encrypted, SRTP
is likely the wrong protocol to use and a fully encapsulating protocol
such as DTLS is preferred (with its attendant per-packet overhead).IANA ConsiderationsThis document updates the "attribute-name (formerly "att-field")" subregistry of the "Session Description Protocol (SDP) Parameters" registry (see ). Specifically, it adds the SDP "a=cryptex" attribute for use at both the media level and the session level.
Contact name:
IETF AVT Working Group or IESG if the AVT Working Group is closed
Contact email address:
avt@ietf.org
Attribute name:
cryptex
Attribute syntax:
This attribute takes no values.
Attribute semantics:
N/A
Attribute value:
N/A
Usage level:
session, media
Charset dependent:
No
Purpose:
The presence of this attribute in the SDP indicates that the
endpoint is capable of receiving RTP packets encrypted with Cryptex
as described in this document.
O/A procedures:
SDP O/A procedures are described in Section of this
document.
Mux Category:
TRANSPORT
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.An Offer/Answer Model with Session Description Protocol (SDP)This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]RTP: A Transport Protocol for Real-Time ApplicationsThis memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]The Secure Real-time Transport Protocol (SRTP)This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.A General Mechanism for RTP Header ExtensionsThis document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285.A Framework for Session Description Protocol (SDP) Attributes When MultiplexingThe purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions.This specification also categorizes the existing SDP attributes based on the framework described herein.SDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.Negotiating Media Multiplexing Using the Session Description Protocol (SDP)This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group.This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension.This specification updates RFCs 3264, 5888, and 7941.This specification obsoletes RFC 8843.Informative ReferencesA Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level IndicationThis document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. [STANDARDS-TRACK]A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level IndicationThis document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK]Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP).Test VectorsAll values are in hexadecimal and represented in network order (big endian).AES-CTRThe following subsections list the test vectors for using Cryptex with AES-CTR as per .Common values are organized as follows:
Rollover Counter: 00000000
Master Key: e1f97a0d3e018be0d64fa32c06de4139
Master Salt: 0ec675ad498afeebb6960b3aabe6
Crypto Suite: AES_CM_128_HMAC_SHA1_80
Session Key: c61e7a93744f39ee10734afe3ff7a087
Session Salt: 30cbbc08863d8c85d49db34a9ae1
Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4
RTP Packet with One-Byte Header ExtensionRTP Packet:
900f1235
decafbad
cafebabe
bede0001
51000200
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
900f1235
decafbad
cafebabe
c0de0001
eb923652
51c3e036
f8de27e9
c27ee3e0
b4651d9f
bc4218a7
0244522f
34a5
RTP Packet with Two-Byte Header ExtensionRTP Packet:
900f1236
decafbad
cafebabe
10000001
05020002
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
900f1236
decafbad
cafebabe
c2de0001
4ed9cc4e
6a712b30
96c5ca77
339d4204
ce0d7739
6cab6958
5fbce381
94a5
RTP Packet with One-Byte Header Extension and CSRC FieldsRTP Packet:
920f1238
decafbad
cafebabe
0001e240
0000b26e
bede0001
51000200
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
920f1238
decafbad
cafebabe
8bb6e12b
5cff16dd
c0de0001
92838c8c
09e58393
e1de3a9a
74734d67
45671338
c3acf11d
a2df8423
bee0
RTP Packet with Two-Byte Header Extension and CSRC FieldsRTP Packet:
920f1239
decafbad
cafebabe
0001e240
0000b26e
10000001
05020002
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
920f1239
decafbad
cafebabe
f70e513e
b90b9b25
c2de0001
bbed4848
faa64466
5f3d7f34
125914e9
f4d0ae92
3c6f479b
95a0f7b5
3133
RTP Packet with Empty One-Byte Header Extension and CSRC FieldsRTP Packet:
920f123a
decafbad
cafebabe
0001e240
0000b26e
bede0000
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
920f123a
decafbad
cafebabe
7130b6ab
fe2ab0e3
c0de0000
e3d9f64b
25c9e74c
b4cf8e43
fb92e378
1c2c0cea
b6b3a499
a14c
RTP Packet with Empty Two-Byte Header Extension and CSRC FieldsRTP Packet:
920f123b
decafbad
cafebabe
0001e240
0000b26e
10000000
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
920f123b
decafbad
cafebabe
cbf24c12
4330e1c8
c2de0000
599dd45b
c9d687b6
03e8b59d
771fd38e
88b170e0
cd31e125
eabe
AES-GCMThe following subsections list the test vectors for using Cryptex with AES-GCM as per .Common values are organized as follows:
Rollover Counter: 00000000
Master Key: 000102030405060708090a0b0c0d0e0f
Master Salt: a0a1a2a3a4a5a6a7a8a9aaab
Crypto Suite: AEAD_AES_128_GCM
Session Key: 077c6143cb221bc355ff23d5f984a16e
Session Salt: 9af3e95364ebac9c99c5a7c4
RTP Packet with One-Byte Header ExtensionRTP Packet:
900f1235
decafbad
cafebabe
bede0001
51000200
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
900f1235
decafbad
cafebabe
c0de0001
39972dc9
572c4d99
e8fc355d
e743fb2e
94f9d8ff
54e72f41
93bbc5c7
4ffab0fa
9fa0fbeb
RTP Packet with Two-Byte Header ExtensionRTP Packet:
900f1236
decafbad
cafebabe
10000001
05020002
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
900f1236
decafbad
cafebabe
c2de0001
bb75a4c5
45cd1f41
3bdb7daa
2b1e3263
de313667
c9632490
81b35a65
f5cb6c88
b394235f
RTP Packet with One-Byte Header Extension and CSRC FieldsRTP Packet:
920f1238
decafbad
cafebabe
0001e240
0000b26e
bede0001
51000200
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
920f1238
decafbad
cafebabe
63bbccc4
a7f695c4
c0de0001
8ad7c71f
ac70a80c
92866b4c
6ba98546
ef913586
e95ffaaf
fe956885
bb0647a8
bc094ac8
RTP Packet with Two-Byte Header Extension and CSRC FieldsRTP Packet:
920f1239
decafbad
cafebabe
0001e240
0000b26e
10000001
05020002
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
920f1239
decafbad
cafebabe
3680524f
8d312b00
c2de0001
c78d1200
38422bc1
11a7187a
18246f98
0c059cc6
bc9df8b6
26394eca
344e4b05
d80fea83
RTP Packet with Empty One-Byte Header Extension and CSRC FieldsRTP Packet:
920f123a
decafbad
cafebabe
0001e240
0000b26e
bede0000
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
920f123a
decafbad
cafebabe
15b6bb43
37906fff
c0de0000
b7b96453
7a2b03ab
7ba5389c
e9331712
6b5d974d
f30c6884
dcb651c5
e120c1da
RTP Packet with Empty Two-Byte Header Extension and CSRC FieldsRTP Packet:
920f123b
decafbad
cafebabe
0001e240
0000b26e
10000000
abababab
abababab
abababab
abababab
Encrypted RTP Packet:
920f123b
decafbad
cafebabe
dcb38c9e
48bf95f4
c2de0000
61ee432c
f9203170
76613258
d3ce4236
c06ac429
681ad084
13512dc9
8b5207d8
AcknowledgementsThe authors wish to thank for
pointing out many of the issues with the existing header encryption
mechanism, as well as suggestions for this proposal. Thanks also to
, , and for their reviews
and suggestions.Authors' Addressesjustin@uberti.nameCiscofluffy@iii.caMillicastsergio.garcia.murillo@cosmosoftware.io