idnits 2.17.1 draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 339. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2, 2008) is 5800 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) == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-01 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-06 -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT J. Lennox 3 Internet-Draft Vidyo 4 Updates: 3550 (if approved) T. Schierl 5 Intended status: Standards Track Fraunhofer HHI 6 Expires: December 4, 2008 S. Ganesan 7 Motorola 8 June 2, 2008 10 Real-Time Transport Protocol (RTP) Timestamps for Layered Encodings 11 draft-lennox-avt-rtp-layered-encoding-timestamps-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 4, 2008. 38 Abstract 40 The Real-Time Transport Protocol (RTP) specification defines how 41 layered encodings can be sent over a layered transmission system. A 42 source can stripe the progressive layers of a hierarchically 43 represented signal across multiple RTP sessions, each carried on, for 44 example, its own multicast group. These layered encodings are given 45 special treatment in RTP, notably in that the same synchronization 46 source (SSRC) identifier space is used across the sessions of all 47 layers. 49 The RTP protocol specification does not, however, explicitly state 50 how RTP timestamps are to be used with layered encodings. This 51 document updates the RTP specification to require that RTP timestamps 52 for layered encodings be synchronized, i.e. that every layer chooses 53 the same random initial value for the timestamp. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Normative Requirements . . . . . . . . . . . . . . . . . . . . 3 60 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 5. Architectural Implications . . . . . . . . . . . . . . . . . . 4 62 6. Payload Design Considerations . . . . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 Intellectual Property and Copyright Statements . . . . . . . . . . 8 71 1. Introduction 73 The Real-Time Transport Protocol (RTP) [RFC3550] specification 74 defines how layered encodings can be sent over a layered transmission 75 system. A source can stripe the progressive layers of a 76 hierarchically represented signal across multiple RTP sessions, each 77 carried on, for example, its own multicast group. These layered 78 encodings are given special treatment in RTP, notably in that the 79 same synchronization source (SSRC) identifier space is used across 80 the sessions of all layers. 82 The RTP protocol specification does not, however, explicitly state 83 how RTP timestamps are to be used with layered encodings. This 84 document updates the RTP specification to require that RTP timestamps 85 for layered encodings be synchronized, i.e. that every layer chooses 86 the same random initial value for the timestamp. 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119] and 93 indicate requirement levels for compliant implementations. 95 3. Normative Requirements 97 When a source is sent as a layered encoding transmitted on separate 98 RTP sessions (as defined in Section 2.4 of [RFC3550]), such that the 99 same synchronization source (SSRC) identifier is used on each 100 session, the same initial (random) RTP timestamp value MUST be used 101 for every layer. 103 (Since each layer's RTP timestamps are derived from the same media 104 clock, and so will advance at the same rate, this implies that RTP 105 packets will have equal timestamps if they are (logically) generated 106 at once, e.g., belong to the same video frame, as with packets on a 107 single session.) 109 4. Discussion 111 Speer and McCanne [I-D.speer-avt-layered-video] defined how layered 112 encoding support would be added to the original RTP specification 113 [RFC1889]. This work was adapted into the current RTP specification 114 when it was revised [RFC3550]. 116 This specification modified RTP so that the same synchronization 117 source (SSRC) identifier would be used on each session for a layered 118 encoding transmitted on multiple streams. As discussed in that 119 draft, the alternative would be to allocate each layer's SSRC 120 independently, and associate the streams using the canonical name 121 (CNAME) information sent periodically in RTCP source description 122 (SDES) packets, as RTP does to associate separate audio and video 123 streams from a single user. However, this alternative introduces 124 additional complexity, in that it forces each receiver to manage all 125 the CNAME/SSRC bindings; requires newly-arrived receivers to wait for 126 the source description packets before they can start decoding a 127 stream; and creates new error recovery conditions for dealing with 128 conflicting information that arrives on the different sessions. 130 Speer and McCanne specification's did not say anything about RTP 131 timestamps. However, as documented in McCanne's Ph.D. Thesis 132 [McCa96], vic [VIC], the primary implementation of layered encoding 133 of RTP, sent base and enhancement layers of a video stream with 134 synchronized RTP timestamps, and relied on this fact to associate the 135 frames when decoding them. 137 Absent payload-specific synchronization information, as with source 138 identifiers, the alternative for stream alignment would be to rely on 139 RTCP reports, in this case on the NTP timestamps carried in carried 140 in RTCP sender report (SR) packets. However, this would introduce 141 much the same problems as relying on CNAME-based synchronization for 142 the sources. It introduces significant additional complexity; 143 receivers must wait for the receipt of SR packets before they can 144 start decoding a stream; and conflicting information can arise from 145 the different sessions, particularly for sessions with long RTCP 146 reporting intervals if there is clock skew between a source's NTP and 147 media timestamps. This largely removes any advantage of SSRC 148 synchronization across the layers. 150 5. Architectural Implications 152 RTP timestamp randomization has two primary motivations: it improves 153 the probability of detection of SSRC collisions, and it provides 154 additional randomness for [RFC3550]-style packet encryption (a "weak 155 initialization vector", in the words of that RFC). 157 Synchronizing RTP timestamps across sessions does not harm SSRC 158 collision detection. As specified by [RFC3550], for layered sessions 159 the base layer's session is used for SSRC identifier allocation and 160 collision resolution. When two sources collide, they will collide on 161 every session layer on which they are being sent; and when a source 162 changes its SSRC following a collision, it will change it on every 163 session. 165 The security implications of timestamp synchronization are discussed 166 in Section 7. 168 6. Payload Design Considerations 170 Depending on the payload, RTP timestamp synchronization may not be 171 sufficient to completely reconstruct the order in which packets sent 172 over several RTP sessions need to be decoded. In such cases, the 173 payload definition needs to specify how the decoding order of packets 174 is reconstructed. 176 Difficulties particularly arise if if a payload allows packets with a 177 given timestamp to be omitted on some sessions; if a payload has non- 178 trivial decoding order constraints for media with the same timestamp; 179 or if a payload supports a transmission order different from its 180 timestamp order, as is common with video formats. 182 7. Security Considerations 184 For [RFC3550]-style packet encryption, RTP timestamp randomization 185 contributes to a "weak initialization vector" for encrypted packets. 186 In particular, the timestamp, sequence number, and SSRC together 187 provide randomness to a session. 189 However, when timestamps and sequence numbers are aligned across 190 multiple sessions, for many payloads sequence numbers will also align 191 periodically (if packets are sent at different rates on each 192 session.) This introduces a weakness which can allow an attacker to 193 launch "two-time-pad" attacks against the bitstream. Thus, if 194 [RFC3550]-style RTP packet encryption is used to protect a layered 195 encoding, different encryption keys MUST be used on each RTP session 196 of the layered encoding. 198 For Secure RTP (SRTP) [RFC3711], similarly, a different SRTP master 199 key MUST be used for each RTP session. The key management mechanisms 200 Secure Descriptions for SDP [RFC4568], Key Management Extensions for 201 SDP and RTSP [RFC4567] combined with MIKEY [RFC3830], DTLS-SRTP 202 [I-D.ietf-sip-dtls-srtp-framework], and ZRTP 203 [I-D.zimmermann-avt-zrtp] all satisfy this requirement. 205 8. IANA Considerations 207 No action by IANA is required. 209 9. References 211 9.1. Normative References 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 217 Jacobson, "RTP: A Transport Protocol for Real-Time 218 Applications", STD 64, RFC 3550, July 2003. 220 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 221 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 222 RFC 3711, March 2004. 224 9.2. Informative References 226 [I-D.ietf-sip-dtls-srtp-framework] 227 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 228 for Establishing an SRTP Security Context using DTLS", 229 draft-ietf-sip-dtls-srtp-framework-01 (work in progress), 230 February 2008. 232 [I-D.speer-avt-layered-video] 233 Speer, M. and S. McCanne, "RTP usage with Layered 234 Multimedia Streams", draft-speer-avt-layered-video-05 235 (work in progress), June 1997. 237 Expired draft. 239 [I-D.zimmermann-avt-zrtp] 240 Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 241 Path Key Agreement for Secure RTP", 242 draft-zimmermann-avt-zrtp-06 (work in progress), 243 March 2008. 245 [McCa96] McCanne, S., "Scalable Compression and Transmission of 246 Internet Multicast Video", Report No. UCB/CSD-96-928, 247 December 1996. 249 Ph.D. Dissertation, University of California Berkeley. 251 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 252 Jacobson, "RTP: A Transport Protocol for Real-Time 253 Applications", RFC 1889, January 1996. 255 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 256 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 257 August 2004. 259 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 260 Carrara, "Key Management Extensions for Session 261 Description Protocol (SDP) and Real Time Streaming 262 Protocol (RTSP)", RFC 4567, July 2006. 264 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 265 Description Protocol (SDP) Security Descriptions for Media 266 Streams", RFC 4568, July 2006. 268 [VIC] McCanne, S. and V. Jacobson, "vic: A Flexible Framework 269 for Packet Video", 1995. 271 ACM Multimedia, pp. 511-522 273 Authors' Addresses 275 Jonathan Lennox 276 Vidyo, Inc. 277 433 Hackensack Avenue 278 Sixth Floor 279 Hackensack, NJ 07601 280 US 282 Email: jonathan@vidyo.com 284 Thomas Schierl 285 Fraunhofer HHI 286 Einsteinufer 37 287 D-10587 Berlin 288 Germany 290 Phone: +49-30-31002-227 291 Email: schierl@hhi.fhg.de 293 Sam Ganesan 294 Motorola 295 80 Central Street 296 Boxborough, MA 01719 297 US 299 Email: sam.ganesan@motorola.com 301 Full Copyright Statement 303 Copyright (C) The IETF Trust (2008). 305 This document is subject to the rights, licenses and restrictions 306 contained in BCP 78, and except as set forth therein, the authors 307 retain all their rights. 309 This document and the information contained herein are provided on an 310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 312 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 313 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 314 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 317 Intellectual Property 319 The IETF takes no position regarding the validity or scope of any 320 Intellectual Property Rights or other rights that might be claimed to 321 pertain to the implementation or use of the technology described in 322 this document or the extent to which any license under such rights 323 might or might not be available; nor does it represent that it has 324 made any independent effort to identify any such rights. Information 325 on the procedures with respect to rights in RFC documents can be 326 found in BCP 78 and BCP 79. 328 Copies of IPR disclosures made to the IETF Secretariat and any 329 assurances of licenses to be made available, or the result of an 330 attempt made to obtain a general license or permission for the use of 331 such proprietary rights by implementers or users of this 332 specification can be obtained from the IETF on-line IPR repository at 333 http://www.ietf.org/ipr. 335 The IETF invites any interested party to bring to its attention any 336 copyrights, patents or patent applications, or other proprietary 337 rights that may cover technology that may be required to implement 338 this standard. Please address the information to the IETF at 339 ietf-ipr@ietf.org.