Network Working Group M. Westerlund
Internet-Draft Ericsson
Intended status: Informational October 19, 2015
Expires: April 21, 2016

Handling Considerations for the RTP fields in PERC


This draft discusses how the Privacy Enhanced RTP Conferencing solution will need consider the different RTP header fields in regards to both hop-by-hop and end-to-end security.

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

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 April 21, 2016.

Copyright Notice

Copyright (c) 2015 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 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

In the design of the Privacy Enchanced RTP Conferencing (PERC) end-to-end security solution for RTP [RFC3550] media streams there is need to carefully consider what properties the different RTP fields have, their security and privacy implications, and provide recommendations and requiremements for how they are handled. This review needs to consider both hop-by-hop properties as well as the end-to-end security.

The fields analysed are that of a regular RTP packet. This is to consider the impact of the information that exists normally in an centralized multi-party conference.

This document is a working document, and not intended to be published as an RFC.

2. Definitions

This document uses the following definitions:

An RTP stream sending and/or receiving entity that is part of the end-to-end security context.
Media Delivery Device - An RTP middlebox that operates according to any of the three possible RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] that is possible in the PERC system:
Third Party:
An entity that is neither an endpoint nor an MDD.

2.1. Connection Case

This analys is based on a basic connectivity use cases, where a media stream sending endpoint (originating) sends one or more RTP streams to a MDD. That MDD selectively forwards media to another MDD (Cascaded) which further sends the media (when selecting to) from the originating endpoint to the receiving endpoint. This connection case is depicted in Figure 1.

+-------------+     +------+     +------+     +-----------+
|             |     |      |     |      |     |           |
| Originating +---->+ MDD  +---->+ MDD  +---->+ Receiving |
| Endpoint    |     |      |     |      |     | Endpoint  |
|             |     |      |     |      |     |           |
+-------------+     +------+     +------+     +-----------+

Figure 1

The MDDs are not trusted with anything except forwarding media according to the policies given to it by endpoints and to not forward media from third parties.

2.2. Additional Assumptions

This document assumes that the originating media stream is uniquely identified by the SSRC value used by the originating endpoint. This SSRC value needs to be preserved to the receiving endpoint. It is assumed that even if SSRC/CSRC translation is in use by an MDD, there will exist an one to one mapping between originating SSRC value and the SSRC/CSRC value the receiving endpoint receives. Further for MDDs operating as Media Switching RTP mixers they will indicate the originating SSRC as CSRC when it switches that stream into one of the MDD's SSRCs. The CSRC will need to be maintained even over multiple MDDs.

3. RTP Packets Fields

This section analyses each RTP packet field or part. The anlysis for each field should answer the following questions:

As a general rule, the only reason to encrypt something without integrity Protection is to save the overhead of the tag. As the PERC Solution will have both hbh tag and e2e tag, no overhead is saved by not integrity protecting so as a general rule confidentiality implies authentication.

Some general considerations apply. Fields that are end-to-end authenticated is actually recommended to be hop-by-hop authenticated, even when there only are a end-to-end version of the field. The reason for this is to detect modifications at the earliest instance and avoid wasting resource further down the path.

3.1. Version Field (V)

As the solution is focused on RTP as defined by [RFC3550] this field must be 2. The field is not expected to be modified by an MDD. The receiving endpoint will also assume that the originating endpoint used RTP (v=2). Modification of this field should result in the packet being dropped by the receiving endpoint or MDD, independent if it is hop-by-hop authenticated. The version field does not require end-to-end authentication as the MDD has more efficient denial of service attacks that it can perform on the endpoints, including not forwarding a single media packet/stream. The field can not be confidentiality protected end-to-end as the MDD must know that it is RTP (v=2) it receives. The field may be hop-by-hop confidentiality protected as part of an attempt to hide that the packet stream is RTP, although packet analysis is likely to reveal that the streams are real-time media anyway.

