idnits 2.17.1 draft-ietf-avt-rtp-framing-contrans-02.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 343. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 349), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '1' on line 292 looks like a reference -- Missing reference section? '2' on line 296 looks like a reference -- Missing reference section? '4' on line 303 looks like a reference -- Missing reference section? '11' on line 82 looks like a reference -- Missing reference section? '6' on line 309 looks like a reference -- Missing reference section? '3' on line 299 looks like a reference -- Missing reference section? '5' on line 306 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John Lazzaro 3 June 24, 2004 CS Division 4 Expires: December 24, 2004 UC Berkeley 6 Framing RTP and RTCP Packets over Connection-Oriented Transport 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable patent 13 or other IPR claims of which I am aware have been disclosed, and any of 14 which I become aware will be disclosed, in accordance with RFC 3668. 16 By submitting this Internet-Draft, I accept the provisions of Section 3 17 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 24, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This memo defines a method for framing Real Time Protocol (RTP) and 43 Real Time Control Protocol (RTCP) packets onto connection-oriented 44 transport (such as TCP). The memo also defines how to specify the 45 framing method in a session description. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. The Framing Method . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Undefined Properties . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Session Descriptions for RTP/AVP over TCP . . . . . . . . . . . . 4 54 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 6 56 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 57 B. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 C. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 7 59 D. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 D.1 Normative References . . . . . . . . . . . . . . . . . . . 7 61 E. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 8 62 F. Intellectual Property Rights Statement . . . . . . . . . . . . . 8 63 G. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 64 H. Change Log for . . . 10 66 1. Introduction 68 The Audio/Video Profile (AVP, [1]) for the Real-Time Protocol (RTP, [2]) 69 does not define a method for framing RTP and Real Time Control Protocol 70 (RTCP) packets onto connection-oriented transport protocols (such as 71 TCP). However, earlier versions of RTP/AVP did define a framing method, 72 and this method is in use in several implementations. 74 In this memo, we document the method and show how a session description 75 [4] may specify the use of the method. 77 1.1 Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in BCP 14, RFC 2119 [11]. 83 2. The Framing Method 85 Figure 1 defines the framing method. 87 0 1 2 3 88 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 89 --------------------------------------------------------------- 90 | LENGTH | RTP or RTCP packet ... | 91 --------------------------------------------------------------- 93 Figure 1 -- The bitfield definition of the framing method. 95 A 16-bit unsigned integer LENGTH field, coded in network byte order 96 (big-endian), begins the frame. If LENGTH is non-zero, an RTP or RTCP 97 packet follows the LENGTH field. The value coded in the LENGTH field 98 MUST equal the number of octets in the RTP or RTCP packet. Zero is a 99 valid value for LENGTH, and codes the null packet. 101 This framing method does not use frame markers (i.e. an octet of 102 constant value that would precede the LENGTH field). Frame markers are 103 useful for detecting errors in the LENGTH field. In lieu of a frame 104 marker, receivers SHOULD monitor the RTP and RTCP header fields whose 105 values are predictable (for example, the RTP version number). 107 3. Undefined Properties 109 The framing method does not specify properties above the level of a 110 single packet. In particular, Section 2 does not specify: 112 The number of RTP or RTCP streams on the connection. 114 The framing method is commonly used for sending a single 115 RTP or RTCP stream over a connection. However, Section 116 2 does not define this common use as normative, so that 117 (for example) a memo that defines an RTP SSRC multiplexing 118 protocol may use the framing method. 120 Bi-directional issues. 122 Section 2 defines a framing method for use in one direction 123 on a connection. The relationship between framed packets 124 flowing in defined direction and in the reverse direction is 125 not specified. 127 Packet loss and reordering. 129 The reliable nature of a connection does not imply that a 130 framed RTP stream has a contiguous sequence number ordering. 131 For example, if the connection is used to tunnel a UDP stream 132 through a network middlebox that only passes TCP, the sequence 133 numbers in the framed stream reflect any packet loss or 134 reordering on the UDP portion of the end-to-end flow. 136 Out-of-band semantics. 138 Section 2 does not define the RTP or RTCP semantics for closing 139 a TCP socket, or of any other "out of band" signal for the 140 connection. 142 Memos that normatively include the framing method MAY specify these 143 properties. For example, Section 4 of this memo specifies these 144 properties for RTP sessions specified in session descriptions. 146 4. Session Descriptions for RTP/AVP over TCP 148 In this section, we show how session descriptions may specify RTP 149 streams that use the framing method. 151 Figure 2 shows the syntax of a media (m=) line [4] of a session 152 description: 154 "m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF 156 Figure 2 -- Syntax for an SDP media (m=) line (from [4]). 158 To specify an RTP/AVP [1] [2] stream that uses the framing method over 159 TCP, the token MUST be set to "TCP/RTP/AVP". To specify a 160 Secure Real Time Protocol [6] stream that uses the framing method over 161 TCP, the token MUST be set to "TCP/RTP/SAVP". 163 The tokens that follow MUST be unique unsigned integers in 164 the range 0 to 127. The tokens specify an RTP payload type 165 associated with the stream. 167 In all other respects, the session description syntax for the framing 168 method is identical to [3]. 170 The TCP on the media line exclusively receives RTP packets. If a 171 media stream uses RTCP, a second connection exclusively receives the 172 RTCP packets. The port for the RTCP connection is chosen using the 173 algorithms defined in [4] and in related documents. 175 The TCP connections MAY carry bi-directional traffic, following the 176 semantics defined in [3]. Both directions of a connection MUST carry 177 the same type of packets (RTP or RTCP). The packets MUST exclusively 178 code the RTP or RTCP streams specified on the media line(s) associated 179 with the connection. 181 The RTP stream MUST have an unbroken sequence number order. RTCP stream 182 packets MUST appear as defined in [2], with no lost or re-ordered 183 packets. IETF standards-track documents MAY loosen these restrictions 184 on packet loss and packet ordering. 186 The out-of-band semantics for the connection MUST comply with [3]. 188 5. Example 190 The session descriptions in Figure 3-4 define a TCP RTP/AVT session. 192 v=0 193 o=first 2520644554 2838152170 IN IP4 first.example.net 194 s=Example 195 t=0 0 196 c=IN IP4 192.0.2.105 197 m=audio 9 TCP/RTP/AVP 11 198 a=setup:active 199 a=connid:1 201 Figure 3 -- TCP session description for first participant. 203 v=0 204 o=second 2520644554 2838152170 IN IP4 second.example.net 205 s=Example 206 t=0 0 207 c=IN IP4 192.0.2.94 208 m=audio 16112 TCP/RTP/AVP 10 11 209 a=setup:passive 210 a=connid:1 212 Figure 4 -- TCP session description for second participant. 214 The session descriptions define two parties that participate in a 215 connection-oriented RTP/AVP session. The first party (Figure 3) is 216 capable of receiving stereo L16 streams (static payload type 11). The 217 second party (Figure 4) is capable of receiving mono (static payload 218 type 10) or stereo L16 streams. 220 The "setup" attribute in Figure 3 specifies that the first party is 221 "active" and initiates connections, and the "setup" attribute in Figure 222 4 specifies that the second party is "passive" and accepts connections 223 [3]. 225 The first party connects to the network address (192.0.2.94) and port 226 (16112) of the second party. Once the connection is established, it is 227 used bi-directionally: the first party sends framed RTP packets to the 228 second party on one direction of the connection, and the second party 229 sends framed RTP packets to the first party in the other direction of 230 the connection. 232 The first party also initiates an RTCP TCP connection to port 16113 233 (16112 + 1, as defined in [4]) of the second party. Once the connection 234 is established, the first party sends framed RTCP packets to the second 235 party on one direction of the connection, and the second party sends 236 framed RTCP packets to the first party in the other direction of the 237 connection. 239 6. Congestion Control 241 The RTP congestion control requirements are defined in [1]. As noted in 242 [1], all transport protocols used on the Internet need to address 243 congestion control in some way, and RTP is not an exception. 245 In addition, the congestion control requirements for the Audio/Video 246 Profile are defined in [2]. The basic congestion control requirement 247 defined in [2] is that RTP sessions should compete fairly with TCP flows 248 that share the network. As the framing method uses TCP, it competes 249 fairly with other TCP flows by definition. 251 A. Acknowledgements 253 This memo, in part, documents discussions on the AVT mailing list about 254 TCP and RTP. Thanks to all of the participants in these discussions. 256 B. Security Considerations 258 Implementors should carefully read the Security Considerations sections 259 of the RTP [1] and RTP/AVP [2] documents, as most of the issues 260 discussed in these sections directly apply to RTP streams framed over 261 TCP. Implementors should also review the Secure Real-time Transport 262 Protocol (SRTP, [6]), an RTP profile that addresses the security issues 263 discussed in [1] [2]. 265 Below, we discuss security issues that are unique to the framing method. 267 Attackers may send framed packets with large LENGTH values, to exploit 268 security holes in applications. For example, a C implementation may 269 declare a 1500-byte array as a stack variable, and use LENGTH as the 270 bound on the loop that reads the framed packet into the array. This 271 code would work fine for friendly applications that use Etherframe-sized 272 RTP packets, but may be open to exploit by an attacker. 274 In addition to security issues related to RTP packet transport, there 275 are also security issues that concern the session descriptions of 276 connection-oriented media sessions. The security considerations section 277 of [3] describe these issues in detail. 279 C. IANA Considerations 281 [4] defines the syntax of session description media lines. We reproduce 282 this definition in Figure 2 of Section 4 of this memo. In Section 4, we 283 define two new token values for the field of media lines: 284 "TCP/RTP/AVP" and "TCP/RTP/SAVP". Section 4 specifies the semantics 285 associated with the field tokens, and Section 5 shows an example 286 of its use in a session description. 288 D. References 290 D.1 Normative References 292 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. 293 "RTP: A transport protocol for real-time applications", RFC 3550, July 294 2003. 296 [2] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video 297 Conferences with Minimal Control", RFC 3551, July 2003. 299 [3] Yon, D. and G. Camarillo. Connection-Oriented Media Transport in 300 the Session Description Protocol (SDP), 301 draft-ietf-mmusic-sdp-comedia-07.txt. 303 [4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session 304 Description Protocol", draft-ietf-mmusic-sdp-new-18.txt. 306 [5] Bradner, S. "Key words for use in RFCs to Indicate Requirement 307 Levels", BCP 14, RFC 2119, March 1997. 309 [6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman. 310 "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 312 E. Authors' Address 314 John Lazzaro 315 UC Berkeley 316 CS Division 317 315 Soda Hall 318 Berkeley CA 94720-1776 319 Email: lazzaro@cs.berkeley.edu 321 F. Intellectual Property Rights Statement 323 The IETF takes no position regarding the validity or scope of any 324 Intellectual Property Rights or other rights that might be claimed to 325 pertain to the implementation or use of the technology described in this 326 document or the extent to which any license under such rights might or 327 might not be available; nor does it represent that it has made any 328 independent effort to identify any such rights. Information on the 329 procedures with respect to rights in RFC documents can be found in BCP 330 78 and BCP 79. 332 Copies of IPR disclosures made to the IETF Secretariat and any 333 assurances of licenses to be made available, or the result of an attempt 334 made to obtain a general license or permission for the use of such 335 proprietary rights by implementers or users of this specification can be 336 obtained from the IETF on-line IPR repository at 337 http://www.ietf.org/ipr. 339 The IETF invites any interested party to bring to its attention any 340 copyrights, patents or patent applications, or other proprietary rights 341 that may cover technology that may be required to implement this 342 standard. Please address the information to the IETF at ietf- 343 ipr@ietf.org. 345 G. Full Copyright Statement 347 Copyright (C) The Internet Society (2004). This document is subject to 348 the rights, licenses and restrictions contained in BCP 78, and except as 349 set forth therein, the authors retain all their rights. 351 This document and the information contained herein are provided 352 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 353 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 355 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 356 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 357 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 358 PARTICULAR PURPOSE. 360 Acknowledgement 362 Funding for the RFC Editor function is currently provided by the 363 Internet Society. 365 H. Change Log for 367 [Note to RFC Editors: this Appendix, and its Table of Contents listing, 368 should be removed from the final version of the memo] 370 Section 4-5 and Appendix C have been rewritten to conform to the changes 371 in draft-ietf-mmusic-sdp-comedia-07.txt. Added a Congestion Control 372 section, and rewrote Security Considerations. 374 The "Status of this Memo", "Intellectual Property Rights Statement", and 375 "Full Copyright" now use the RFC 3667/3668 conventions. The document 376 passes idnits, modulo bugs in the script. 378 The major unresolved issue concerns the inclusion of "TCP/RTP/SAVP" as a 379 token to support SRTP. We do this in Section 4. Does this 380 inclusion bring up the same sort of controversies that resulted in TLS's 381 removal from draft-ietf-mmusic-sdp-comedia-07.txt? If so, should we 382 face into those controversies, or should we remove "TCP/RTP/SAVP" from 383 this document? Comments welcome.