draft-westerlund-avtcore-transport-multiplexing-03.txt   draft-westerlund-avtcore-transport-multiplexing-04.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track C. Perkins Intended status: Standards Track C. Perkins
Expires: January 14, 2013 University of Glasgow Expires: April 25, 2013 University of Glasgow
July 13, 2012 October 22, 2012
Multiple RTP Sessions on a Single Lower-Layer Transport Multiple RTP Sessions on a Single Lower-Layer Transport
draft-westerlund-avtcore-transport-multiplexing-03 draft-westerlund-avtcore-transport-multiplexing-04
Abstract Abstract
This document specifies how multiple RTP sessions are to be This document specifies how multiple RTP sessions are to be
multiplexed on the same lower-layer transport, e.g. a UDP flow. It multiplexed on the same lower-layer transport, e.g. a UDP flow. It
discusses various requirements that have been raised and their discusses various requirements that have been raised and their
feasibility, which results in a solution with a certain feasibility, which results in a solution with a certain
applicability. A solution is recommended and that solution is applicability. A solution is recommended and that solution is
provided in more detail, including signalling and examples. provided in more detail, including signalling and examples.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 7 4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 7
4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 8 4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 8
4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 9 4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 9
4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9 4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9
4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 9 4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 9
4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 10 4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 10
4.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 4.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 10
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10
5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . . 10 5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . . 10
5.2. Signalling Fallback . . . . . . . . . . . . . . . . . . . 12 5.2. ICE and DTLS-SRTP Integration . . . . . . . . . . . . . . 12
5.3. Signalling Fallback . . . . . . . . . . . . . . . . . . . 12
6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 17 6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 18
6.3.1. Security Description . . . . . . . . . . . . . . . . . 18 6.3.1. Security Description . . . . . . . . . . . . . . . . . 19
6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 18 6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 19
6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 19 6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 20
6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 19 6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 21
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informational References . . . . . . . . . . . . . . . . . 26 11.2. Informational References . . . . . . . . . . . . . . . . . 27
Appendix A. Possible Solutions . . . . . . . . . . . . . . . . . 27 Appendix A. Possible Solutions . . . . . . . . . . . . . . . . . 29
A.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 27 A.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 29
A.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 29 A.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 30
A.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 29 A.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 31
A.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 31 A.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 32
A.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 31 A.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 33
A.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 32 A.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 33
Appendix B. Comparison . . . . . . . . . . . . . . . . . . . . . 33 Appendix B. Comparison . . . . . . . . . . . . . . . . . . . . . 34
B.1. Support of Multiple RTP Sessions Over Single Transport . . 33 B.1. Support of Multiple RTP Sessions Over Single Transport . . 34
B.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 33 B.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 34
B.2.1. Avoid SSRC Translation in Gateways/Translation . . . . 33 B.2.1. Avoid SSRC Translation in Gateways/Translation . . . . 34
B.2.2. Support Existing Extensions . . . . . . . . . . . . . 33 B.2.2. Support Existing Extensions . . . . . . . . . . . . . 35
B.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 34 B.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 35
B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 34 B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 36
B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 35 B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 37
B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 37 B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 38
B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 37 B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 39
B.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 38 B.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 39
B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 39 B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
There has been renewed interest for having a solution that allows There has been renewed interest for having a solution that allows
multiple RTP sessions [RFC3550] to use a single lower layer multiple RTP sessions [RFC3550] to use a single lower layer
transport, such as a bi-directional UDP flow. The main reason is the transport, such as a bi-directional UDP flow. The main reason is the
cost of doing NAT/FW traversal for each individual flow. ICE and cost of doing NAT/FW traversal for each individual flow. ICE and
other NAT/FW traversal solutions are clearly capable of attempting to other NAT/FW traversal solutions are clearly capable of attempting to
open multiple flows. However, there is both increased risk for open multiple flows. However, there is both increased risk for
failure and an increased cost in the creation of multiple flows. The failure and an increased cost in the creation of multiple flows. The
increased cost comes as slightly higher delay in establishing the increased cost comes as slightly higher delay in establishing the
traversal, and the amount of consumed NAT/FW resources. The latter traversal, and the amount of consumed NAT/FW resources. The latter
might be an increasing problem in the IPv4 to IPv6 transition period. might be an increasing problem in the IPv4 to IPv6 transition period.
There is ongoing work on specifying how and when one RTP session may There is ongoing work on specifying how and when one RTP session may
contain multiple media types contain multiple media types
[I-D.westerlund-avtcore-multi-media-rtp-session]. That addresses [I-D.ietf-avtcore-multi-media-rtp-session]. That addresses certain
certain use cases, while this proposal addresses a different set of use cases, while this proposal addresses a different set of use cases
use cases and motivations. This is further discussed in the section and motivations. This is further discussed in the section on
on Motivations (Section 3). The classical method of having one RTP Motivations (Section 3). The classical method of having one RTP
session over a specific transport flow is still motivated for a session over a specific transport flow is still motivated for a
number of use cases, especially when flow based QoS is to be used for number of use cases, especially when flow based QoS is to be used for
some media streams. some media streams.
This document draws up some requirements for consideration on how to This document draws up some requirements for consideration on how to
transport multiple RTP sessions over a single lower-layer transport. transport multiple RTP sessions over a single lower-layer transport.
These requirements will have to be weighted as the combined set of These requirements had to be weighted as the combined set of
requirements result in that no known solution exist that can fulfill requirements result in that no known solution exist that can fulfill
them completely. them completely.
A number of possible solutions where considered and discussed with A number of possible solutions where considered and discussed with
respect to their properties. Based on that, the authors recommends a respect to their properties. Based on that, the authors recommended
shim layer variant as single solution, which is described in more a shim layer variant as single solution, which specified in detail
detail including signalling solution and examples. The proposals and including signalling solution and examples. The other considered
the comparison is available as appendices. proposals and the comparison is available as appendices.
2. Conventions 2. Conventions
2.1. Terminology 2.1. Terminology
Some terminology used in this document. Some terminology used in this document.
Multiplexing: Unless specifically noted, all mentioning of Multiplexing: Unless specifically noted, all mentioning of
multiplexing in this document refer to the multiplexing of multiplexing in this document refer to the multiplexing of
multiple RTP Sessions on the same lower layer transport. It is multiple RTP Sessions on the same lower layer transport. It is
skipping to change at page 5, line 17 skipping to change at page 5, line 17
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Motivations 3. Motivations
This section looks at the motivations why an additional solution is This section looks at the motivations why an additional solution is
needed assuming that you can do both the classical method of having needed assuming that you can do both the classical method of having
one RTP session per transport flow as defined by the RTP one RTP session per transport flow as defined by the RTP
specification [RFC3550] and when you have multiple media types within specification [RFC3550] and when you have multiple media types within
one RTP session [I-D.westerlund-avtcore-multi-media-rtp-session]. one RTP session [I-D.ietf-avtcore-multi-media-rtp-session].
First we look at the motivations why a single transport flow is of
sufficient interest, namely NATs and Firewalls. Then
3.1. NAT and Firewalls 3.1. NAT and Firewalls
The existence of NATs and Firewalls at almost all Internet access has The existence of NATs and Firewalls at almost all Internet access has
had implications on protocols like RTP that were designed to use had implications on protocols like RTP that were designed to use
multiple transport flows. First of all, the NAT/FW traversal multiple transport flows. First of all, the NAT/FW traversal
solution one uses needs to ensure that all these transport flows are solution one uses needs to ensure that all these transport flows are
established. This has three different impacts: established. This has three different impacts:
1. Increased delay to perform the transport flow establishment 1. Increased delay to perform the transport flow establishment
2. The more transport flows, the more state and the more resource 2. The more transport flows, the more state and the more resource
consumption in the NAT and Firewalls. When the resource consumption in the NAT and Firewalls. When the resource
consumption in NAT/FWs reaches their limits, unexpected behaviors consumption in NAT/FWs reaches their limits, unexpected behaviors
usually occur. usually occur. Commonly resulting in service disruptions.
3. More transport flows means a higher risk that some transport flow 3. More transport flows means a higher risk that some transport flow
fails to be established, thus preventing the application to fails to be established, thus preventing the application to
communicate. communicate.
Using fewer transport flows reduces the risk of communication Using fewer transport flows reduces the risk of communication
failure, improved establishment behavior and less load on NAT and failure, improved establishment behavior and less load on NAT and
Firewalls. Firewalls.
3.2. No Transport Level QoS 3.2. No Transport Level QoS
skipping to change at page 6, line 11 skipping to change at page 6, line 10
network treatment of its media packets, independent of whether they network treatment of its media packets, independent of whether they
are audio, video or text. When an application has no such desire, it are audio, video or text. When an application has no such desire, it
doesn't need to provide a transport flow structure that simplifies doesn't need to provide a transport flow structure that simplifies
flow based QoS. flow based QoS.
3.3. Multiple RTP sessions 3.3. Multiple RTP sessions
The usage of multiple RTP sessions allow separation of media streams The usage of multiple RTP sessions allow separation of media streams
that have different usages or purposes in an RTP based application, that have different usages or purposes in an RTP based application,
for example to separate the video of a presenter or most important for example to separate the video of a presenter or most important
current talker from those of the listeners that not all end-points current talker, from those of the listeners that not all end-points
receiver. Also separation for different processing based on media receive. Also separation for different processing based on media
types such as audio and video in end-points and central nodes. Thus types such as audio and video in end-points and central nodes. Thus
providing the node with the knowledge that any SSRC within the providing the node with the knowledge that any SSRC within the
session is supposed to be processed in a similar or same way. session is supposed to be processed in a similar or same way.
For simpler cases, where the streams within each media type need the For simpler cases, where the streams within each media type need the
same processing, it is clearly possible to find other multiplex same processing, it is clearly possible to find other multiplex
solutions, for example based on the Payload Type and the differences solutions, for example based on the Payload Type and the differences
in encoding that the payload type allows to describe. This may in encoding that the payload type allows to describe. This may
anyhow be insufficient when you get into more advanced usages where anyhow be insufficient when you get into more advanced usages where
you have multiple sources of the same media type, but for different you have multiple sources of the same media type, but for different
usages or as alternatives. For example when you have one set of usages or as alternatives. For example when you have one set of
video sources that shows session participants and another set of video sources that shows session participants and another set of
video sources that shares an application or slides, you likely want video sources that shares an application or presentation slides, you
to separate those streams for various reasons such as control, likely want to separate those streams for various reasons such as
prioritization, QoS, methods for robustification, etc. In those control, prioritization, QoS, methods for robustification, etc. In
cases, using the RTP session for separation of properties is a those cases, using the RTP session for separation of properties is a
powerful tool. A tool with properties that need to be preserved when powerful tool. A tool with properties that need to be preserved when
providing a solution for how to use only a single lower-layer providing a solution for how to use only a single lower-layer
transport. transport.
For more discussion of the usage of RTP sessions verses other For more discussion of the usage of RTP sessions verses other
multiplexing we recommend RTP Multiplexing Architecture multiplexing we recommend RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture]. [I-D.westerlund-avtcore-multiplex-architecture].
3.4. Usage of RTP Extensions 3.4. Usage of RTP Extensions
Applications uses different sets of RTP extensions. The solution for Applications uses different sets of RTP extensions. The solution for
multiple media types in one RTP session multiple media types in one RTP session
[I-D.westerlund-avtcore-multi-media-rtp-session] is known to have [I-D.ietf-avtcore-multi-media-rtp-session] is known to have
limitations that prevent the usage of the following RTP mechanisms limitations that prevent the usage of the following RTP mechanisms
and extensions: and extensions:
o XOR FEC (RFC5109) o XOR FEC (RFC5109)
o RTP Retransmission in session mode (RFC4588) o RTP Retransmission in session mode (RFC4588)
o Certain Layered Coding o Certain Layered Coding
A developed solution should minimize the number of RTP/RTCP extension A developed solution should minimize the number of RTP/RTCP extension
skipping to change at page 7, line 16 skipping to change at page 7, line 15
3.5. Incremental Deployment 3.5. Incremental Deployment
In various multi-party communication scenarios deployment can become In various multi-party communication scenarios deployment can become
an issue if all session participants are required to have the an issue if all session participants are required to have the
functionality before enabling its usage. This is especially functionality before enabling its usage. This is especially
difficult in communication scenarios where not all possible difficult in communication scenarios where not all possible
participants and their capabilities are know ahead of establishing participants and their capabilities are know ahead of establishing
the communication session with some sub-set of the participants. At the communication session with some sub-set of the participants. At
least for centralized communication sessions it is desirable to have least for centralized communication sessions it is desirable to have
a solution that enables allows the solution to be used on a single a solution that enables allows the solution to be used on a single
leg without affecting any other leg, nor require advanced leg without affecting any other leg, nor require advanced translation
functionality in any central node. functionality in any central node.
3.6. Summary 3.6. Summary
The center of the motivation is to ensure that the RTP session is a The center of the motivation is to ensure that the RTP session is a
available and usable tool also for applications that has no need for available and usable tool also for applications that has no need for
network level separation of its media streams and wants to reduce its network level separation of its media streams and wants to reduce its
exposure to any NAT or Firewall inconsistencies and minimize the exposure to any NAT or Firewall inconsistencies and minimize the
resource consumption. As a benefit a well designed solution will resource consumption. As a benefit a well designed solution will
enable incremental deployment and minimal limitations in what enable incremental deployment and minimal limitations in what
skipping to change at page 8, line 11 skipping to change at page 8, line 9
maintains a full, separate space of SSRC identifiers (defined maintains a full, separate space of SSRC identifiers (defined
next). The set of participants included in one RTP session next). The set of participants included in one RTP session
consists of those that can receive an SSRC identifier transmitted consists of those that can receive an SSRC identifier transmitted
by any one of the participants either in RTP as the SSRC or a CSRC by any one of the participants either in RTP as the SSRC or a CSRC
(also defined below) or in RTCP." (also defined below) or in RTCP."
4.2. Same SSRC Value in Multiple RTP Sessions 4.2. Same SSRC Value in Multiple RTP Sessions
Two different RTP sessions being multiplexed on the same lower layer Two different RTP sessions being multiplexed on the same lower layer
transport need to be able to use the same SSRC value. This is a transport need to be able to use the same SSRC value. This is a
strong requirement, for two reasons: absolute requirement, for two reasons:
1. To avoid mandating SSRC assignment rules that are coordinated 1. To avoid mandating SSRC assignment rules that are coordinated
between the sessions. If the RTP sessions multiplexed together between the sessions. If the RTP sessions multiplexed together
must have unique SSRC values, then additional code that works must have unique SSRC values, then additional code that works
between RTP Sessions is needed in the implementations. Thus between RTP Sessions is needed in the implementations. Thus
raising the bar for implementing this solution. In addition, if raising the bar for implementing this solution. In addition, if
one gateways between parts of a system using this multiplexing one gateways between parts of a system using this multiplexing
and parts that aren't multiplexing, the part that isn't and parts that aren't multiplexing, the part that isn't
multiplexing must also fulfill the requirements on how SSRC is multiplexing must also fulfill the requirements on how SSRC is
assigned or force the gateway to translate SSRCs. Translating assigned or force the gateway to translate SSRCs. Translating
skipping to change at page 8, line 38 skipping to change at page 8, line 36
* XOR FEC (RFC5109) * XOR FEC (RFC5109)
* RTP Retransmission in session mode (RFC4588) * RTP Retransmission in session mode (RFC4588)
* Certain Layered Coding * Certain Layered Coding
4.3. SRTP 4.3. SRTP
SRTP [RFC3711] is one of the most commonly used security solutions SRTP [RFC3711] is one of the most commonly used security solutions
for RTP. In addition, it is the only one recommended by IETF that is for RTP. In addition, it is the only one defined by IETF that is
integrated into RTP. This integration has several aspects that needs integrated into RTP. This integration has several aspects that needs
to be considered when designing a solution for multiplexing RTP to be considered when designing a solution for multiplexing RTP
sessions on the same lower layer transport. sessions on the same lower layer transport.
Determining Crypto Context: SRTP first of all needs to know which Determining Crypto Context: SRTP first of all needs to know which
session context a received or to-be-sent packet relates to. It session context a received or to-be-sent packet relates to. It
also normally relies on the lower layer transport to identify the also normally relies on the lower layer transport to identify the
session. It uses the MKI, if present, to determine which key set session. It uses the Master Key Indicatior (MKI), if present, to
is to be used. Then the SSRC and sequence number are used by most determine which key set is to be used. Then the SSRC and sequence
crypto suites, including the most common use of AES Counter Mode, number are used by most crypto suites, including the most common
to actually generate the correct cipher stream. use of AES Counter Mode, to actually generate the correct cipher
stream.
Unencrypted Headers: SRTP has chosen to leave the RTP headers and Unencrypted Headers: SRTP has chosen to leave the RTP headers and
the first two 32-bit words of the first RTCP header unencrypted, the first two 32-bit words of the first RTCP header unencrypted,
to allow for both header compression and monitoring to work also to allow for both header compression and monitoring to work also
in the presence of encryption. As these fields are in clear text in the presence of encryption. As these fields are in clear text
they are used in most crypto suites for SRTP to determine how to they are used in most crypto suites for SRTP to determine how to
protect or recover the plain text. protect or recover the plain text.
It is here important to contrast SRTP against a set of other possible It is here important to contrast SRTP against a set of other possible
protection mechanisms. DTLS, TLS, and IPsec are all protecting and protection mechanisms. DTLS, TLS, and IPsec are all protecting and
skipping to change at page 9, line 38 skipping to change at page 9, line 38
Combing the two behaviors in the same session can force the Combing the two behaviors in the same session can force the
deployment of costly and less than perfect translation devices. deployment of costly and less than perfect translation devices.
4.5. Firewall Friendly 4.5. Firewall Friendly
It is desirable that current Firewalls will accept the solutions as It is desirable that current Firewalls will accept the solutions as
normal RTP packets. However, in the authors' opinion we can't let normal RTP packets. However, in the authors' opinion we can't let
the firewall stifle invention and evolution of the protocol. It is the firewall stifle invention and evolution of the protocol. It is
also necessary to be aware that a change that will make most deep also necessary to be aware that a change that will make most deep
inspecting firewall consider the packet as not valid RTP/RTCP will inspecting firewall consider the packet as not valid RTP/RTCP will
have more difficult deployment story. have a more difficult deployment story.
4.6. Monitoring and Reporting 4.6. Monitoring and Reporting
It is desirable that a third party monitor can still operate on the It is desirable that a third party monitor can still operate on the
multiplexed RTP Sessions. It is however likely that they will multiplexed RTP Sessions. It is however likely that they will
require an update to correctly monitor and report on multiplexed RTP require an update to correctly monitor and report on multiplexed RTP
Sessions. Sessions.
Another type of function to consider is packet sniffers and their Another type of function to consider is packet sniffers and their
selector filters. These may be impacted by a change of the fields. selector filters. These may be impacted by a change of the fields.
skipping to change at page 11, line 31 skipping to change at page 11, line 31
RTP sessions using the same SSRC values due to irregular behavior RTP sessions using the same SSRC values due to irregular behavior
of the fields for what the third party believes is one media of the fields for what the third party believes is one media
stream rather than multiple ones. The prefixed will however stream rather than multiple ones. The prefixed will however
maintain the long-term capabilities of such devices assuming they maintain the long-term capabilities of such devices assuming they
can be updated to include the SHIM header as part of the can be updated to include the SHIM header as part of the
classification. classification.
Header Compression: The different header compression techniques that Header Compression: The different header compression techniques that
has been developed compresses IP/UDP/RTP as complete combination. has been developed compresses IP/UDP/RTP as complete combination.
If one instead have a IP/UDP/SHIM/RTP then the compression for the If one instead have a IP/UDP/SHIM/RTP then the compression for the
full set will not work. Instead only IP/UDP header compression full set may not work or poorly. Instead only IP/UDP header
can be applied. Thus a prefix will loose some compression compression is likely to be applied. Thus a prefix will loose
efficiency until compression profiles for IP/UDP/SHIM/RTP has been some compression efficiency until compression profiles for IP/UDP/
developed, implemented and deployed. Postfix don't have that SHIM/RTP has been developed, implemented and deployed. Postfix
issue, but nor can it ever gain anything from header compression don't have that issue, but nor can it ever gain anything from
which an prefixed solution could once an updated profile is header compression which an prefixed solution could once an
deployed. updated profile is deployed. Postfix also will have reduced
efficiency compressing sessions when the same SSRC is used in two
different RTP sessions as the RTP header fields like sequence
number etc will not behave as expected and need frequent explicit
updates.
The question of a prefixed or a postfixed header comes down to a The question of a prefixed or a postfixed header comes down to a
trade-off between long term usability and deployment issues: trade-off between long term usability and deployment issues:
Prefixed: Long term good possibility to adapt any network function Prefixed: Long term good possibility to adapt any network function
that needs to take the SHIM header into account. At the same time that needs to take the SHIM header into account. At the same time
any function that tries to analyze packets and because of that may any function that tries to analyze packets and because of that may
block the packets will be a hinder to deployment. block the packets will be a hinder to deployment.
Postfixed: This solution will likely short term have the best Postfixed: This solution will likely short term have the best
possibilities to deploy successfully. However, long term this possibilities to deploy successfully. However, long term this
choice will likely prevent many network nodes that like to be choice will likely prevent many network nodes that like to be
capable of separating the RTP sessions being multiplexed together capable of separating the RTP sessions being multiplexed together
from successfully doing that. from successfully doing that.
Open Issue: Which should be chosen? The below specification uses After discussion in the WG it has been determined that prefixed is
prefix but that can easily be changed. But appears to be the best the prefered solution.
long term choice without to badly affecting deployability.
5.2. Signalling Fallback 5.2. ICE and DTLS-SRTP Integration
When using ICE [RFC5245] or DTLS-SRTP [RFC5764] or both with RTP
there exist the issue that RTP, STUN [RFC5389] and DTLS-SRTP are
simultanously in use over the same lower layer transport flow, like
UDP. This multiplexing is based on the value of the first byte of
the lower layer transport payload as discussed in Section 5.1.2 of
DTLS-SRTP [RFC5764].
The replacement of a single RTP session with the multiple RTP
sessions idenfied by a SHIM must not be missidentified to be either
STUN or DTLS-SRTP or any other protocol intending to take the
available free code-points in the range 193-255 (Decimal). Thus a
prefixed SHIM must have its first byte have the two first bits set to
10 (Binary). Having the SHIM share the identity of RTP is not an
issue as one must have mutual agreement that the SHIM is used instead
of RTP.
Note: This limits a single byte SHIM to only allow a maximum of 64
RTP sessions over a single transport flow.
5.3. Signalling Fallback
There exist an important aspect in how the SDP signalling functions, There exist an important aspect in how the SDP signalling functions,
especially Offer/Answer [RFC3264]. The initial idea for the especially Offer/Answer [RFC3264]. The initial idea for the
signalling was to build on top of bundle signalling was to build on top of bundle
[I-D.ietf-mmusic-sdp-bundle-negotiation] which in its default [I-D.ietf-mmusic-sdp-bundle-negotiation] which in its default
function negotiate multiple media types over one RTP session function negotiate multiple media types over one RTP session
[I-D.westerlund-avtcore-multi-media-rtp-session]. If the signalling [I-D.ietf-avtcore-multi-media-rtp-session]. If the signalling for
for the solution that main purpose is to enable multiple RTP sessions the solution that main purpose is to enable multiple RTP sessions
results in those cases the peer doesn't support this specification results in those cases the peer doesn't support this specification
the communicating peer can end up in single RTP session if the peer the communicating peer can end up in single RTP session if the peer
supports that. supports that.
We consider it important that in the signalling design that the We consider it important that in the signalling design that the
application developer can decide what type of fallback that will application developer can decide what type of fallback that will
occur. It is also important to consider that one have to signal SHIM occur. It is also important to consider that one have to signal SHIM
based multiplexing of RTP sessions that are in fact of the type with based multiplexing of RTP sessions that are in fact of the type with
multiple media types. Thus the signalling for SHIM must be able to multiple media types. Thus the signalling for SHIM must be able to
describe multiple different scenarios: describe multiple different scenarios:
skipping to change at page 12, line 43 skipping to change at page 13, line 20
media types media types
3. Like 1, but where the peer doesn't support SHIM and the initiator 3. Like 1, but where the peer doesn't support SHIM and the initiator
wants to fallback to independent transports wants to fallback to independent transports
4. Like 2, but where the peer doesn't support SHIM and wants to 4. Like 2, but where the peer doesn't support SHIM and wants to
fallback to multiple BUNDLED sessions over independent fallback to multiple BUNDLED sessions over independent
transports. transports.
In addition it must be possible to have multiple different transports In addition it must be possible to have multiple different transports
where each is a SHIM multiplex. where each is a SHIM multiplex. This is to support decomposed end-
points or cases where certain media traffic is required to go to a
central processing node while others goes directly to a peer.
To enable all of these scenarios we propose a solution where each To enable all of these scenarios we propose a solution where each
indicates SHIM multiplex is indicated as its own grouping attribute indicates SHIM multiplex is indicated as its own grouping attribute
across all media blocks that are included in some form in the across all media blocks that are included in some form in the
multiplex. This resulting in that these media blocks fall under a multiplex. This resulting in that these media blocks fall under a
form of BUNDLE super set. This super set will also have some of form of BUNDLE super set. This super set will also have some of
bundles restrictions on the transport layer, but not on higher layer. bundles restrictions on the transport layer, but not on higher layer.
Which Session ID pair a particular media block is associated is Which Session ID pair a particular media block is associated is
signalled using a SDP attribute (a=session-mux-id) in each media signalled using a SDP attribute (a=session-mux-id) in each media
block. When multiple media block are assigned the same session ID block. When multiple media block are assigned the same session ID
pair, they form a RTP session with multiple media types and have the pair, they form a RTP session with multiple media types and have the
full restriction of bundle between them. full restriction of bundle between them.
The method of fallback is indicated by providing explicit BUNDLE The method of fallback is indicated by providing explicit BUNDLE
grouping in addition to the SHIM when the fallback from SHIM is to grouping in addition to the SHIM when the fallback from SHIM is to
BUNDLE. BUNDLE.
Note: Signalling solution is awaiting resolution of design path for
bundle and will then consider that solution and issues raised.
6. Specification 6. Specification
This section contains the specification of the solution based on a This section contains the specification of the RTP session
SHIM, with the explicit session identifier of the encapsulated multiplexing SHIM, using an explicit session identifier of the
payload. encapsulated payload.
6.1. Shim Layer 6.1. Shim Layer
This solution is based on a shim layer that is inserted in the stack This solution is based on a shim layer that is inserted in the stack
between the regular RTP and RTCP packets and the transport layer between the regular RTP and RTCP packets and the transport layer
being used by the RTP sessions. Thus the layering looks like the being used by the RTP sessions. Thus the layering looks like the
following: following:
+---------------------+ +---------------------+
| RTP / RTCP Packet | | RTP / RTCP Packet |
skipping to change at page 14, line 4 skipping to change at page 14, line 38
+-------------------+ +-------------------+
| S1 | S2 | S3 | S4 | | S1 | S2 | S3 | S4 |
+-------------------+ +-------------------+
| Session ID Layer | | Session ID Layer |
+-------------------+ +-------------------+
| Transport layer | | Transport layer |
+-------------------+ +-------------------+
Figure 1: Multiple RTP Session On Top of Session ID Layer Figure 1: Multiple RTP Session On Top of Session ID Layer
The Session ID layer encapsulates one RTP or RTCP packet from a given The Session ID layer encapsulates one RTP or RTCP packet from a given
RTP session and prefixes a one byte Session ID (SID) field to the RTP session and prefixes the 2-byte Session ID layer to the packet.
packet. Each RTP session being multiplexed on top of a given The Session ID layer is depicted below (Figure 2) and consists of
transport layer is assigned either a single or a pair of unique SID first 2 fixed bit values (10b) followed by a 14 bits unsigned integer
in the range 0-255. The reason for assigning a pair of SIDs to a field with the Session ID (SID) value.
given RTP session are for RTP Sessions that doesn't support 0 1
"Multiplexing RTP Data and Control Packets on a Single Port" 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
[RFC5761] to still be able to use a single 5-tuple. The reasons for +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
supporting this extra functionality is that RTP and RTCP multiplexing |1 0| Session ID (SID) |
based on the payload type/packet type fields enforces certain +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
restrictions on the RTP sessions. These restrictions may not be
acceptable. As this solution does not have these restrictions, Figure 2: Session ID layer
performing RTP and RTCP multiplexing in this way has benefits.
Each RTP session being multiplexed on top of a given transport layer
is assigned either a single or a pair of unique SID in the range
0-16383. The reason for assigning a pair of SIDs to a given RTP
session are for RTP Sessions that doesn't support "Multiplexing RTP
Data and Control Packets on a Single Port" [RFC5761] to still be able
to use a single 5-tuple. The reasons for supporting this extra
functionality is that RTP and RTCP multiplexing based on the payload
type/packet type fields enforces certain restrictions on the RTP
sessions. These restrictions may not be acceptable. As this
solution does not have these restrictions, performing RTP and RTCP
multiplexing in this way has benefits.
Each Session ID value space is scoped by the underlying transport Each Session ID value space is scoped by the underlying transport
protocol. Common transport protocols like UDP, DCCP, TCP, and SCTP protocol. Common transport protocols like UDP [RFC0768], DCCP
can all be scoped by one or more 5-tuple (Transport protocol, source [RFC4340], TCP [RFC0793], and SCTP [RFC4960] can all be scoped by one
address and port, destination address and port). The case of or more 5-tuple (Transport protocol, source address and port,
multiple 5-tuples occur in the case of multi-unicast topologies, also destination address and port). The case of multiple 5-tuples occur
called meshed multiparty RTP sessions or in case any application in the case of multi-unicast topologies, also called meshed
would need more than 128 RTP sessions. multiparty RTP sessions or in case any application would need more
than 8192 RTP sessions.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+ +-------------------------------+
| Session ID | |1 0| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | | |V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | | | timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | | | synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | | | contributing source (CSRC) identifiers | |
| .... | | | .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 15, line 4 skipping to change at page 15, line 49
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | | | | payload ... | |
| | +-------------------------------+ | | | +-------------------------------+ |
| | | RTP padding | RTP pad count | | | | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ | | ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : | | : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+- Encrypted Portion* Authenticated Portion ---+ +- Encrypted Portion* Authenticated Portion ---+
Figure 2: SRTP Packet encapsulated by Session ID Layer
Figure 3: SRTP Packet encapsulated by Session ID Layer
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+ +-------------------------------+
| Session ID | |1 0| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P| RC | PT=SR or RR | length | | |V=2|P| RC | PT=SR or RR | length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SSRC of sender | | | SSRC of sender | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ sender info ~ | | ~ sender info ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 1 ~ | | ~ report block 1 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 2 ~ | | ~ report block 2 ~ |
skipping to change at page 15, line 39 skipping to change at page 16, line 37
| ~ ... ~ | | ~ ... ~ |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| |E| SRTCP index | | | |E| SRTCP index | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTCP MKI (OPTIONAL) ~ | | ~ SRTCP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag : | | : authentication tag : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-- Encrypted Portion Authenticated Portion -----+ +-- Encrypted Portion Authenticated Portion -----+
Figure 3: SRTCP packet encapsulated by Session ID layer Figure 4: SRTCP packet encapsulated by Session ID layer
The processing in a receiver when the Session ID layer is present The processing in a receiver when the Session ID layer is present
will be to will be to
1. Pick up the packet from the lower layer transport 1. Pick up the packet from the lower layer transport
2. Inspect the SID field value 2. Inspect the SID field value
3. Strip the SID field from the packet 3. Strip the SID field from the packet
4. Forward it to the (S)RTP Session context identified by the SID 4. Forward it to the (S)RTP Session context identified by the SID
value value
6.2. Signalling 6.2. Signalling
Note: This section may need updating as the direction of the solution
for Bundle has settled and the impact of the raised issues has been
analyzed.
The use of the Session ID layer needs to be explicitly agreed on The use of the Session ID layer needs to be explicitly agreed on
between the communicating parties. Each RTP Session the application between the communicating parties. Each RTP Session the application
uses must in addition to the regular configuration such as payload uses must in addition to the regular configuration such as payload
types, RTCP extension etc, have both the underlying 5-tuple (source types, RTCP extension etc, have both the underlying 5-tuple (source
address and port, destination address and port, and transport address and port, destination address and port, and transport
protocol) and the Session ID used for the particular RTP session. protocol) and the Session ID used for the particular RTP session.
The signalling requirement is to assign unique Session ID values to The signalling requirement is to assign unique Session ID values to
all RTP Sessions being sent over the same 5-tuple. The same Session all RTP Sessions being sent over the same 5-tuple. The same Session
ID shall be used for an RTP session independently of the traffic ID shall be used for an RTP session independently of the traffic
direction. Note that nothing prevents a multi-media application from direction. Note that nothing prevents a multi-media application from
skipping to change at page 18, line 21 skipping to change at page 19, line 21
Thus the attribute is already associated with a particular media Thus the attribute is already associated with a particular media
description. A media description that also will have an instance of description. A media description that also will have an instance of
the "a=session-mux-id" attribute carrying the SID value/pair used the "a=session-mux-id" attribute carrying the SID value/pair used
with this particular crypto parameters. with this particular crypto parameters.
6.3.2. DTLS-SRTP 6.3.2. DTLS-SRTP
Datagram Transport Layer Security (DTLS) Extension to Establish Keys Datagram Transport Layer Security (DTLS) Extension to Establish Keys
for the Secure Real-time Transport Protocol (SRTP) [RFC5764] is a for the Secure Real-time Transport Protocol (SRTP) [RFC5764] is a
keying mechanism that works on the media plane on the same lower keying mechanism that works on the media plane on the same lower
layer transport that SRTP/SRTCP will be transported over. Thus each layer transport that SRTP/SRTCP will be transported over.
DTLS message must be associated with the SRTP and/or SRTCP flow it is
keying.
The most direct solution is to use the SHIM and the SID context The most direct solution would be to use the SHIM and the SID context
identifier to be applied also on DTLS packets. Thus using the same identifier to be applied also on DTLS packets. Thus using the same
SID that is used with RTP and/or RTCP also for the DTLS message SID that is used with RTP and/or RTCP also for the DTLS message
intended to key that particular SRTP and/or SRTCP flow(s). Thus this intended to key that particular SRTP and/or SRTCP flow(s). This of
behavior doesn't gain you anything in regards to key-management when course requires independent usage of DTLS-SRTP for each RTP session.
using SHIM. In addition it requires changing the layering for DTLS-SRTP as well
as RTP. Thus this behavior doesn't gain you anything in regards to
key-management when using SHIM and have some costs.
Instead we propose that an DTLS-SRTP key-derivation change is
introduced. By including the Session ID value in the derivation of
the keying material a single DTLS-SRTP key-management operation could
apply keys and parameters for all the RTP sessions in the same
transport flow. Thus the keying cost is significantly reduced,
especially in regards to network communication and delay impact and
vunerability to packet loss.
Details to be written up.
6.3.3. MIKEY 6.3.3. MIKEY
MIKEY: Multimedia Internet KEYing [RFC3830] is a key management MIKEY: Multimedia Internet KEYing [RFC3830] is a key management
protocol that has several transports. In some cases it is used protocol that has several transports. In some cases it is used
directly on a transport protocol such as UDP, but there is also a directly on a transport protocol such as UDP, but there is also a
specification for how MIKEY is used with SDP "Key Management specification for how MIKEY is used with SDP "Key Management
Extensions for Session Description Protocol (SDP) and Real Time Extensions for Session Description Protocol (SDP) and Real Time
Streaming Protocol (RTSP)" [RFC4567]. Streaming Protocol (RTSP)" [RFC4567].
skipping to change at page 19, line 19 skipping to change at page 20, line 25
The below figure contains an RTP packet with SID field encapsulated The below figure contains an RTP packet with SID field encapsulated
by a UDP packet (added UDP header). by a UDP packet (added UDP header).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | |1 0| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | | |V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | | | timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | | | synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | | | contributing source (CSRC) identifiers | |
| .... | | | .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 25, line 4 skipping to change at page 26, line 4
contains a list of open issues where the author desires some input. contains a list of open issues where the author desires some input.
1. In Section 6.2 there is a discussion of which parameters that 1. In Section 6.2 there is a discussion of which parameters that
must be configured. The scope of these rules and if they do make must be configured. The scope of these rules and if they do make
sense needs additional discussion. sense needs additional discussion.
2. Can we provide better control so that applications that doesn't 2. Can we provide better control so that applications that doesn't
desire fallback to single RTP session when Multiplexing shim desire fallback to single RTP session when Multiplexing shim
fails to be supported but Bundle is supported ends up with a fails to be supported but Bundle is supported ends up with a
better alternative? better alternative?
3. Is there any issues with using DTLS-SRTP individually per RTP 3. The details for how to do key-derivation, preferably in such a
session? way that it can be reused by multiple key-management solutions
like MIKEY and DTLS-SRTP
4. Shall the SHIM header be prefixed or postfixed in relation to the 4. The signalling solution will be revisited when the BUNDLE
RTP/RTCP packets? solution discussion has yeild some result.
8. IANA Considerations 8. IANA Considerations
This document request the registration of one SDP attribute. Details This document request the registration of one SDP attribute. Details
of the registration to be filled in. of the registration to be filled in.
9. Security Considerations 9. Security Considerations
The security properties of the Session ID layer is depending on what The security properties of the Session ID layer is depending on what
mechanism is used to protect the RTP and RTCP packets of a given RTP mechanism is used to protect the RTP and RTCP packets of a given RTP
skipping to change at page 25, line 38 skipping to change at page 26, line 39
wrong SRTP crypto context. If that retrieval fails, the packet will wrong SRTP crypto context. If that retrieval fails, the packet will
be anyway be discarded. If it is successful, the context will not be anyway be discarded. If it is successful, the context will not
lead to successful verification of the packet. lead to successful verification of the packet.
10. Acknowledgements 10. Acknowledgements
This document is based on the input from various people, especially This document is based on the input from various people, especially
in the context of the RTCWEB discussion of how to use only a single in the context of the RTCWEB discussion of how to use only a single
lower layer transport. The RTP and RTCP packet figures are borrowed lower layer transport. The RTP and RTCP packet figures are borrowed
from RFC3711. The SDP example is extended from the one present in from RFC3711. The SDP example is extended from the one present in
[I-D.ietf-mmusic-sdp-bundle-negotiation]. The authors would like to [I-D.ietf-mmusic-sdp-bundle-negotiation]. Eric Rescorla contributed
thank Christer Holmberg for assistance in utilizing the BUNDLE the basic idea of optimizing the DTLS-SRTP key-management by
grouping mechanism. modifying the key derivation process.
The proposal in Appendix A.5 is original suggested by Colin Perkins. The proposal in Appendix A.5 is original suggested by Colin Perkins.
The idea in Appendix A.6 is from an Internet Draft The idea in Appendix A.6 is from an Internet Draft
[I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al. [I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al.
The proposal in Appendix A.3 is a result of discussion by a group of The proposal in Appendix A.3 is a result of discussion by a group of
people at IETF meeting #81 in Quebec. people at IETF meeting #81 in Quebec.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
Using Session Description Protocol (SDP) Port Numbers", Using Session Description Protocol (SDP) Port Numbers",
draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in draft-ietf-mmusic-sdp-bundle-negotiation-01 (work in
progress), February 2012. progress), August 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informational References 11.2. Informational References
[I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Multiple
Media Types in an RTP Session",
draft-ietf-avtcore-multi-media-rtp-session-00 (work in
progress), October 2012.
[I-D.lennox-rtcweb-rtp-media-type-mux] [I-D.lennox-rtcweb-rtp-media-type-mux]
Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media
Types In a Single Real-Time Transport Protocol (RTP) Types In a Single Real-Time Transport Protocol (RTP)
Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work
in progress), October 2011. in progress), October 2011.
[I-D.rosenberg-rtcweb-rtpmux] [I-D.rosenberg-rtcweb-rtpmux]
Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M., Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M.,
Rescorla, E., and T. Terriberry, "Multiplexing of Real- Rescorla, E., and T. Terriberry, "Multiplexing of Real-
Time Transport Protocol (RTP) Traffic for Browser based Time Transport Protocol (RTP) Traffic for Browser based
Real-Time Communications (RTC)", Real-Time Communications (RTC)",
draft-rosenberg-rtcweb-rtpmux-00 (work in progress), draft-rosenberg-rtcweb-rtpmux-00 (work in progress),
July 2011. July 2011.
[I-D.westerlund-avtcore-multi-media-rtp-session] [I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Perkins, C., and J. Lennox, "Multiple Westerlund, M., Burman, B., Perkins, C., and H.
Media Types in an RTP Session",
draft-westerlund-avtcore-multi-media-rtp-session-00 (work Alvestrand, "Guidelines for using the Multiplexing
Features of RTP",
draft-westerlund-avtcore-multiplex-architecture-02 (work
in progress), July 2012. in progress), July 2012.
[I-D.westerlund-avtcore-multiplex-architecture] [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
Westerlund, M., Burman, B., and C. Perkins, "RTP August 1980.
Multiplexing Architecture",
draft-westerlund-avtcore-multiplex-architecture-01 (work [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
in progress), March 2012. RFC 793, September 1981.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
Appendix A. Possible Solutions Appendix A. Possible Solutions
This section looks at a few possible solutions and discusses their This section documents the solutions explored when selecting a SHIM
feasibility. based one and discusses their feasibility.
A.1. Header Extension A.1. Header Extension
One proposal is to define an RTP header extension [RFC5285] that One proposal is to define an RTP header extension [RFC5285] that
explicitly enumerates the session identifier in each packet. This explicitly enumerates the session identifier in each packet. This
proposal has some merits regarding RTP, since it uses an existing proposal has some merits regarding RTP, since it uses an existing
extension mechanism; it explicitly enumerates the session allowing extension mechanism; it explicitly enumerates the session allowing
for third parties to associate the packet to a given RTP session; and for third parties to associate the packet to a given RTP session; and
it works with SRTP as currently defined since a header extension is it works with SRTP as currently defined since a header extension is
by default not encrypted, and is thus readable by the receiving stack by default not encrypted, and is thus readable by the receiving stack
skipping to change at page 33, line 10 skipping to change at page 34, line 26
are required. In addition the translator must be part of the are required. In addition the translator must be part of the
security context. security context.
This solution has no per packet overhead. This solution has no per packet overhead.
Appendix B. Comparison Appendix B. Comparison
This section compares the above potential solutions with the This section compares the above potential solutions with the
requirements. Motivations are provided in addition to a high level requirements. Motivations are provided in addition to a high level
metric of successfully, partially and failing to meet requirement. metric of successfully, partially and failing to meet requirement.
In the end a summary table (Figure 4) of the high level value are In the end a summary table (Figure 5) of the high level value are
provided. provided.
B.1. Support of Multiple RTP Sessions Over Single Transport B.1. Support of Multiple RTP Sessions Over Single Transport
This one is easy to determine. Only the single session proposal This one is easy to determine. Only the single session proposal
fails this requirement as it is not at all designed to meet it. The fails this requirement as it is not at all designed to meet it. The
rest fully support this requirement. The main question around this rest fully support this requirement. The main question around this
requirement is how important it is to have as discussed in requirement is how important it is to have as discussed in
Section 4.1. Section 4.1.
skipping to change at page 40, line 19 skipping to change at page 41, line 38
Solution | 1 |2.1|2.2| 3 | 4 | 5 | 6 | 7 | 8 | OH Solution | 1 |2.1|2.2| 3 | 4 | 5 | 6 | 7 | 8 | OH
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
Header Ext. | S | S | P | P | F | P | F | S | P | 8+ Header Ext. | S | S | P | P | F | P | F | S | P | 8+
Multiplex Shim | S | S | S | S | S | P | F | S | S | 1 Multiplex Shim | S | S | S | S | S | P | F | S | S | 1
Single Session | F | F | F | S | S | P | S | S | F | 0 Single Session | F | F | F | S | S | P | S | S | F | 0
SRTP MKI Field | S | S | S | P | F | P | F | S | S | 4 SRTP MKI Field | S | S | S | P | F | P | F | S | S | 4
Padding Field | S | S | S | F | P | P | F | S | P | 2 Padding Field | S | S | S | F | P | P | F | S | P | 2
Redefine SSRC | S | F | F | P | F | P | P | S | S | 0 Redefine SSRC | S | F | F | P | F | P | P | S | S | 0
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
Figure 4: Summary Table of Evaluation (Successfully (S), Partially Figure 5: Summary Table of Evaluation (Successfully (S), Partially
(P) or Fails (F) to meet requirement) (P) or Fails (F) to meet requirement)
Considering these options, the authors would recommend that AVTCORE Considering these options, the authors would recommend that AVTCORE
standardize a solution based on a post or prefixed multiplexing standardize a solution based on a post or prefixed multiplexing
field, i.e. a shim approach combined with the appropriate signalling field, i.e. a shim approach combined with the appropriate signalling
as described in Appendix A.2. as described in Appendix A.2.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
 End of changes. 53 change blocks. 
141 lines changed or deleted 221 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/