If ever an RTP v=3 is defined in the future it is clear that one particular version must be used per hop. It is not possible to predict if it would be possible to have the end-to-end information translated between one hop using v=2 and one using v=3. If such translation and e2e authentication would be performed, the receiving entity must be aware of it, to know that the field's value is not the original one. Thus, it becomes a choice if one want to require explicit knowledge of the translation, or not demand it by excluding the field from end-to-end authentication.

3.2. Padding Indicator bit (P)

The padding bit is an indicator for the presence of the padding octets at the end of the RTP payload. As further discussed in Padding Octets [sec-padding-octets] the padding is considered part of the payload and jointly protected with the payload. The reason for this is that padding can help hide length variations in the payload that can leak information about the media content being carried [RFC6562].

As the Payload and padding octets are end-to-end protected, the padding indicator can't be modified by the MDD, due to its inability to remove the padding octets. For correct processing in the receiving endpoint the padding indicator needs to be correct. Therefore it should be end-to-end authenticated. It could be end-to-end confidentiality protected. The benefit of protecting it end-to-end would be that the MDD would not know if the end-to-end payload is padded or not. Knowing if the payload is padded or not reduces the uncertainty for an attacker that attempts to perform content analysis based on payload length. Because of that it would beneficial to protect the padding bit also hop-by-hop, if not already protected end-to-end. The padding bit should be hop-by-hop authenticated to protect if end-to-end authentication is not used.

3.3. Extension Indicator bit (X)

The extension indicator bit indicates if the header extension part is present. The MDD will be the target recipient of some RTP header extensions. It can also remove the ones not necessary to reach the receiving endpoint. This can result that something starting out with header extensions may no longer have any on the last hop. Thus, the MDD must be able to modify the X bit. Currently, there is no strong argument for why a receiving endpoint needs to know that there where header extensions present from the originating endpoint that has been removed. It might arise when using end-to-end protected header extensions and want to ensure detection of removal of such header extensions by the MDD. However, other methods for ensuring that exist, most likley by authenticating the end-to-end header extensions themselves. Conclusion is that there are no need for knowing the original value.

There are no need for end-to-end confidentiality, nor authentication. Hop-by-hop authentication shall be used to prevent unnecesary erronous processing of the packet. Hop-by-hop confidentiality is recommended but lack of it has very minor impact as the information leaked is the presence or not of header extensions. Having this knowledge may simplify payload length based attacks in regards to the content.

3.4. CSRC Count (CC)

Contributing Sources count indicates how many CSRC values that are part of the CSRC field and are critical to know to correctly find the start of the payload within the RTP packet. When using MDDs that follow the Media Switching RTP Mixer topology (Section 3.6.2 of [I-D.ietf-avtcore-rtp-topologies-update]) the MDD will need to insert the originating endpoint's SSRC as CSRC value in the outgoing stream when that stream contains a payload from the by the CSRC identified originating stream. This results that in the MDD can modify and add CSRC fields when performing switching. And in cases an MDD operating like a SFM (Section 3.7 of [I-D.ietf-avtcore-rtp-topologies-update]) receives a switched media stream it may attempt to restore the mixed stream into a number of SSRC specific streams, thus removing the CSRC field. An originating endpoint is unlikely to have a need to insert an CSRC, this as in PERC context it is expected that the media sources have a direct relation to the endpoint. The need for an endpoint to express that it generates a mixed or switched stream where it can generate "end-to-end" secured payload with such properties appear to be in a violation of the intended security model. The current conclusion will be no need for orignal value.

The CC field does not appear to need end-to-end authenticated, nor confidentiality protected. The CC field shall be hop-by-hop authenticated to prevent third party modifcations as it effects finding the payload limit. Errors here can only lead to wasting resources for further entities in the conference, and should be detected as early as possible. Erronous payload delimitation due to error in the CC field will result in the receiving endpoint's integrity verification of the end-to-end payload will fail. Hop-by-hop confidentiality is recommened as the CC field allows a third party to better determine the RTP payload size, thus being information with some privacy sensitivity

