idnits 2.17.1 draft-ietf-mmusic-delayed-duplication-03.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 (December 3, 2013) is 3790 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 369, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-06) exists of draft-ietf-avtext-rtp-duplication-04 -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Begen 3 Internet-Draft Cisco 4 Intended status: Standards Track Y. Cai 5 Expires: June 6, 2014 Microsoft 6 H. Ou 7 Cisco 8 December 3, 2013 10 Delayed Duplication Attribute in the Session Description Protocol 11 draft-ietf-mmusic-delayed-duplication-03 13 Abstract 15 A straightforward approach to provide protection against packet 16 losses due to network outages with a longest duration of T time units 17 is to duplicate the original packets and send each copy separated in 18 time by at least T time units. This approach is commonly referred to 19 as Time-shifted Redundancy, Temporal Redundancy or simply Delayed 20 Duplication. This document defines an attribute to indicate the 21 presence of temporally redundant media streams and the duplication 22 delay in the Session Description Protocol. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 6, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 60 3. The 'duplication-delay' Attribute . . . . . . . . . . . . . . 4 61 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Registration of SDP Attributes . . . . . . . . . . . . . 8 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 Inside an IP network, packet delivery may be interrupted due to a 74 physical link, interface or device failure. To reduce the impact of 75 such interruptions, some networks are built in a resilient manner, 76 allowing for multiple alternative paths between two endpoints. 77 However, if there is no resiliency in the network or the failure 78 happens in a non-resilient part of the network, a temporary outage 79 will occur (i.e., packets will get dropped) lasting until 80 connectivity is restored around the failure (which is called network 81 reconvergence). Typically, network reconvergence takes between tens 82 and hundreds of milliseconds depending on the size and features of 83 the network. 85 There are a number of network-reconvergence technologies available 86 today such as IP Fast Convergence, MPLS Traffic Engineering Fast 87 Reroute and Multicast Only Fast Reroute. These technologies can be 88 augmented by different types of application-layer loss-repair methods 89 such as Forward Error Correction (FEC), retransmission, temporal 90 redundancy and spatial redundancy to minimize (and sometimes totally 91 eliminate) the impact of outages. Each combination has its distinct 92 requirements in terms of bandwidth consumption and results in a 93 different network complexity. Thus, a network operator has to 94 carefully consider what combination to deploy for different parts of 95 a network (e.g., core vs. edge). A detailed overview of network- 96 convergence technologies and loss-repair methods is provided in 97 [IC2011]. 99 One of the loss-repair methods is temporal redundancy, also known as 100 delayed duplication. A media sender using this method transmits an 101 original source packet and transmits its duplicate after a certain 102 delay following the original transmission. If a network outage hits 103 the original transmission, the expectation is that the second 104 transmission arrives at the receiver (with a high probability). 105 Alternatively, the second transmission may be hit by an outage and 106 gets dropped, and the original transmission completes successfully. 107 On the receiver side, both transmissions can also arrive and in that 108 case, the receiver (or the node that does the duplicate suppression) 109 needs to identify the duplicate packets and discard them 110 appropriately, producing a duplicate-free stream. 112 Delayed duplication can be used in a variety of multimedia 113 applications where there is sufficient bandwidth for the duplicated 114 traffic and the application can tolerate the introduced delay. 115 However, it must be used with care since it might easily result in a 116 new series of denial-of-service attacks. Delayed duplication is 117 harmful in cases where the primary cause of packet loss is 118 congestion, rather than a network outage due to a temporary link or 119 network element failure. Duplication should only be used by 120 endpoints that want to protect against network failures; protection 121 against congestion must be achieved through other means as 122 duplication will make congestion only worse. 124 One particular use case for delayed duplication is to improve the 125 reliability of real-time video feeds inside a core IP network where 126 bandwidth is plentiful and maximum reliability (preferably zero loss) 127 is desired [IC2011]. Compared to other redundancy approaches such as 128 FEC [RFC6363] and redundant data encoding (e.g., [RFC2198]), delayed 129 duplication is easy to implement since it does not require any 130 special type of encoding or decoding. 132 For duplicate suppression, the receiver has to be able to identify 133 the identical packets. This is straightforward for media packets 134 that carry one or more unique identifiers such as the sequence number 135 field in RTP header [RFC3550]. In non-RTP applications, the receiver 136 can use unique sequence numbers if available or other alternative 137 approaches to compare the incoming packets and discard the duplicate 138 ones. 140 This specification introduces a new Session Description Protocol 141 (SDP) [RFC4566] attribute for applications/services using the delayed 142 duplication method to indicate the relative delay for each additional 143 duplication. The attribute is used with the Duplication Grouping 144 Semantics defined in [I-D.ietf-mmusic-duplication-grouping]. 146 This specification does not explain how to select the duplication 147 delay that a sender should use, which depends on the underlying 148 network and reconvergence technologies used inside this network. 149 This specification does not explain how the receiver should suppress 150 the duplicate packets and merge the incoming streams to produce a 151 loss-free and duplication-free output stream (a process commonly 152 called stream merging), either. An application or a transport 153 service that will use the delayed duplication method must determine 154 its own rules about stream merging. 156 In practice, more than two redundant streams are unlikely to be used 157 since the additional delay and increased overhead are not easily 158 justified. However, we define the new attribute in a general way so 159 that it could be used with more than two redundant streams (i.e., 160 multiple duplications), if needed. While the primary focus in this 161 specification is the RTP-based transport, the new attribute is 162 applicable to both RTP and non-RTP streams. Protocol issues and 163 details on duplicating RTP streams are presented in 164 [I-D.ietf-avtext-rtp-duplication]. 166 2. Requirements Notation 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in 171 [RFC2119]. 173 3. The 'duplication-delay' Attribute 175 The following ABNF [RFC5234] syntax formally describes the 176 'duplication-delay' attribute: 178 delaying-attribute = "a=duplication-delay:" periods CRLF 179 periods = period *( SP period) 180 period = 1*DIGIT ; in milliseconds 182 Figure 1: ABNF syntax for the 'duplication-delay' attribute 184 The 'duplication-delay' attribute is defined as both a media-level 185 and session-level attribute. It specifies the relative delay with 186 respect to the previous transmission of each duplication in 187 milliseconds (ms) at the time of transmission. The following rules 188 apply: 190 o If used as a media-level attribute, it MUST be used with the 191 'ssrc-group' attribute and "DUP" grouping semantics as defined in 192 [I-D.ietf-mmusic-duplication-grouping]. When used as a media- 193 level attribute, the relative delay value(s) it specifies SHALL 194 apply to every Synchronization Source (SSRC)-based duplication 195 grouping in the same media description. In other words, one 196 cannot specify different duplication delay values to different 197 duplication groups in the same media description. 199 o If used as a session-level attribute, it MUST be used with 'group' 200 attribute and "DUP" grouping semantics as defined in 201 [I-D.ietf-mmusic-duplication-grouping]. When used as a session- 202 level attribute, the relative delay value(s) it specifies SHALL 203 apply to every duplication grouping in the same SDP description. 204 In other words, one cannot specify different duplication delay 205 values to different duplication groups in the same SDP 206 description. If one needs to specify different duplication delay 207 values for different duplication groups, then one MUST use 208 different SDP descriptions for each or MUST use the 'duplication- 209 delay' attribute at media level. In that case, the 'duplication- 210 delay' attribute MUST NOT be used at the session level. 212 o For offer/answer model considerations, refer to 213 [I-D.ietf-mmusic-duplication-grouping]. 215 4. SDP Examples 217 In the first example below, the multicast stream consists of two RTP 218 streams, each duplicated once, resulting in two sets of two-stream 219 groups. The same duplication delay of 100 ms is applied to each 220 grouping. The first set's streams have SSRCs of 1000 and 1010 and 221 the second set's streams have SSRCs of 1020 and 1030. 223 v=0 224 o=ali 1122334455 1122334466 IN IP4 dup.example.com 225 s=Delayed Duplication 226 t=0 0 227 m=video 30000 RTP/AVP 100 101 228 c=IN IP4 233.252.0.1/127 229 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 230 a=rtpmap:100 MP2T/90000 231 a=ssrc:1000 cname:ch1a@example.com 232 a=ssrc:1010 cname:ch1a@example.com 233 a=ssrc-group:DUP 1000 1010 234 a=rtpmap:101 MP2T/90000 235 a=ssrc:1020 cname:ch1b@example.com 236 a=ssrc:1030 cname:ch1b@example.com 237 a=ssrc-group:DUP 1020 1030 238 a=duplication-delay:100 239 a=mid:Ch1 241 Note that in actual use, SSRC values, which are random 32-bit 242 numbers, could be much larger than the ones shown in this example. 244 In the second example below, the multicast stream is duplicated 245 twice. 50 ms after the original transmission, the first duplicate is 246 transmitted and 100 ms after that, the second duplicate is 247 transmitted. In other words, the same packet is transmitted three 248 times over a period of 150 ms. 250 v=0 251 o=ali 1122334455 1122334466 IN IP4 dup.example.com 252 s=Delayed Duplication 253 t=0 0 254 m=video 30000 RTP/AVP 100 255 c=IN IP4 233.252.0.1/127 256 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 257 a=rtpmap:100 MP2T/90000 258 a=ssrc:1000 cname:ch1c@example.com 259 a=ssrc:1010 cname:ch1c@example.com 260 a=ssrc:1020 cname:ch1c@example.com 261 a=ssrc-group:DUP 1000 1010 1020 262 a=duplication-delay:50 100 263 a=mid:Ch1 265 In the third example below, the multicast UDP stream is duplicated 266 with a duplication delay of 50 ms. Redundant streams are sent in 267 separate source-specific multicast (SSM) sessions so the receiving 268 host has to join both SSM sessions if it wants to receive both 269 streams. 271 v=0 272 o=ali 1122334455 1122334466 IN IP4 dup.example.com 273 s=Delayed Duplication 274 t=0 0 275 a=group:DUP S1a S1b 276 a=duplication-delay:50 277 m=audio 30000 udp mp4 278 c=IN IP4 233.252.0.1/127 279 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 280 a=mid:S1a 281 m=audio 40000 udp mp4 282 c=IN IP4 233.252.0.2/127 283 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 284 a=mid:S1b 286 5. Security Considerations 288 The 'duplication-delay' attribute is not believed to introduce any 289 significant security risk to multimedia applications. A malevolent 290 third party could use this attribute to misguide the receiver(s) 291 about the duplication delays and/or the number of redundant streams. 292 For example, if the malevolent third party increases the value of the 293 duplication delay, the receiver(s) will unnecessarily incur a longer 294 delay since they will have to wait for the entire period. Or, if the 295 duplication delay is reduced by the malevolent third party, the 296 receiver(s) might not wait long enough for the duplicated 297 transmission and incur unnecessary packet losses. However, these 298 require intercepting and rewriting the packets carrying the SDP 299 description; and if an interceptor can do that, many more attacks are 300 also possible. 302 In order to avoid attacks of this sort, the SDP description needs to 303 be integrity protected and provided with source authentication. This 304 can, for example, be achieved on an end-to-end basis using S/MIME 305 [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME 306 types (application/sdp). Alternatively, HTTPS [RFC2818] or the 307 authentication method in the Session Announcement Protocol (SAP) 308 [RFC2974] could be used as well. 310 Another security risk is due to possible software misconfiguration or 311 a software bug where a large number of duplicates could be 312 unwillingly signaled in the 'duplication-delay' attribute. 313 Similarly, an attacker can use this attribute to start a denial-of- 314 service attack by signaling and sending too many duplicated streams. 315 In applications where this attribute is to be used, it is a good 316 practice to put a hard limit both on the number of duplicate streams 317 and the total delay introduced due to duplication regardless of what 318 the SDP description specifies. 320 Since this mechanism causes duplication of media packets, if those 321 packets are also cryptographically protected, (e.g., encrypted) then 322 such duplication could act as an accelerator if any million-message 323 [RFC3218] or similar Lucky13 attack exists against the security 324 mechanism that is in use. Such acceleration could turn an otherwise 325 infeasible attack into one that is practical, however, assuming that 326 the amount of duplication is small and that such weak or broken 327 security mechanisms should really not be used, the overall security 328 impact of the duplication should be minimal. If however, a bad-actor 329 were in control of the SDP but did not have access to the keying 330 material used for media, then such a bad actor could potentially use 331 the SDP to cause the media handling to use a weak or broken mechanism 332 with a lot of duplication, in which case the duplication could be 333 significant. Deployments where the SDP is controlled by an actor who 334 should not have access to the media keying-material should therefore 335 be cautious in their use of this duplication mechanism. 337 If this mechanism were used in conjunction with SDES and if the key 338 being used for media protection is derived from a human-memorable or 339 otherwise dictionary-attackable secret, then the duplication done 340 here could allow for a more efficient dictionary attack against the 341 media. The right countermeasure is to use proper keying, or if using 342 SDES to ensure that the keys used are not dictionary-attackable. 344 6. IANA Considerations 346 The following contact information shall be used for all registrations 347 in this document: 349 Ali Begen 350 abegen@cisco.com 352 Note to the RFC Editor: In the following, replace "XXXX" with the 353 number of this document prior to publication as an RFC. 355 6.1. Registration of SDP Attributes 357 This document registers a new attribute name in SDP. 359 SDP Attribute ("att-field"): 360 Attribute name: duplication-delay 361 Long form: Duplication delay for temporally redundant 362 streams 363 Type of name: att-field 364 Type of attribute: Media or session level 365 Subject to charset: No 366 Purpose: Specifies the relative duplication delay(s) for 367 redundant stream(s) 368 Reference: [RFCXXXX] 369 Values: See [RFCXXXX] 371 7. Acknowledgements 373 Authors would like to thank Colin Perkins and Paul Kyzivat for their 374 suggestions and reviews. 376 8. References 378 8.1. Normative References 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 384 Description Protocol", RFC 4566, July 2006. 386 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 387 Jacobson, "RTP: A Transport Protocol for Real-Time 388 Applications", STD 64, RFC 3550, July 2003. 390 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 391 Specifications: ABNF", STD 68, RFC 5234, January 2008. 393 [I-D.ietf-mmusic-duplication-grouping] 394 Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 395 Semantics in the Session Description Protocol", draft- 396 ietf-mmusic-duplication-grouping-04 (work in progress), 397 November 2013. 399 8.2. Informative References 401 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 402 Correction (FEC) Framework", RFC 6363, October 2011. 404 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 405 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 406 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 407 September 1997. 409 [I-D.ietf-avtext-rtp-duplication] 410 Begen, A. and C. Perkins, "Duplicating RTP Streams", 411 draft-ietf-avtext-rtp-duplication-04 (work in progress), 412 October 2013. 414 [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, 415 "Toward Lossless Video Transport, IEEE Internet Computing, 416 vol. 15/6, pp. 48-57", November 2011. 418 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 419 RFC 5652, September 2009. 421 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 422 Mail Extensions (S/MIME) Version 3.2 Message 423 Specification", RFC 5751, January 2010. 425 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 427 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 428 Announcement Protocol", RFC 2974, October 2000. 430 [RFC3218] Rescorla, E., "Preventing the Million Message Attack on 431 Cryptographic Message Syntax", RFC 3218, January 2002. 433 Authors' Addresses 435 Ali Begen 436 Cisco 437 181 Bay Street 438 Toronto, ON M5J 2T3 439 Canada 441 Email: abegen@cisco.com 443 Yiqun Cai 444 Microsoft 445 1065 La Avenida 446 Mountain View, CA 94043 447 USA 449 Email: yiqunc@microsoft.com 450 Heidi Ou 451 Cisco 452 170 W. Tasman Dr. 453 San Jose, CA 95134 454 USA 456 Email: hou@cisco.com