idnits 2.17.1 draft-westerlund-avtcore-transport-multiplexing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2011) is 4577 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Intended status: Standards Track October 14, 2011 5 Expires: April 16, 2012 7 Multiple RTP Session on a Single Lower-Layer Transport 8 draft-westerlund-avtcore-transport-multiplexing-00 10 Abstract 12 This document specifies how multiple RTP sessions are to be 13 multiplexed on the same lower-layer transport, e.g. a UDP flow. It 14 discusses various requirements that have been raised and their 15 feasibility, which results in a solution with a certain 16 applicability. A solution is recommended and that solution is 17 provided in more detail, including signalling and examples. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 16, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 4 59 3.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 4 60 3.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 6 62 3.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 6 63 3.6. Monitioring and Reporting . . . . . . . . . . . . . . . . 6 64 3.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 6 65 3.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 6 66 4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 8 69 4.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 9 71 4.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 10 72 4.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 10 73 5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 11 74 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 15 77 6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 16 78 6.3.1. Security Description . . . . . . . . . . . . . . . . . 16 79 6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 17 80 6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 17 83 6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 18 84 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 90 11.2. Informational References . . . . . . . . . . . . . . . . . 22 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 There has been renewed interest for having a solution that allows 96 multiple RTP sessions [RFC3550] to use a single lower layer 97 transport, such as a bi-directional UDP flow. The main reason is the 98 cost of doing NAT/FW traversal for each individual flow. ICE and 99 other NAT/FW traversal solutions are clearly capable of attempting to 100 open multiple flows. However, there is both increased risk for 101 failure and an increased cost in the creation of multiple flows. The 102 increased cost comes as slightly higher delay in establishing the 103 traversal, and the amount of consumed NAT/FW resources. The latter 104 might be an increasing problem in the IPv4 to IPv6 transition period. 106 This document draws up some requirements for consideration on how to 107 transport multiple RTP sessions over a single lower-layer transport. 108 These requirements will have to be weighted as the combined set of 109 requirements result in that no known solution exist that can fulfill 110 them completely. 112 A number of possible solutions are then considered and discussed with 113 respect to their properties. Based on that, the author recommends a 114 shim layer variant as single solution, which is described in more 115 detail including signalling solution and examples. 117 2. Conventions 119 2.1. Terminology 121 Some terminology used in this document. 123 Multiplexing: Unless specifically noted, all mentioning of 124 multiplexing in this document refer to the multiplexing of 125 multiple RTP Sessions on the same lower layer transport. It is 126 important to make this distinction as RTP does contain a number of 127 multiplexing points for various purposes, such as media formats 128 (Payload Type), media sources (SSRC), and RTP sessions. 130 2.2. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 3. Requirements 138 This section lists and discusses a number of potential requirements. 140 However, it is not difficult to realize that it is in fact possible 141 to put requirements that makes the set of feasible solutions an empty 142 set. It is thus necessary to consider which requirements that are 143 essential to fulfill and which can be compromised on to arrive at a 144 solution. 146 3.1. Support Use of Multiple RTP Sessions 148 This may at first glance appear to be an obvious requirement. 149 Although the authors are convinced it is a mandatory requirement for 150 a solution, it warrants some discussion around the implications of 151 not having multiple RTP sessions and instead use a single RTP 152 session. 154 The main purpose of RTP sessions is to allow separation of streams 155 that have different purposes, for example different media types. A 156 big reason for establishing this is the knowledge that any SSRC 157 within the session is supposed to be processed in a similar way. 159 For simpler cases, where the streams within each media type need the 160 same processing, it is clearly possible to find other multiplex 161 solutions, for example based on the Payload Type and the differences 162 in encoding that allows to describe. This may anyhow be insufficient 163 when you get into more advanced usages where you have multiple 164 sources of the same media type, but for different purposes or as 165 alternatives. For example when you have one set of video sources 166 that shows session participants and another set of video sources that 167 shares an application or slides, you likely want to separate those 168 streams for various reasons such as control, prioritization, QoS, 169 methods for robustification, etc. In those cases, using the RTP 170 session for separation of properties is a powerful tool. A tool with 171 properties that need to be preserved when providing a solution for 172 how to use only a single lower-layer transport. 174 3.2. Same SSRC Value in Multiple RTP Sessions 176 Two different RTP sessions being multiplexed on the same lower layer 177 transport need to be able to use the same SSRC value. This is a 178 strong requirement, for two reasons: 180 1. To avoid mandating SSRC assignment rules that are coordinated 181 between the sessions. If the RTP sessions multiplexed together 182 must have unique SSRC values, then additional code that works 183 between RTP Sessions is needed in the implementations. Thus 184 raising the bar for implementing this solution. In addition, if 185 one gateways between parts of a system using this multiplexing 186 and parts that aren't multiplexing, the part that isn't 187 multiplexing must also fulfil the requirements on how SSRC is 188 assigned or force the gateway to translate SSRCs. Translating 189 SSRC is actually hard as it requires one to understand the 190 semantics of all current and future RTP and RTCP extensions. 191 Otherwise a barrier for deploying new extensions is created. 193 2. There are some few RTP extensions that currently rely on being 194 able to use the same SSRC in different RTP sessions: 196 * XOR FEC (RFC5109) 198 * RTP Retransmission in session mode (RFC4588) 200 * Certain Layered Coding 202 3.3. SRTP 204 SRTP [RFC3711] is one of the most commonly used security solutions 205 for RTP. In addition, it is the only one recommended by IETF that is 206 integrated into RTP. This integration has several aspects that needs 207 to be considered when designing a solution for multiplexing RTP 208 sessions on the same lower layer transport. 210 Determing Crypto Context: SRTP first of all needs to know which 211 session context a received or to-be-sent packet relates to. It 212 also normally relies on the lower layer transport to identify the 213 session. It uses the MKI, if present, to determine which key set 214 is to be used. Then the SSRC and sequence number are used by most 215 crypto suites, including the most common use of AES Counter Mode, 216 to actually generate the correct cipher stream. 218 Unencrypted Headers: SRTP has chosen to leave the RTP headers and 219 the first two 32-bit words of the first RTCP header unencrypted, 220 to allow for both header compression and monitoring to work also 221 in the presence of encryption. As these fields are in clear text 222 they are used in most crypto suites for SRTP to determine how to 223 protect or recover the plain text. 225 It is here important to contrast SRTP against a set of other possible 226 protection mechanisms. DTLS, TLS, and IPsec are all protecting and 227 encapsulating the entire RTP and RTCP packets. They don't perform 228 any partial operations on the RTP and RTCP packets. Any change that 229 is considered to be part of the RTP and RTCP packet is transparent to 230 them, but possibly not to SRTP. Thus the impact on SRTP operations 231 must be considered when defining a mechanism. 233 3.4. Don't Redefine Used Bits 235 As the core of RTP is in use in many systems and has a really large 236 deployment story and numerous implementations, changing any of the 237 field definitions is highly problematic. First of all, the 238 implementations need to change to support this new semantics. 239 Secondly, you get a large transition issue when you have some session 240 participants that support the new semantics and some that don't. 241 Combing the two behaviors in the same session can force the 242 deployment of costly and less than perfect translation devices. 244 3.5. Firewall Friendly 246 It is desirable that current firewalls will accept the solutions as 247 normal RTP packets. However, in the author's opinion we can't let 248 the firewall stifle invention and evolution of the protocol. It is 249 also necessary to be aware that a change that will make most deep 250 inspecting firewall consider the packet as not valid RTP/RTCP will 251 have more difficult deployment story. 253 3.6. Monitioring and Reporting 255 It is strongly desirable that a third party monitor can still operate 256 on the multiplexed RTP Sessions. It is however likely that they will 257 require an update to correctly monitor and report on multiplexed RTP 258 Sessions. 260 Another type of function to consider is packet sniffers and their 261 selector filters. These may be impacted by a change of the fields. 262 An observation is that many such systems are usually quite rapidly 263 updated to consider new types of standardized or simply common packet 264 formats. 266 3.7. Usable Also Over Multicast 268 It is desirable that a solution should be possible to use also when 269 RTP and RTCP packets are sent over multicast, both Any Source 270 Multicast (ASM) and Single Source Multicast (SSM). The reason for 271 this requirement is to allow a system using RTP to use the same 272 configuration regardless of the transport being done over unicast or 273 multicast. In addition, multicast can't be claimed to have an issue 274 with using multiple ports, as each multicast group has a complete 275 port space scoped by address. 277 3.8. Incremental Deployment 279 A good solution has the property that in topologies that contains RTP 280 mixers or Translators, a single session participant can enable 281 multiplexing without having any impact on any other session 282 participants. Thus a node should be able to take a multiplexed 283 packet and then easily send it out with minimal or no modification on 284 another leg of the session, where each RTP session is transported 285 over its own lower-layer transport. It should also be as easy to do 286 the reverse forwarding operation. 288 4. Possible Solutions 290 This section looks at a few possible solutions and discusses their 291 feasibility. 293 4.1. Header Extension 295 The proposal is to define an RTP header extension [RFC5285] that 296 explicitly enumerates the session identifier in each packet. This 297 proposal has definite merits regarding RTP. It uses an existing 298 extension mechanism, it explicitly enumerates the session allowing 299 for third parties to associate the packet to a given RTP session. It 300 works with SRTP as currently defined since a header extension is by 301 default not encrypted and thus readable by the receiving stack 302 without needing to guess which session it belongs to and attempt to 303 decrypt it. 305 If the session ID on the contrary would be in the integrity protected 306 part of the packet, a translator between multiplexed and non- 307 multiplexed has the options: 309 1. to be part of the security context to verify the field 311 2. to be part of the security context to verify the field and remove 312 it before forwarding the packet 314 3. to be outside of the security context and leave the header 315 extension in the packet. However, that requires successful 316 negotiation of the header extension, but not of the 317 functionality, with the receiving end-points. 319 The biggest existing hurdle for this solution is that there exist no 320 header extension field in the RTCP packets. This requires defining a 321 solution for RTCP that allows carrying the explicit indicator, 322 preferably in a position that isn't encrypted by SRTCP. However, the 323 current SRTCP definition does not offer such a position in the 324 packet. 326 Modifying the RR or SR packets is possible using profile specific 327 extensions. However, that has issues when it comes to deployability 328 and in addition any information placed there would end up in the 329 encrypted part. 331 Another alternative could be to define another RTCP packet type that 332 only contains the common header, using the 5 bits in the first byte 333 of the common header to carry a session id. That would allow SRTCP 334 to work correctly as long it accepts this new packet type being the 335 first in the packet. Allowing a non-SR/RR packet as the first packet 336 in a compound RTCP packet is also needed if an implementation is to 337 support Reduced Size RTCP packets [RFC5506]. The remaining downside 338 with this is that all stack implementations supporting multiplexing 339 would need to modify its RTCP compound packet rules to include this 340 packet type first. Thus a translator box between supporting nodes 341 and non-supporting nodes needs to be in the crypto context. 343 This solution's per packet overhead is expected to be 64-bits for 344 RTCP. For RTP it is 64-bits if no header extension was otherwise 345 used, and an additional 16 bits (short header), or 24 bits plus (if 346 needed) padding to next 32-bits boundary if other header extensions 347 are used. 349 4.2. Multiplexing Shim 351 This proposal is to prefix or postfix all RTP and RTCP packets with a 352 session ID field. This field would be outside of the normal RTP and 353 RTCP packets, thus having no impact on the RTP and RTCP packets and 354 their processing. An additional step of demultiplexing processing 355 would be added prior to RTP stack processing to determine in which 356 RTP session context the packet shall be included. This has also no 357 impact on SRTP/SRTCP as the shim layer would be outside of its 358 protection context. The shim layer's session ID is however 359 implicitly integrity protected as any error in the field will result 360 in the packet being placed in the wrong or non-existing context, thus 361 resulting in a integrity failure if processed by SRTP/SRTCP. 363 This proposal is quite simple to implement in any gateway or 364 translating device that goes from a multiplexed to a non-multiplexed 365 domain or vice versa, as only an additional field needs to be added 366 to or removed from the packet. 368 The main downside of this proposal is that it is very likely to 369 trigger a firewall response from any deep packet inspection device. 370 If the field is prefixed, the RTP fields are not matching the 371 heuristics field, thus likely preventing classification of the packet 372 as an RTP packet. If it is postfixed, it is likely classified as an 373 RTP packet but will not correctly validate if the content validation 374 is such that the payload length is expected to match certain values. 376 This solution's per packet overhead is 1 byte. 378 4.3. Single Session 380 One way of trying to avoid multiplexing multiple RTP sessions on a 381 single lower layer transport is to use only a single RTP session, 382 including multiple media types such as both audio and video. This 383 does have a number of implications, the first of which is the 384 complete loss of RTP session as a separator for different type of 385 streams. 387 Lacking different RTP sessions, a node will have to dig deeper into 388 the packet before determining what to do with it. Care must be taken 389 in that inspection. For example, you must be careful to ensure that 390 each real media source uses its own SSRC in the session and that this 391 SSRC doesn't change media type. 393 The loss of purpose separator is likely not a big issue if the only 394 difference between RTP Sessions are the media type. This as you can 395 use the Payload Type to identify the media type. The loss of the RTP 396 Session functionality is more severe if you actually use the RTP 397 Session for separating different treatments, contexts etc. Then you 398 would need additional signalling to bind the different sources to 399 groups which can help make the necessary distinctions. 401 This method has several limitations that makes it unsuitable as 402 general mechanism to provide multiple RTP sessions on the same lower 403 layer transport. However, we acknowledge that there are some uses 404 for which this method may be sufficient and which can accept the 405 method limitations and other downsides. The RTCWEB WG has a working 406 assumption to support this method. For more details of this method, 407 see the relevant drafts under development. 409 This solution has no per packet overhead. The signalling overhead 410 will be a different question. 412 4.4. Use the SRTP MKI field 414 This proposal is to overload the MKI SRTP/SRTCP identifier to not 415 only identify a particular crypto context, but also identify the 416 actual RTP Session. This clearly is a miss use of the MKI field, 417 however it appears to be with little negative implications. SRTP 418 already supports handling of multiple crypto contexts. 420 The two major downsides with this proposal is first the fact that it 421 requires using SRTP/SRTCP to multiplex multiple sessions on a single 422 lower layer transport. The second issue is that the session ID 423 parameter needs to be put into the various key-management schemes and 424 to make them understand that the reason to establish multiple crypto 425 contexts is because they are connected to various RTP Sessions. 426 Considering that SRTP have at least 3 used keying mechanisms, DTLS- 427 SRTP [RFC5764], Security Descriptions [RFC4568], and MIKEY [RFC3830], 428 this is not an insignificant amount of work. 430 This solution has 32-bit per packet overhead, but only if the MKI was 431 not already used. 433 4.5. Use an Octet in the Padding 435 The basics of this proposal is to have the RTP packet and the last 436 (required by RFC3550) RTCP packet in a compound to include padding, 437 at least 2 bytes. One byte for the padding count (last byte) and one 438 byte just before the padding count containing the session ID. 440 This proposal uses bytes to carry the session ID that have no defined 441 value and is intended to be ignored by the receiver. From that 442 perspective it only causes packet expansion that is supported and 443 handled by all existing equipment. If an implementation fails to 444 understand that it is required to interpret this padding byte to 445 learn the session ID, it will see a mostly coherent RTP session 446 except where SSRCs overlap or where the payload types overlap. 447 However, reporting on the individual sources or forwarding the RTCP 448 RR are not completely without merit. 450 There is one clear downside of this proposal and that has to do with 451 SRTP. To be able to determine the crypto context, it is necessary to 452 access to the encrypted payload of the packet. Thus, the only 453 mechanism available for a receiver to solve this issue is to try the 454 existing crypto contexts for any session on the same lower layer 455 transport and then use the one where the packet decrypts and verifies 456 correctly. Thus for transport flows with many crypto contexts, an 457 attacker could simply generate packets that don't validate to force 458 the receiver to try all crypto contexts they have rather than 459 immediately discard it as not matching a context. 461 This solution has a 16-bit per packet overhead. 463 4.6. Redefine the SSRC field 465 The Rosenberg et. al. Internet draft "Multiplexing of Real-Time 466 Transport Protocol (RTP) Traffic for Browser based Real-Time 467 Communications (RTC)" [I-D.rosenberg-rtcweb-rtpmux] proposed to 468 redefine the SSRC field. This has the advantage of no packet 469 expansion. It also looks like regular RTP. However, it has a number 470 of implications. First of all it prevents any RTP functionality that 471 require the same SSRC in multiple RTP sessions. 473 Secondly its interoperability with normal RTP is problematic. Such 474 interoperability requires an SSRC translator function in the gateway 475 to ensure that the SSRCs fulfill the requirements of the different 476 domains. That translator is actually far from easy as it needs to 477 understand the semantics of all RTP and RTCP extensions that include 478 SSRC/CSRC. This as it is necessary to know when a particular 479 matching 32-bit pattern is an SSRC field and when the field is just a 480 combination of other fields that create the same matching 32-bit 481 pattern. Thus any future RTCP extension might not work through the 482 translator, causing a barrier for deployment of future extensions. 484 This solution has no per packet overhead. 486 5. Recommendation 488 Considering these options, the authors would recommend that AVTCORE 489 standardize a solution based on a postfixed multiplexing field, i.e. 490 a shim approach combined with the appropriate signalling as described 491 in Section 4.2. 493 6. Specification 495 This section contains the specification of the solution based on a 496 SHIM, with the explicit session identifier at the end of the 497 encapsulated payload. 499 6.1. Shim Layer 501 This solution is based on a shim layer that is inserted in the stack 502 between the regular RTP and RTCP packets and the transport layer 503 being used by the RTP sessions. Thus the layering looks like the 504 following: 506 +---------------------+ 507 | RTP / RTCP Packet | 508 +---------------------+ 509 | Session ID Layer | 510 +---------------------+ 511 | Transport layer | 512 +---------------------+ 514 Stack View with Session ID SHIM 516 The above stack is in fact a layered one as it does allow multiple 517 RTP Sessions to be multiplexed on top of the Session ID shim layer. 518 This enables the example presented in Figure 1 where four sessions, 519 S1-S4 is sent over the same Transport layer and where the Session ID 520 layer will combine and encapsulate them with the session ID on 521 transmission and separate and decapsulate them on reception. 523 +-------------------+ 524 | S1 | S2 | S3 | S4 | 525 +-------------------+ 526 | Session ID Layer | 527 +-------------------+ 528 | Transport layer | 529 +-------------------+ 531 Figure 1: Multiple RTP Session On Top of Session ID Layer 533 The Session ID layer encapsulates one RTP or RTCP packet from a given 534 RTP session and postfixes a one byte Session ID (SID) field to the 535 packet. Each RTP session being multiplexed on top of a given 536 transport layer is assigned either a single or a pair of unique SID 537 in the range 0-255. The reason for assigning a pair of SIDs to a 538 given RTP session are for RTP Sessions that doesn't support 539 "Multiplexing RTP Data and Control Packets on a Single Port" 540 [RFC5761] to still be able to use a single 5-tuple. The reasons for 541 supporting this extra functionality is that RTP and RTCP multiplexing 542 based on the payload type/packet type fields enforces certain 543 restrictions on the RTP sessions. These restrictions may not be 544 acceptable. As this solution does not have these restrictions, 545 performing RTP and RTCP multiplexing in this way has benefits. 547 Each Session ID value space is scoped by the underlying transport 548 protocol. Common transport protocols like UDP, DCCP, TCP, and SCTP 549 can all be scoped by one or more 5-tuple (Transport protocol, source 550 address and port, destination address and port). The case of 551 multiple 5-tuples occur in the case of multi-unicast topologies, also 552 called meshed multiparty RTP sessions. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 557 |V=2|P|X| CC |M| PT | sequence number | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 559 | timestamp | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 561 | synchronization source (SSRC) identifier | | 562 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 563 | contributing source (CSRC) identifiers | | 564 | .... | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 566 | RTP extension (OPTIONAL) | | 567 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 568 | | payload ... | | 569 | | +-------------------------------+ | 570 | | | RTP padding | RTP pad count | | 571 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 572 | ~ SRTP MKI (OPTIONAL) ~ | 573 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 574 | : authentication tag (RECOMMENDED) : | 575 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 576 | | Session ID | | 577 | +---------------+ | 578 +- Encrypted Portion* Authenticated Portion ---+ 580 SRTP Packet encapsulated by Session ID Layer 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 585 |V=2|P| RC | PT=SR or RR | length | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 587 | SSRC of sender | | 588 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 589 | ~ sender info ~ | 590 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 591 | ~ report block 1 ~ | 592 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 593 | ~ report block 2 ~ | 594 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 595 | ~ ... ~ | 596 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 597 | |V=2|P| SC | PT=SDES=202 | length | | 598 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 599 | | SSRC/CSRC_1 | | 600 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 601 | ~ SDES items ~ | 602 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 603 | ~ ... ~ | 604 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 605 | |E| SRTCP index | | 606 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 607 | ~ SRTCP MKI (OPTIONAL) ~ | 608 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 609 | : authentication tag : | 610 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 611 | | Session ID | | 612 | +---------------+ | 613 +-- Encrypted Portion Authenticated Portion -----+ 615 SRTCP packet encapuslated by Session ID layer 617 The processing in a receiver when the Session ID layer is present 618 will be to 620 1. Pick up the packet from the lower layer transport 622 2. Inspect the SID field value 624 3. Strip the SID field from the packet 626 4. Forward it to the (S)RTP Session context identified by the SID 627 value 629 6.2. Signalling 631 The use of the Session ID layer needs to be explicitly agreed on 632 between the communicating parties. Each RTP Session the application 633 uses must in addition to the regular configuration such as payload 634 types, RTCP extension etc, have both the underlying 5-tuple (source 635 address and port, destination address and port, and transport 636 protocol) and the Session ID used for the particular RTP session. 637 The signalling requirement is to assign unique Session ID values to 638 all RTP Sessions being sent over the same 5-tuple. The same Session 639 ID shall be used for an RTP session independently of the traffic 640 direction. Note that nothing prevents a multi-media application from 641 using multiple 5-tuples if desired for some reason, in which case 642 each 5-tuple has its own session ID value space. 644 This section defines how to negotiate the use of the Session ID 645 layer, using the Session Description Protocol (SDP) Offer/Answer 646 mechanism [RFC3264]. A new media-level SDP attribute, 647 'session-mux-id', is defined, in order to be used with the media 648 multiplex mechanism defined in 649 [I-D.holmberg-mmusic-sdp-multiplex-negotiation]. The attribute 650 allows each media description ("m=" line) associated with a 651 'MULTIPLEX' group to form a separate RTP session. 653 The 'session-mux-id' attribute is included for a media description, 654 in order to indicate the Session ID for that particular media 655 description. Every media description that shares a common attribute 656 value is assumed to be part of a single RTP session. An SDP Offerer 657 MUST include the 'session-mux-id' attribute for every media 658 description associated with a 'MULTIPLEX' group. If the SDP Answer 659 does not contain 'session-mux-id' attributes, the SDP Offerer MUST 660 NOT assume that separate RTP sessions will be used. If the SDP 661 Answer still describes a 'MULTIPLEX' group, the procedures in 662 [I-D.holmberg-mmusic-sdp-multiplex-negotiation] apply. 664 An SDP Answerer MUST NOT include the 'session-mux-id' attribute in an 665 SDP Answer, unless included in the SDP Offer. 667 The attribute has the following ABNF [RFC5234] definition. 669 Session-mux-id-attr = "a=session-mux-id:" SID *SID-prop 670 SID = SID-value / SID-pairs 671 SID-value = 1*3DIGIT / "NoN" 672 SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs 673 SID-prop = SP assignment-policy / prop-ext 674 prop-ext = token "=" value 675 assignment-policy = "policy=" ("tentative" / "fixed") 676 The following parameters MUST be configured as specified: 678 o RTP Profile SHOULD be the same, but MUST be compatible, like AVP 679 and AVPF. 681 o RTCP bandwidth parameters are the same 683 o RTP Payload type values are not overlapping 685 In declarative SDP usage, there is clearly no method for fallback 686 unless some other negotiation protocol is used. 688 The SID property "policy" is used in negotiation by an end-point to 689 indicate if the session ID values are merely a tentative suggestion 690 or if they must have these values. This is used when negotiating SID 691 for multi-party RTP sessions to support shared transports such as 692 multicast or RTP translators that are unable to produce renumbered 693 SIDs on a per end-point basis. The normal behavior is that the offer 694 suggest a tentative set of values, indicated by "policy=tentative". 695 These SHOULD be accepted by the peer unless that peer negotiate 696 session IDs on behalf of a centralized policy, in which case it MAY 697 change the value(s) in the answer. If the offer represents a policy 698 that does not allow changing the session ID values, it can indicate 699 that to the answerer by setting the policy to "fixed". This enables 700 the answering peer to either accept the value or indicate that there 701 is a conflict in who is performing the assignment by setting the SID 702 value to NoN (Not a Number). Offerer and answerer SHOULD always 703 include the policy they are operating under. Thus, in case of no 704 centralized behaviors, both offerer and answerer will indicate the 705 tentative policy. 707 6.3. SRTP Key Management 709 Key management for SRTP do needs discussion as we do cause multiple 710 SRTP sessions to exist on the same underlying transport flow. Thus 711 we need to ensure that the key management mechanism still are 712 properly associated with the SRTP session context it intends to key. 713 To ensure that we do look at the three SRTP key management mechanism 714 that IETF has specified, one after another. 716 6.3.1. Security Description 718 Session Description Protocol (SDP) Security Descriptions for Media 719 Streams [RFC4568] as being based on SDP has no issue with the RTP 720 session multiplexing on lower layer specified here. The reason is 721 that the actual keying is done using a media level SDP attribute. 722 Thus the attribute is already associated with a particular media 723 description. A media description that also will have an instance of 724 the "a=session-mux-id" attribute carrying the SID value/pair used 725 with this particular crypto parameters. 727 6.3.2. DTLS-SRTP 729 Datagram Transport Layer Security (DTLS) Extension to Establish Keys 730 for the Secure Real-time Transport Protocol (SRTP) [RFC5764] is a 731 keying mechanism that works on the media plane on the same lower 732 layer transport that SRTP/SRTCP will be transported over. Thus each 733 DTLS message must be associated with the SRTP and/or SRTCP flow it is 734 keying. 736 The most direct solution is to use the SHIM and the SID context 737 identifier to be applied also on DTLS packets. Thus using the same 738 SID that is used with RTP and/or RTCP also for the DTLS message 739 intended to key that particular SRTP and/or SRTCP flow(s). 741 6.3.3. MIKEY 743 MIKEY: Multimedia Internet KEYing [RFC3830] is a key management 744 protocol that has several transports. In some cases it is used 745 directly on a transport protocol such as UDP, but there is also a 746 specification for how MIKEY is used with SDP "Key Management 747 Extensions for Session Description Protocol (SDP) and Real Time 748 Streaming Protocol (RTSP)" [RFC4567]. 750 Lets start with the later, i.e. the SDP transport, which shares the 751 properties with Security Description in that is can be associated 752 with a particular media description in a SDP. As long as one avoids 753 using the session level attribute one can be certain to correctly 754 associate the key exchange with a given SRTP/SRTCP context. 756 It does appear that MIKEY directly over a lower layer transport 757 protocol will have similar issues as DTLS. 759 6.4. Examples 761 6.4.1. RTP Packet with Transport Header 763 The below figure contains an RTP packet with SID field encapsulated 764 by a UDP packet (added UDP header). 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Source Port | Destination Port | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Length | Checksum | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 773 |V=2|P|X| CC |M| PT | sequence number | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 775 | timestamp | | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 777 | synchronization source (SSRC) identifier | | 778 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 779 | contributing source (CSRC) identifiers | | 780 | .... | | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 782 | RTP extension (OPTIONAL) | | 783 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 784 | | payload ... | | 785 | | +-------------------------------+ | 786 | | | RTP padding | RTP pad count | | 787 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 788 | ~ SRTP MKI (OPTIONAL) ~ | 789 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 790 | : authentication tag (RECOMMENDED) : | 791 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 792 | | Session ID | | 793 | +---------------+ | 794 +- Encrypted Portion* Authenticated Portion ---+ 796 SRTP Packet Encapsulated by Session ID Layer 798 6.4.2. SDP Offer/Answer example 800 This section contains SDP offer/answer examples. First one example 801 of successful multiplexing, and then two where fallback occurs. 803 In the below SDP offer, one audio and one video is being offered. 804 The audio is using SID 0, and the video is using SID 1 to indicate 805 that they are different RTP sessions despite being offered over the 806 same 5-tuple. 808 v=0 809 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 810 s= 811 c=IN IP4 atlanta.example.com 812 t=0 0 813 a=group:MULTIPLEX foo bar 814 m=audio 10000 RTP/AVP 0 8 97 815 b=AS:200 816 a=mid:foo 817 a=session-mxu-id:0 policy=suggest 818 a=rtpmap:0 PCMU/8000 819 a=rtpmap:8 PCMA/8000 820 a=rtpmap:97 iLBC/8000 821 m=video 10000 RTP/AVP 31 32 822 b=AS:1000 823 a=mid:bar 824 a=session-mxu-id:1 policy=suggest 825 a=rtpmap:31 H261/90000 826 a=rtpmap:32 MPV/90000 828 The SDP answer from an end-point that supports this multiplexing: 829 v=0 830 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 831 s= 832 c=IN IP4 biloxi.example.com 833 t=0 0 834 a=group:MULTIPLEX foo bar 835 m=audio 20000 RTP/AVP 0 836 b=AS:200 837 a=mid:foo 838 a=session-mux-id:0 policy=suggest 839 a=rtpmap:0 PCMU/8000 840 m=video 20000 RTP/AVP 32 841 b=AS:1000 842 a=mid:bar 843 a=session-mux-id:1 policy=suggest 844 a=rtpmap:32 MPV/90000 846 The SDP answer from an end-point that does not support this 847 multiplexing or the general signalling of 848 [I-D.holmberg-mmusic-sdp-multiplex-negotiation]. 850 v=0 851 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 852 s= 853 c=IN IP4 biloxi.example.com 854 t=0 0 855 m=audio 20000 RTP/AVP 0 856 b=AS:200 857 a=rtpmap:0 PCMU/8000 858 m=video 30000 RTP/AVP 32 859 b=AS:1000 860 a=rtpmap:32 MPV/90000 862 The SDP answer of a client supporting 863 [I-D.holmberg-mmusic-sdp-multiplex-negotiation] but not this 864 multiplexing would look like this: 865 v=0 866 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 867 s= 868 c=IN IP4 biloxi.example.com 869 t=0 0 870 a=group:MULTIPLEX foo bar 871 m=audio 20000 RTP/AVP 0 872 a=mid:foo 873 b=AS:200 874 a=rtpmap:0 PCMU/8000 875 m=video 20000 RTP/AVP 32 876 a=mid:bar 877 b=AS:1000 878 a=rtpmap:32 MPV/90000 880 In this last case, the result is a sing RTP session with both media 881 types being established. If that isn't supported or desired, the 882 offerer will have to either re-invite without the MULTIPLEX grouping 883 to force different 5-tuples, or simply terminate the session. 885 7. Open Issues 887 This is the first version of this draft. It will obviously have a 888 number of open issues. This section contains a list of open issues 889 where the author desires some input. 891 1. Should RTP and RTCP multiplexing without RFC 5761 support be 892 included? 894 8. IANA Considerations 896 This document request the registration of one SDP attribute. Details 897 of the registration to be filled in. 899 9. Security Considerations 901 The security properties of the Session ID layer is depending on what 902 mechanism is used to protect the RTP and RTCP packets of a given RTP 903 session. If IPsec or transport layer security solutions such as DTLS 904 or TLS are being used then both the encapsulated RTP/RTCP packets and 905 the session ID layer will be protected by that security mechanism. 906 Thus potentially providing both confidentiality, integrity and source 907 authentication. If SRTP is used, the session ID layer will not be 908 directly protected by SRTP. However, it will be implicitly integrity 909 protected (assuming the RTP/RTCP packet is integrity protected) as 910 the only function of the field is to identify the session context. 911 Thus any modification of the SID field will attempt to retrieve the 912 wrong SRTP crypto context. If that retrieval fails, the packet will 913 be anyway be discarded. If it is successful, the context will not 914 lead to successful verification of the packet. 916 10. Acknowledgements 918 This document is based on the input from various people, especially 919 in the context of the RTCWEB discussion of how to use only a single 920 lower layer transport. The RTP and RTCP packet figures are borrowed 921 from RFC3711. The SDP example is extended from the one present in 922 [I-D.holmberg-mmusic-sdp-multiplex-negotiation]. The authors would 923 like to thank Christer Holmberg for assistance in utilizing the 924 multiplex grouping mechanism. 926 The proposal in Section 4.5 is original suggested by Colin Perkins. 927 The idea in Section 4.6 is from an Internet Draft 928 [I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al. 929 The proposal in Section 4.3 is a result of discussion by a group of 930 people at IETF meeting #81 in Quebec. 932 11. References 934 11.1. Normative References 936 [I-D.holmberg-mmusic-sdp-multiplex-negotiation] 937 Holmberg, C., "Multiplexing Negotiation Using Session 938 Description Protocol (SDP) Port Numbers", 939 draft-holmberg-mmusic-sdp-multiplex-negotiation-00 (work 940 in progress), September 2011. 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, March 1997. 945 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 946 Jacobson, "RTP: A Transport Protocol for Real-Time 947 Applications", STD 64, RFC 3550, July 2003. 949 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 950 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 951 RFC 3711, March 2004. 953 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 954 Specifications: ABNF", STD 68, RFC 5234, January 2008. 956 11.2. Informational References 958 [I-D.rosenberg-rtcweb-rtpmux] 959 Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M., 960 Rescorla, E., and T. Terriberry, "Multiplexing of Real- 961 Time Transport Protocol (RTP) Traffic for Browser based 962 Real-Time Communications (RTC)", 963 draft-rosenberg-rtcweb-rtpmux-00 (work in progress), 964 July 2011. 966 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 967 with Session Description Protocol (SDP)", RFC 3264, 968 June 2002. 970 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 971 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 972 August 2004. 974 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 975 Carrara, "Key Management Extensions for Session 976 Description Protocol (SDP) and Real Time Streaming 977 Protocol (RTSP)", RFC 4567, July 2006. 979 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 980 Description Protocol (SDP) Security Descriptions for Media 981 Streams", RFC 4568, July 2006. 983 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 984 Header Extensions", RFC 5285, July 2008. 986 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 987 Real-Time Transport Control Protocol (RTCP): Opportunities 988 and Consequences", RFC 5506, April 2009. 990 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 991 Control Packets on a Single Port", RFC 5761, April 2010. 993 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 994 Security (DTLS) Extension to Establish Keys for the Secure 995 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 997 Author's Address 999 Magnus Westerlund 1000 Ericsson 1001 Farogatan 6 1002 SE-164 80 Kista 1003 Sweden 1005 Phone: +46 10 714 82 87 1006 Email: magnus.westerlund@ericsson.com