3.5. Marker Bit (M)

The marker bit semantics are dependent on the RTP payload format in use. Two dominant semantics are in use, but not limited to these two. Video primarily use it to indicate the last packet carrying part of an encoded video frame. Audio primarily use it to indicate the start of a talk spurt, indicating where an receiver could adjust its jitter buffer and playout.

The MDD could depending on semantics potentially have an interest in setting the marker. One example could be an MDD that like to set an marker bit for audio to indicate the start of a media stream when swtiching in/on a particular originating endpoint's stream. In the discussion about this for PERC the conclusion is that an MDD can use other methods for indicating the switch in event. The main argument for this is to avoid having to understand the semantics of the payload currently present. Especially as codec switches can change the semantics in the middle of an ongoing conference session. The marker bit is meta data about the stream that can be relevant for knowing where appropriate switching points are, depending on the semantics.

The receiving endpoint's need for original value from the originating endpoint is dependent on the semantics. However, for many semantics it is important for the originating value is know by the receiving endpoint. Therefore the recommendation is to require the originating value to be made available to the receiving endpoint.

The recommendation is to use end-to-end authenticaiton of the value. End-to-end confidentiality needs exits as the marker bit can carry semantics direclty related to the content encoded. Audio's common semantics as start of speech burst, is telling the passive monitoring something on the ongoing flow of information. This needs to be balanced against the potential needs for the MDD to have this information for better function, like knowing where to switch.

The marker bit should be both hop-by-hop authenticated as well as confidentiality protected. This is to prevent modification of this important piece of information to avoid that the MDD react to manipulated data. The confidentiality is there to prevent third parties from learning the information, potentially privacy sensitive.

3.6. Payload Type (PT)

The payload type identies the RTP payload format and thus normally the encoding of the media content in the payload. The dominant usage is to use some type of signalling protocol to agree on a mapping between a payload format and its parameters following the payload formats MIME type and the 7-bit field values. There exist some statically assigned codecs, but these values can still be assigned to other payload format configurations by the signalling.

The MDD is expected to be required to rewrite the PT values when forwarding the payloads. The reason for this is that in many signalling contexts the binding between a payload type value and the payload format configuration will only have local meaning. And the PT value identifying a particular codec configuration is not unlikely a different PT value with another endpoint. Thus, the MDD will need to maintain translation tables for each ingress and egress pair.

As knowing the correct payload format and codec configuration is cruical to be able to correctly decode the received payload, it is in the interest of the receiving endpoint to know the originating payload format and codec configuration. This would indicate a need to know the original value of the PT field. Unfortunately that is not sufficient to securly verify that no malicious changes has occurded on the path by a third party or the MDDs. The receiving endpoint would need to know also how the originating PT values map against the payload format and its parameters to verify correctness.

End-to-end authentication of original value is recommended, given that the receiving endpoint also get the payload format configuration. End-to-end confidentiality would be desirable as it simplifies for an attacker to know which codec is used, or at least detect when the codec changes. When doing content analytics it simplifies to know the codec, so the codecs behaviour can be accounted for. However, this is not cruical information, and it appears very difficult to confidentiality protect the PT field value in respect to the MDD.

Hop-by-hop authentication is important to prevent thrid-party modifications and avoid wasting resources by forwarding erronous information. Hob-by-hop confidentiality is recommended by not cruical as the information leakage can be limited to knowing when the same codec is being used. If the signalling is kept confidential towards any third party, then this minimal leakage is achieved. If one uses payload formats that has static mappings without remapping them, then the codec will be known by third parties. As a countering requirement that may need to be considered. The payload type is usually needed in third party quality monitors that gather statitics about the RTP packet stream as it passes a measuring point.

3.7. Sequence Number

