idnits 2.17.1 draft-ietf-avtext-sdes-hdr-ext-07.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 (June 10, 2016) is 2870 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) == Missing Reference: 'RFCXXXX' is mentioned on line 556, but not defined ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-30 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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 B. Burman 4 Intended status: Standards Track Ericsson 5 Expires: December 12, 2016 R. Even 6 Huawei Technologies 7 M. Zanaty 8 Cisco Systems 9 June 10, 2016 11 RTP Header Extension for RTCP Source Description Items 12 draft-ietf-avtext-sdes-hdr-ext-07 14 Abstract 16 Source Description (SDES) items are normally transported in RTP 17 control protocol (RTCP). In some cases it can be beneficial to speed 18 up the delivery of these items. Mainly when a new source (SSRC) 19 joins an RTP session and the receivers need this source's identity, 20 relation to other sources, or its synchronization context, all of 21 which may be fully or partially identified using SDES items. To 22 enable this optimization, this document specifies a new RTP header 23 extension that can carry SDES items. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 12, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5 66 4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 5 67 4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6 68 4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6 69 4.2.1. One or Two Byte Headers . . . . . . . . . . . . . . . 6 70 4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7 71 4.2.3. Transmission Considerations . . . . . . . . . . . . . 7 72 4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9 73 4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9 74 4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10 75 4.2.7. RTP Header Compression . . . . . . . . . . . . . . . 10 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11 78 5.2. Creation of an SDES Sub-Registry . . . . . . . . . . . . 11 79 5.3. Registration of SDES Item . . . . . . . . . . . . . . . . 12 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 8.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 This specification defines an RTP header extension [RFC3550][RFC5285] 90 that can carry RTCP source description (SDES) items. Normally the 91 SDES items are carried in their own RTCP packet type [RFC3550]. By 92 including selected SDES items in a header extension the determination 93 of relationship and synchronization context for new RTP streams 94 (SSRCs) in an RTP session can be optimized. Which relationship and 95 what information depends on the SDES items carried. This becomes a 96 complement to using only RTCP for SDES Item delivery. 98 It is important to note that not all SDES items are appropriate to 99 transmit using RTP header extensions. Some SDES items performs 100 binding or identifies synchronization context with strict timeliness 101 requirements, while many other SDES items do not have such 102 requirements. In addition, security and privacy concerns for the 103 SDES item information need to be considered. For example, the Name 104 and Location SDES items are highly sensitive from a privacy 105 perspective and should not be transported over the network without 106 strong security. No use case has identified where this information 107 is required at the same time as the first RTP packets arrive. A few 108 seconds delay before such information is available to the receiver 109 appears acceptable. Therefore only appropriate SDES items will be 110 registered for use with this header extension, such as CNAME. 112 First, some requirements language and terminology are defined. The 113 following section motivates why this header extension is sometimes 114 required or at least provides a significant improvement compared to 115 waiting for regular RTCP packet transmissions of the information. 116 This is followed by a specification of the header extension and usage 117 recommendations. Next, a sub-space of the header-extension URN is 118 defined to be used for existing and future SDES items, and then the 119 appropriate existing SDES items are registered. 121 2. Definitions 123 2.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2.2. Terminology 131 This document uses terminology defined in "A Taxonomy of Semantics 132 and Mechanisms for Real-Time Transport Protocol (RTP) Sources" 133 [RFC7656]. In particular the following definitions: 135 Media Source 137 RTP Stream 139 Media Encoder 141 Participant 143 3. Motivation 145 Source Description (SDES) items are associated with a particular SSRC 146 and thus RTP stream. The source description items provide various 147 meta data associated with the SSRC. How important it is to have this 148 data no later than when receiving the first RTP packets depends on 149 the item itself. The CNAME item is one item that is commonly needed 150 either at reception of the first RTP packet for this SSRC, or at 151 least by the time the first media can be played out. If it is not 152 available, the synchronization context cannot be determined and thus 153 any related streams cannot be correctly synchronized. Thus, this is 154 a valuable example for having this information early when a new RTP 155 stream is received. 157 The main reason for new SSRCs in an RTP session is when media sources 158 are added. This can be either because an end-point is adding a new 159 actual media source, or additional participants in a multi-party 160 session are added to the session. Another reason for a new SSRC can 161 be an SSRC collision that forces both colliding parties to select new 162 SSRCs. 164 For the case of rapid media synchronization, one may use the RTP 165 header extension for Rapid Synchronization of RTP Flows [RFC6051]. 166 This header extension carries the clock information present in the 167 RTCP sender report (SR) packets. It however assumes that the CNAME 168 binding is known, which can be provided via signaling [RFC5576] in 169 some cases, but not all. Thus an RTP header extension for carrying 170 SDES items like CNAME is a powerful combination to enable rapid 171 synchronization in all cases. 173 The Rapid Synchronization of RTP Flows specification does provide an 174 analysis of the initial synchronization delay for different sessions 175 depending on number of receivers as well as on session bandwidth 176 (Section 2.1 of [RFC6051]). These results are applicable also for 177 other SDES items that have a similar time dependency until the 178 information can be sent using RTCP. These figures can be used to 179 determine the benefit of reducing the initial delay before 180 information is available for some use cases. 182 Rapid Synchronization of RTP Flows [RFC6051] also discusses the case 183 of late joiners, and defines an RTCP Feedback format to request 184 synchronization information, which is another potential use case for 185 SDES items in RTP header extension. It would for example be natural 186 to include CNAME SDES item with the header extension containing the 187 NTP formatted reference clock to ensure synchronization. 189 The ongoing work on bundling SDP media descriptions 190 [I-D.ietf-mmusic-sdp-bundle-negotiation] has identified a new SDES 191 item that can benefit from timely delivery. A corresponding RTP SDES 192 compact header extension is therefore also defined and registered in 193 that document: 195 MID: This is a media description identifier that matches the value 196 of the Session Description Protocol (SDP) [RFC4566] a=mid 197 attribute [RFC5888], to associate RTP streams multiplexed on the 198 same transport with their respective SDP media description. 200 4. Specification 202 This section first specifies the SDES item RTP header extension 203 format, followed by some usage considerations. 205 4.1. SDES Item Header Extension 207 An RTP header extension scheme allowing for multiple extensions is 208 defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. 209 That specification defines both short and long item headers. The 210 short headers (One-byte) are restricted to 1 to 16 bytes of data, 211 while the long format (Two-byte) supports a data length of 0 to 255 212 bytes. Thus the RTP header extension formats are capable of 213 supporting any SDES item from a data length perspective. 215 The ID field, independent of short or long format, identifies both 216 the type of RTP header extension and, in the case of the SDES item 217 header extension, the type of SDES item. The mapping is done in 218 signaling by identifying the header extension and SDES item type 219 using a URN, which is defined in the IANA consideration (Section 5) 220 for the known SDES items appropriate to use. 222 4.1.1. One-Byte Format 224 The one-byte header format for an SDES item extension element 225 consists of the one-byte header (defined in Section 4.2 of 226 [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length 227 field (len) that identifies the number of data bytes (len value +1) 228 following the header. The data part consists of len+1 bytes of UTF-8 229 [RFC3629] text. The type of text and its mapping to the SDES item 230 type is determined by the ID field value. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | ID | len | SDES Item text value ... | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 1 240 4.1.2. Two-Byte Format 242 The two-byte header format for an SDES item extension element 243 consists of the two-byte header (defined in Section 4.3 of 244 [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length 245 field (len) that identifies the number of data bytes following the 246 header. The data part consists of len bytes of UTF-8 text. The type 247 of text and its mapping to the SDES item type is determined by the ID 248 field value. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | ID | len | SDES Item text value ... | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 2 258 4.2. Usage of the SDES Item Header Extension 260 This section discusses various usage considerations; which form of 261 header extension to use, the packet expansion, and when to send SDES 262 items in header extension. 264 4.2.1. One or Two Byte Headers 266 The RTP header extensions for SDES items MAY use either the one-byte 267 or two-byte header formats, depending on the text value size for the 268 used SDES items and the requirement from any other header extensions 269 used. The one-byte header SHOULD be used when all non SDES item 270 header extensions supports the one-byte format and all SDES item text 271 values contain at most 16 bytes. Note that the RTP header extension 272 specification does not allow mixing one-byte and two-byte headers for 273 the same RTP stream (SSRC), so if the value size of any of the SDES 274 items value requires the two-byte header, then all other header 275 extensions MUST also use the two-byte header format. 277 For example using CNAMEs that are generated according to "Guidelines 278 for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" 279 [RFC7022], using short term persistent values, and if 96-bit random 280 values prior to base64 encoding are sufficient, then they will fit 281 into the one-byte header format. 283 An RTP middlebox needs to take care choosing between one-byte headers 284 and two-byte headers when creating the first packets for an outgoing 285 stream (SSRC) with header extensions. First of all it needs to 286 consider all the header extensions that may potentially be used. 287 Secondly, it needs to know the size of the SDES items that are going 288 to be included, and use two bytes headers if any are longer than 16 289 bytes. An RTP middlebox that forwards a stream, i.e., not mixing it 290 or combing it with other streams, may be able to base its choice on 291 the header size in incoming streams. This is assuming that the 292 middlebox does not modify the stream or add additional header 293 extensions to the stream it sends, in which case it needs to make its 294 own decision. 296 4.2.2. MTU and Packet Expansion 298 The RTP packet size will clearly increase when a header extension is 299 included. How much depends on the type of header extensions and 300 their data content. The SDES items can vary in size. There are also 301 some use-cases that require transmitting multiple SDES items in the 302 same packet to ensure that all relevant data reaches the receiver. 303 An example of that is when both CNAME, a MID, and the rapid time 304 synchronization extension from RFC 6051 are needed. Such a 305 combination is quite likely to result in at least 16+3+8 bytes of 306 data plus the headers, which will be another 7 bytes for one-byte 307 headers, plus two bytes of header padding to make the complete header 308 extension 32-bit word aligned, thus in total 36 bytes. 310 If the packet expansion cannot be taken into account when producing 311 the RTP payload, it can cause an issue. An RTP payload that is 312 created to meet a particular IP level Maximum Transmission Unit 313 (MTU), taking the addition of IP/UDP/RTP headers but not RTP header 314 extensions into account, could exceed the MTU when the header 315 extensions are present, thus resulting in IP fragmentation. IP 316 fragmentation is known to negatively impact the loss rate due to 317 middleboxes unwilling or not capable of dealing with IP fragments, as 318 well as increasing the target surface for other types of packet 319 losses. 321 As this is a real issue, the media encoder and payload packetizer 322 should be flexible and be capable of handling dynamically varying 323 payload size restrictions to counter the packet expansion caused by 324 header extensions. If that is not possible, some reasonable worst 325 case packet expansion should be calculated and used to reduce the RTP 326 payload size of all RTP packets the sender transmits. 328 4.2.3. Transmission Considerations 330 The general recommendation is to only send header extensions when 331 needed. This is especially true for SDES items that can be sent in 332 periodic repetitions of RTCP throughout the whole session. Thus, the 333 different usages (Section 4.2.4) have different recommendations. 334 First some general considerations for getting the header extensions 335 delivered to the receiver: 337 1. The probability for packet loss and burst loss determine how many 338 repetitions of the header extensions will be required to reach a 339 targeted delivery probability, and if burst loss is likely, what 340 distribution would be needed to avoid getting all repetitions of 341 the header extensions lost in a single burst. 343 2. If a set of packets are all needed to enable decoding, there is 344 commonly no reason for including the header extension in all of 345 these packets, as they share fate. Instead, at most one instance 346 of the header extension per independently decodable set of media 347 data would be a more efficient use of the bandwidth. 349 3. How early the SDES item information is needed, from the first 350 received RTP data or only after some set of packets are received, 351 can guide if the header extension(s) should be in all of the 352 first N packets or be included only once per set of packets, for 353 example once per video frame. 355 4. The use of RTP level robustness mechanisms, such as RTP 356 retransmission [RFC4588], or Forward Error Correction, e.g., 357 [RFC5109] may treat packets differently from a robustness 358 perspective, and SDES header extensions should be added to 359 packets that get a treatment corresponding to the relative 360 importance of receiving the information. 362 As a summary, the number of header extension transmissions should be 363 tailored to a desired probability of delivery taking the receiver 364 population size into account. For the very basic case, N repetitions 365 of the header extensions should be sufficient, but may not be 366 optimal. N is selected so that the header extension target delivery 367 probability reaches 1-P^N, where P is the probability of packet loss. 368 For point to point or small receiver populations, it might also be 369 possible to use feedback, such as RTCP, to determine when the 370 information in the header extensions has reached all receivers and 371 stop further repetitions. Feedback that can be used includes the 372 RTCP XR Loss RLE report block [RFC3611], which will indicate 373 successful delivery of particular packets. If the RTP/AVPF Transport 374 Layer Feedback Messages for generic NACK [RFC4585] is used, it can 375 indicate the failure to deliver an RTP packet with the header 376 extension, thus indicating the need for further repetitions. The 377 normal RTCP report blocks can also provide an indicator of successful 378 delivery, if no losses are indicated for a reporting interval 379 covering the RTP packets with the header extension. Note that loss 380 of an RTCP packet reporting on an interval where RTP header extension 381 packets were sent, does not necessarily mean that the RTP header 382 extension packets themselves were lost. 384 4.2.4. Different Usages 386 4.2.4.1. New SSRC 388 A new SSRC joins an RTP session. As this SSRC is completely new for 389 everyone, the goal is to ensure, with high probability, that all RTP 390 session participants receives the information in the header 391 extension. Thus, header extension transmission strategies that allow 392 some margins in the delivery probability should be considered. 394 4.2.4.2. Late Joiner 396 In a multi-party RTP session where one or a small number of receivers 397 join a session where the majority of receivers already have all 398 necessary information, the use of header extensions to deliver 399 relevant information should be tailored to reach the new receivers. 400 The trigger to send header extensions can for example either be RTCP 401 from new receiver(s) or an explicit request like the Rapid 402 Resynchronization Request defined in [RFC6051]. In centralized 403 topologies where an RTP middlebox is present, it can be responsible 404 for transmitting the known information, possibly stored, to the new 405 session participant only, and not repeat it to all the session 406 participants. 408 4.2.4.3. Information Change 410 If the SDES information is tightly coupled with the RTP data, and the 411 SDES information needs to be updated, then the use of the RTP header 412 extension is superior to RTCP. Using the RTP header extension 413 ensures that the information is updated on reception of the related 414 RTP media, ensuring synchronization between the two. Continued use 415 of the old SDES information can lead to undesired effects in the 416 application. Thus, header extension transmission strategies with 417 high probability of delivery should be chosen. 419 4.2.5. SDES Items in RTCP 421 The RTP header extension information, i.e., SDES items, can and will 422 be sent also in RTCP. Therefore, it is worth making some reflections 423 on this interaction. As an alternative to the header extension, it 424 is possible to schedule a non-regular RTCP packet transmission 425 containing important SDES items, if one uses an RTP/AVPF-based RTP 426 profile. Depending on which mode one's RTCP feedback transmitter is 427 working on, extra RTCP packets may be sent as immediate or early 428 packets, enabling more timely SDES information delivery. 430 There are however two aspects that differ between using RTP header 431 extensions and any non-regular transmission of RTCP packets. First, 432 as the RTCP packet is a separate packet, there is no direct relation 433 and also no fate sharing between the relevant media data and the SDES 434 information. The order of arrival for the packets will matter. With 435 a header-extension, the SDES items can be ensured to arrive if the 436 media data to play out arrives. Secondly, it is difficult to 437 determine if an RTCP packet is actually delivered. This, as the RTCP 438 packets lack both sequence number and a mechanism providing feedback 439 on the RTCP packets themselves. 441 4.2.6. Update Flaps 443 The SDES item may arrive both in RTCP and in RTP header extensions, 444 potentially causing the value to flap back and forth at the time of 445 updating. There are at least two reasons for these flaps. The first 446 one is packet reordering, where a pre-update RTP or RTCP packet with 447 an SDES item is delivered to the receiver after the first RTP/RTCP 448 packet with the updated value. The second reason is the different 449 code-paths for RTP and RTCP in implementations. An update to the 450 sender's SDES item parameter can take a different time to propagate 451 to the receiver than the corresponding media data. For example, an 452 RTCP packet with the SDES item included that may have been generated 453 prior to the update can still reside in a buffer and be sent 454 unmodified. The update of the item's value can at the same time 455 cause RTP packets to be sent including the header extension, prior to 456 the RTCP packet being sent. 458 However, most of these issues can be avoided by the receiver 459 performing some checks before updating the receiver's stored value. 460 To handle flaps caused by reordering, SDES items received in RTP 461 packets with the same or a lower extended sequence number than the 462 last change MUST NOT be applied, i.e., discard items that can be 463 determined to be older than the current one. For compound RTCP 464 packets, which will contain a Sender Report (SR) packet (assuming an 465 active RTP sender), the receiver can use the RTCP SR Timestamp field 466 to determine at what approximate time it was transmitted. If the 467 timestamp is earlier than the last received RTP packet with a header 468 extension carrying an SDES item, and especially if carrying a 469 previously used value, the SDES item in the RTCP SDES packet can be 470 ignored. Note that media processing and transmission pacing can 471 easily cause the RTP header timestamp field as well as the RTCP SR 472 timestamp field to not match with the actual transmission time. 474 4.2.7. RTP Header Compression 476 When robust header compression (ROHC) [RFC5225] is used with RTP, the 477 RTP header extension [RFC5285] data itself is not part of what is 478 being compressed and thus does not impact header compression 479 performance. The extension indicator (X) bit in the RTP header is 480 however compressed. It is classified as rarely changing, which may 481 no longer be true for all RTP header extension usage, in turn leading 482 to lower header compression efficiency. 484 5. IANA Considerations 486 This section makes the following requests to IANA: 488 o Create a new sub-registry reserved for RTCP SDES items with the 489 URN sub-space "urn:ietf:params:rtp-hdrext:sdes:" in the RTP 490 Compact Header Extensions registry. 492 o Register the SDES items appropriate for use with the RTP header 493 extension defined in this document. 495 RFC-editor note: Please replace all occurrences of RFCXXXX with the 496 RFC number this specification receives when published. 498 5.1. Registration of an SDES Base URN 500 IANA is requested to register the below entry in the RTP Compact 501 Header Extensions registry: 503 Extension URI: urn:ietf:params:rtp-hdrext:sdes 504 Description: Reserved as base URN for RTCP SDES items that are also 505 defined as RTP Compact header extensions. 506 Contact: Authors of [RFCXXXX] 507 Reference: [RFCXXXX] 509 The reason to register a base URN for an SDES sub-space is that the 510 name represents an RTCP Source Description item, where a 511 specification is strongly recommended [RFC3550]. 513 5.2. Creation of an SDES Sub-Registry 515 IANA is requested to create a sub-registry to the RTP Compact Header 516 Extensions registry, with the same basic requirements, structure and 517 layout as the RTP Compact Header Extensions registry. 519 o Registry name: RTP SDES Compact Header Extensions 521 o Specification: RFCXXXX and RFCs updating RFCXXXX 523 o Information required: Same as for RTP Header Extensions [RFC5285] 524 registry 526 o Review process: Same as for RTP Header Extensions [RFC5285] 527 registry, with the following requirements added to the expert 528 review: 530 1. Any registration using an Extension URI that starts with 531 "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also 532 have a registered Source Description item in the "RTP SDES 533 item types" registry. 535 2. A security and privacy consideration for the SDES item MUST be 536 provided with the registration. 538 3. Information MUST be provided on why this SDES item requires 539 timely delivery, motivating it to be transported in a header 540 extension rather than as RTCP only. 542 o Size and format of entries: Same as for RTP Header Extensions 543 [RFC5285] registry. 545 o Initial assignments: See Section 5.3 below. 547 5.3. Registration of SDES Item 549 It is requested that the following SDES item is registered in the 550 newly formed RTP SDES Compact Header Extensions registry: 552 Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname 553 Description: Source Description: Canonical End-Point Identifier 554 (SDES CNAME) 555 Contact: Authors of [RFCXXXX] 556 Reference: [RFCXXXX] 558 6. Security Considerations 560 Source Description items may contain data that are sensitive from a 561 security perspective. There are SDES items that are or may be 562 sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, 563 PHONE, LOC and H323-CADDR. Some may contain sensitive information, 564 like NOTE and PRIV, while others may be sensitive from profiling 565 implementations for vulnerability or other reasons, like TOOL. The 566 CNAME sensitivity can vary depending on how it is generated and what 567 persistence it has. A short term CNAME identifier generated using a 568 random number generator [RFC7022] may have minimal security 569 implications, while a CNAME of the form user@host has privacy 570 concerns, and a CNAME generated from a MAC address has long term 571 tracking potentials. 573 In RTP sessions where any type of confidentiality protection is 574 enabled for RTCP, the SDES item header extensions MUST also be 575 protected. This implies that to provide confidentiality, users of 576 SRTP need to implement and use encrypted header extensions per 577 [RFC6904]. SDES items carried as RTP header extensions MUST then use 578 commensurate strength algorithms and SHOULD use the same 579 cryptographic primitives (algorithms, modes) as applied to RTCP 580 packets carrying corresponding SDES items. If the security level is 581 chosen to be different for an SDES item in RTCP and RTP header 582 extension, it is important to motivate the exception, and to consider 583 the security properties as the worst in each aspect for the different 584 configurations. It is worth noting that the current Secure RTP 585 (SRTP) [RFC3711] only provides protection for the next trusted RTP/ 586 RTCP hop, which is not necessarily end-to-end. 588 The general RTP header extension mechanism [RFC5285] does not itself 589 contain any functionality that is a significant risk for a denial of 590 service attack, neither from processing nor storage requirements. 591 The extension for SDES items defined in this document, can 592 potentially be a risk. The risk depends on the received SDES item 593 and its content. If the SDES item causes the receiver to perform a 594 large amount of processing, create significant storage structures, or 595 emit network traffic, such a risk does exist. The CNAME SDES item in 596 the RTP header extension is only a minor risk, as reception of a 597 CNAME item will create an association between the stream carrying the 598 SDES item and other RTP streams with the same SDES item. This 599 usually results in time synchronizing the media streams, thus some 600 additional processing is performed. However, the application's media 601 quality is likely more affected by an erroneous or changing 602 association and media synchronization, than the application quality 603 impact caused by the additional processing. 605 As the SDES items are used by the RTP based application to establish 606 relationships between RTP streams or between an RTP stream and 607 information about the originating participant, there SHOULD be strong 608 integrity protection and source authentication of the header 609 extensions. If not, an attacker can modify the SDES item value to 610 create erroneous relationship bindings in the receiving application. 611 For information regarding options for securing RTP, see [RFC7201]. 613 7. Acknowledgments 615 The authors likes to thank the following individuals for feedback and 616 suggestions: Colin Perkins, Ben Campbell, and Samuel Weiler. 618 8. References 620 8.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 628 Jacobson, "RTP: A Transport Protocol for Real-Time 629 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 630 July 2003, . 632 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 633 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 634 2008, . 636 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 637 Real-time Transport Protocol (SRTP)", RFC 6904, 638 DOI 10.17487/RFC6904, April 2013, 639 . 641 8.2. Informative References 643 [I-D.ietf-mmusic-sdp-bundle-negotiation] 644 Holmberg, C., Alvestrand, H., and C. Jennings, 645 "Negotiating Media Multiplexing Using the Session 646 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 647 negotiation-30 (work in progress), June 2016. 649 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 650 "RTP Control Protocol Extended Reports (RTCP XR)", 651 RFC 3611, DOI 10.17487/RFC3611, November 2003, 652 . 654 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 655 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 656 2003, . 658 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 659 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 660 RFC 3711, DOI 10.17487/RFC3711, March 2004, 661 . 663 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 664 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 665 July 2006, . 667 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 668 "Extended RTP Profile for Real-time Transport Control 669 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 670 DOI 10.17487/RFC4585, July 2006, 671 . 673 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 674 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 675 DOI 10.17487/RFC4588, July 2006, 676 . 678 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 679 Correction", RFC 5109, DOI 10.17487/RFC5109, December 680 2007, . 682 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 683 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 684 UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, 685 . 687 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 688 Media Attributes in the Session Description Protocol 689 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 690 . 692 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 693 Protocol (SDP) Grouping Framework", RFC 5888, 694 DOI 10.17487/RFC5888, June 2010, 695 . 697 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 698 Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, 699 . 701 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 702 "Guidelines for Choosing RTP Control Protocol (RTCP) 703 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 704 September 2013, . 706 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 707 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 708 . 710 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 711 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 712 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 713 DOI 10.17487/RFC7656, November 2015, 714 . 716 Authors' Addresses 718 Magnus Westerlund 719 Ericsson 720 Farogatan 6 721 SE-164 80 Stockholm 722 Sweden 724 Phone: +46 10 714 82 87 725 Email: magnus.westerlund@ericsson.com 727 Bo Burman 728 Ericsson 729 Gronlandsgatan 31 730 Stockholm 16480 731 Sweden 733 Email: bo.burman@ericsson.com 735 Roni Even 736 Huawei Technologies 737 Tel Aviv 738 Israel 740 Email: roni.even@mail01.huawei.com 742 Mo Zanaty 743 Cisco Systems 744 7100 Kit Creek 745 RTP, NC 27709 746 USA 748 Email: mzanaty@cisco.com