The MDD will need to modify the originating sequence number when it performs any switching or on/off operations on the RTP stream. This to ensure that the outgoing RTP stream has consistent sequence numbers with the number of packets actually sent, rather then how many that is being received at the ingress.

The receiving endpoint likely need the originating sequence number or something semantically equivalent. The reasons for this is decryption, replay protection, and packet reordering. If the receiving endpoint knows through an end-to-end authenticated way the sequence in which the payloads was originated, the receiver can prevent using payloads that are replays from previous points in the RTP stream.

End-to-End authentication of the original payload seqence number is likely required. End-to-end confidentiality is not possible as the MDDs needs to know in which sequence the payloads where sent. Being able to re-order the payloads could help improving the confidentiality of the media content as analysis using randomly reordered packets would be significantly more difficult. However, due to the real-time properties, such actions are unlikely to be feasible. However, if any such deliberate reordering would be attempted, the original sequence number would need to be confidentiality protected.

Hop-by-hop authentication of the sequence number is recommended to prevent attacks on the receiver buffer, including forcing the receiver to discard other packets. Hop-by-hop confidentiality is recommened but not required. This as the goal would be to attempt to hide the correct sequence, across unintentional or intentional reordering, and enable detection of lost packets. Such knowledge has some use in content analysis. At the same time having this information in the clear enables third party monitoiring to gather statistics about re-ordering and packet loss.

3.8. Timestamp

The RTP timestamp expresses playout related time information. When a MDD is an media switching RTP mixer, it will need to provide a consistent timeline across switches. The timeline is also the outgoing SSRC's (from the mixer) internal timeline, and not specific to any of the originating RTP streams being switched into the stream. Thus, the timestamp in relation to the originating packet will need to be rewritten.

The receiving endpoint could have use of the original value. First it could be used to detect malicous rewrite attempts that forces the receiver into flusing the receiver buffer or perform concealment over media that otherwise would have been played out. Secondly it can be used as a protection against the delay attack discussed above in Section 3.7. However, protection against these type of attacks by the MDD can be fragile and may cause more harm than gain. For the first type of attacks, it is clear that some modifications of the timeline between originating sources are necessary. This is first to align content segments so they have matching boundaries. Secondly, as the different endpoint don't have synchronized clocks there will be clock skew, thus some clock skew compensation at switch points are to be expected. For the delay attack protection also the clock skew issue is present. For both clock skew related issues this is further complicated that the clock skew compensation information is in RTCP and curently under control of the MDD. Thus, one would need to consider protecting this RTCP information end-to-end, or provided using other protocol means.

If the original timestamp needs end-to-end authentication is dependent on if one can define a mechanism for delay attack protection using it. If not it is likely not needed. End-to-end confidentiality will be difficult as the MDD will need to know where in the timeline a particular payload belongs to. This is also closely related to the payload sequence information discussed above Section 3.7.

Hop-by-hop authentication is needed to prevent third party attacks. Hop-by-hop confidentiality is recommended as it prevents leaking information about the sequence of the media and how much media is packed into each payload, especially for audio. This is coupled to the protection on provide the sequence number. At the same time a third party quality monitor likely need the RTP timestamp to perform its role adequately.

3.9. SSRC

The SSRC identifies the source of the RTP packet. As each SSRC has its own RTP sequence number space as well as timestamp sequence, collisions shall be avoided. For the PERC usage it is also important that a receiving endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias). The important security related issue is that unless the originating RTP stream can be identified the MDD could create one outgoing stream that selects packets from either of them. This may be challenging due to replay protection, but not impossible depending on how the sequence number and timestamps align. To avoid having multiple identifers for the RTP packet stream, the design team has proposed that the SSRC shall be unique and the original value preserved to the receiving endpoint.

Even if the originating endpoints have unique SSRCs, it is not clear if the same requirement will be extended to the MDD, and then especially media switching RTP mixers that have their own SSRCs. Thus translation of SSRC as a method for dealing with SSRC collisions may need to be dealt with.

The original SSRC needs to be authenticated end-to-end to prevent the splicing attack described above. The SSRC can't be confidentiality protected end-to-end as it is required by the MDD to know which packets are part of the same RTP stream. Note that for an media switching mixer, the SSRC field will not be the original one, instead that value is expected to be put in the CSRC field.

The SSRC shall be authenticated hop-by-hop to prevent splicing or redirecting packets between incoming RTP streams. It would have benefits to confidentiality protect the SSRC towards third parties as it would make it more difficult for such an attacker to associate packets to different RTP streams, when the originating endpoint sends more than one stream in the same transport flow.

3.10. CSRC List

The contributing source list contains the SSRC values of the RTP streams that contributed to the media content of this packet. In the PERC case, where the payload is end-to-end and not mixed in the middle boxes the field is expected to contain a single value. This is for the case where the originating SSRC is moved into the CSRC field with the MDD acts as an media switching mixer. As discusssed in Section 3.4 there could in theory be cases where an endpoint is performing mixes and thus need to include multiple CSRC values, but it appears to be contradicting the security model.

The MDD needs to be able to add the CSRC field when not present. As it populates it with the orignating SSRC value, it simple moves the information from one place to another. Thus, the authentication and confidentiality requirements will be the same as for the SSRC field. End-to-End authentication of the CSRC value is performed, when the field is present instead of the SSRC field. Here CSRC fields from an originating endpoint will be an issue that requires special considerations. End-to-end confidentiality is not possible, due to the MDD moving the field from the SSRC place.

Hop-by-hop the CSRC list shall be authenticated to prevent a third party to corrupt the field. Hop-by-hop confidentiality is recommended but not requried.

3.11. Header Extensions

This section assumes that the RTP header extension is used following the mechanism in [RFC5285]. Thus, the header extension can contain multiple different extensions as agreed and identified according to signalling. Each header extension format in use are assigned an identifer that are per endpoint and RTP session agreed. This results in that the MDD are likely to need to renumber them between ingress and egrees if they forward the extension. In addition a number of header extensions in use will be intended and targeted to the MDD. When MDDs are cascade they will likely need to forward the extension between themselves, and only on the last leg towards the receiving endpoint remove them.

What security properties that are needed will be highly dependent on the header extension and their content. Therefore a number of header extensions are analysed in this section to determine if they contain material that need end-to-end authentication or also end-to-end confidentiality.

The current summary of the known information is the following. The MDD needs to modify the IDs and add or remove some header extensions. There are header extensions that really should use hop-by-hop confidentiality (See Audio levels), and all should have hop-by-hop authentication to prevent modification impacting the MDD's processing and forwarding decision. The SMPTE time-code mapping, the Cordination of Video Orientation, the Region of Interest and the SDES information are all information from the originating endpoint intended to receiving endpoint. In the case of the SDES information, likely also needed by the MDD. This is information that all should be authenticated end-to-end to ensure that the MDD can't modify it. SPMTE time-codes, Coordination of video orientation (CVO), Region of Interest (ROI) are all information that the MDD lack need to see to be able to perform its task to forward media appropriately. Thus end-to-end confidentiality is recommended to be applied.

3.11.1. Transmission Time offsets

The Transmission Time offsets [RFC5450] are header extension that encodes the time of transmission of the RTP packet in relation to the RTP timestamp. Being directly related to the transmission of the whole RTP packet it is non-sensitive information from a privacy and confidentiality aspect. It only provides more detaild information in what sequence a packet actually was sent, information that both the timestamp and sequence number provide.

The authentication of this information can be valuable. However, as the MDD receives and the potentially fowards it, it has limited end-to-end value, and it is more appropriate for an MDD to rewrite this header when forwarding the packet to provide hop-by-hop transport information. Thus, hop-by-hop authentication is recommended.

3.11.2. SMPTE time-code mapping

The SMPTE time-code mapping [RFC5484] is providing SMPTE time codes associated with the RTP packet. This information is meta data to the media content in the payload. End-to-end authentication is recommend to ensure that the data is non-modified from the originating endpoint. The meta data may be privacy sensitive as it reveals information about the timeline for the content the receiver sees, inluding seeking in stored contentet provided into a conferencing context. There appear to be no reason why the MDD should have access to this, and end-to-end confidentiality is recommended.

Hop-by-hop authentication is recommended, and confidentiality should be applied if not used end-to-end.

3.11.3. Synchronisation metadata

Synchronisation metadata [RFC6051] is an header extension that provides the NTP and RTP Timestamp information binding, just like in the RTCP Sender Report. This is information that a MDD may need to perform its work efficiently, especially when functioning as an media switching mixer. The information could be end-to-end authenticated to prevent the MDD from intefering with it, and if included by an originating endpoint it can be assumed that it is intended for any current receiver of this RTP stream. The information does not appear to be sensitive from a confidentiality perspective.

3.11.4. Client to Mixer Audio Level

The Client-to-Mixer Audio Level Indication [RFC6464] is very interesting and problematic header extension. It contains the audio level of the audio included in the RTP packet. If that information is provided frequently enough is may provide an attacker of good possibilities as of deducing what is being said [RFC6562]. It is also is important meta data needed by an MDD if it is to perform the RTP stream switching based on who is talking.

This header may require end-to-end confidentiality, this is for cases where the meta data is inteded for the receiving endpoints only, and not the MDDs. In cases of cascaded MDDs it could potentially be of interest to have authentication of the origin, but with a method that the MDDs could verify, and which would allow the final MDD before a receiving endpoint to remove the header extension.

The header shall be hop-by-hop confidentiality protected and authenticated.

3.11.5. Mixer-to-client audio level

Mixer-to-Client Audio Level Indication [RFC6465] is an providing audio levels for individual contributing sources within an audio mix. As the PERC system does not support content mixing, this header does not appear relevant.

3.11.6. Coordination of video orientation (CVO)

The Coordination of video orientation (CVO) [3GPP TS 26.114, version 12.5.0] provides a receiver with meta data about a video stream indicating which direction in the video is "up". Thus enabling the receiving endpoint to display the video content correctly oriented.

This information is meta data about the media content itself. It does not appear to be information required by an MDD for its task. Changing the video orientation may in some cases completely change the meaning, e.g. a hand doing sign language. Therefore, this information should be end-to-end confidentiality protected as well as authenticated. Hop-by-hop authentication is recommended and confidentiality as well if not applied end-to-end.

3.11.7. Region-of-interest (ROI)

Region-of-interest (ROI) [3GPP TS 26.114, version 13.1.0] is an header extension providing the receiving endpoint information that the video image it receives is a covering a particular sub-area of what is originally captured. There exist other protocol mechanism to select the region of interest.

This information is meta data about the media content itself. It does not appear to be information required by an MDD for its task. Therefore this information should be end-to-end confidentiality protected as well as authenticated. Hop-by-hop authentication is recommended and confidentiality as well if not applied end-to-end.

3.11.8. SDES Information

The SDES header extension is defined in [I-D.ietf-avtext-sdes-hdr-ext] and provides SDES CNAME and MID [I-D.ietf-mmusic-sdp-bundle-negotiation] information associated with the originating SSRC.

The privacy sensitve nature of the CNAME is dependent of how it is generated. If generated with privacy in mind [RFC7022] then it will not need to be end-to-end confientiality protected. If not it may require end-to-end confidentiality. The MID values are references into SDP media descriptions and are not expected to be sensitive. This information is provided by the originating endpoint, and being able to trust it is highly valuabel, thus it should be end-to-end authenticated, and preferably also be possible to validate by the MDD.

The hop-by-hop should be authenticated to avoid wasting resources, and the hop-by-hop confiendiality reduces the tracking possibilities by third parties.

3.12. Payload

The payload is the payload format with the media content that is to be confidentiality protected end-to-end. Thus, the MDD shall not be able to modify it. It needs to be end-to-end confidentiality protected and authenticated. The payload should be hop-by-hop authenticated to prevent wasting downstream resources by forwarding a corrupt or modified payload. Hop-by-hop confidentiality is not strictly needed as it will be protected end-to-end. However, to help prevent tracking of how particular payloads are forwarded, it could be confidentiality protected also hop-by-hop.

3.13. Padding Octets

The padding octets that come after the regular payload are often used to hide payload length variations when that is sensitive and could lead to breach of the confidentiality of the content. Thus, it important that the amount of padding can't be determined by either the MDD or any third party. Thus, end-to-end confidentiality and authentication is necessary. Hop-by-hop authentication is recommended to prevent wasting resources on corrupt or modified padding. Hop-by-hop confidentiality is not necessary due to the end-to-end one, but would reduce tracking possibilities.

4. Summery

The following table summarizes the information from the previous section. Legend:

Something is required to be done, or in the case of MDD modification need to be possible.
Something that is not to be done, nor needs to be done.
Recommened to be done but not required.
It can be done, but neither recommened or required (Yes).
Please see description in the section for specific considerations.
Classification is more uncertain and need further input.
Summary of Handling Required
Data MDD Mod Orig Needed E2E Auth E2E Conf HBH Auth HBH Conf
V No No No No Yes May
P No Yes Yes May? Yes Rec
X Yes No No No Yes Rec
CC Yes No No No Yes Rec
M No Yes Yes Rec? Yes Yes
PT Yes Yes? Rec? No* Yes Rec
Seq No Yes Yes* Yes No Yes Rec
Timestamp Yes Yes? Yes? No Yes Rec
SSRC May Yes* Yes* No Yes Rec
CSRCs Yes Yes* Yes* No Yes Rec
Extensions Yes Some? Some? Some? Yes Some
Payload No Yes Yes Yes Yes May?
Padding No Yes Yes Yes Yes May?

5. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

6. Security Considerations

The purpose of this document include discussing the security issue around the information in the RTP header. That is covered above in the document. Worth noting is the differences in recommendation for hop-by-hop confidentiality compared to regular SRTP. Where SRTP for allowing third party monitors as well as enabling the use of IP/UDP/RTP header compressors the RTP header information is in clear text and only integrity protected.

With the increased privacy concerns [RFC6973][RFC7258] and known attacks based on payload length analys, it has become more important to consider confidentiality protect the whole RTP header, but specifically the X, CC, M, PT fields as they reveal important information around the payload and its length. Based on this I recommend that we not only consider SRTP as outer security layer to provide hop-by-hop confidentiality and integrity protection, but also methods that protect the whole RTP packet, like DTLS.

7. Contributors

Cullen Jennings contributed the initial version of the summary table.

8. Acknowledgements

The author like to thank John Mattsson for review comments.

9. Informative References

[I-D.ietf-avtcore-rtp-topologies-update] Westerlund, M. and S. Wenger, "RTP Topologies", Internet-Draft draft-ietf-avtcore-rtp-topologies-update-10, July 2015.
[I-D.ietf-avtext-sdes-hdr-ext] Westerlund, M., Burman, B., Even, R. and M. Zanaty, "RTP Header Extension for RTCP Source Description Items", Internet-Draft draft-ietf-avtext-sdes-hdr-ext-02, July 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H. and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Internet-Draft draft-ietf-mmusic-sdp-bundle-negotiation-23, July 2015.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, DOI 10.17487/RFC5484, March 2009.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010.
[RFC6464] Lennox, J., Ivov, E. and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011.
[RFC6465] Ivov, E., Marocco, E. and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013.
[RFC7022] Begen, A., Perkins, C., Wing, D. and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014.

Author's Address

Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Stockholm, Sweden Phone: +46 10 714 82 87 EMail: