idnits 2.17.1 draft-ietf-avt-rtp-framing-contrans-03.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 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 337. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 343), 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 289 looks like a reference -- Missing reference section? '2' on line 293 looks like a reference -- Missing reference section? '4' on line 300 looks like a reference -- Missing reference section? '5' on line 303 looks like a reference -- Missing reference section? '3' on line 296 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John Lazzaro 3 July 2, 2004 CS Division 4 Expires: January 2, 2005 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 January 2, 2005. 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 [5]. 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 The token value "TCP/RTP/AVP" specifies an RTP/AVP [1] [2] 159 stream that uses the framing method over TCP. 161 The tokens that follow MUST be unique unsigned integers in 162 the range 0 to 127. The tokens specify an RTP payload type 163 associated with the stream. 165 In all other respects, the session description syntax for the framing 166 method is identical to [3]. 168 The TCP on the media line exclusively receives RTP packets. If a 169 media stream uses RTCP, a second connection exclusively receives the 170 RTCP packets. The port for the RTCP connection is chosen using the 171 algorithms defined in [4] and in related documents. 173 The TCP connections MAY carry bi-directional traffic, following the 174 semantics defined in [3]. Both directions of a connection MUST carry 175 the same type of packets (RTP or RTCP). The packets MUST exclusively 176 code the RTP or RTCP streams specified on the media line(s) associated 177 with the connection. 179 The RTP stream MUST have an unbroken sequence number order. RTCP stream 180 packets MUST appear as defined in [2], with no lost or re-ordered 181 packets. IETF standards-track documents MAY loosen these restrictions 182 on packet loss and packet ordering. 184 The out-of-band semantics for the connection MUST comply with [3]. 186 5. Example 188 The session descriptions in Figure 3-4 define a TCP RTP/AVT session. 190 v=0 191 o=first 2520644554 2838152170 IN IP4 first.example.net 192 s=Example 193 t=0 0 194 c=IN IP4 192.0.2.105 195 m=audio 9 TCP/RTP/AVP 11 196 a=setup:active 197 a=connid:1 199 Figure 3 -- TCP session description for first participant. 201 v=0 202 o=second 2520644554 2838152170 IN IP4 second.example.net 203 s=Example 204 t=0 0 205 c=IN IP4 192.0.2.94 206 m=audio 16112 TCP/RTP/AVP 10 11 207 a=setup:passive 208 a=connid:1 210 Figure 4 -- TCP session description for second participant. 212 The session descriptions define two parties that participate in a 213 connection-oriented RTP/AVP session. The first party (Figure 3) is 214 capable of receiving stereo L16 streams (static payload type 11). The 215 second party (Figure 4) is capable of receiving mono (static payload 216 type 10) or stereo L16 streams. 218 The "setup" attribute in Figure 3 specifies that the first party is 219 "active" and initiates connections, and the "setup" attribute in Figure 220 4 specifies that the second party is "passive" and accepts connections 221 [3]. 223 The first party connects to the network address (192.0.2.94) and port 224 (16112) of the second party. Once the connection is established, it is 225 used bi-directionally: the first party sends framed RTP packets to the 226 second party on one direction of the connection, and the second party 227 sends framed RTP packets to the first party in the other direction of 228 the connection. 230 The first party also initiates an RTCP TCP connection to port 16113 231 (16112 + 1, as defined in [4]) of the second party. Once the connection 232 is established, the first party sends framed RTCP packets to the second 233 party on one direction of the connection, and the second party sends 234 framed RTCP packets to the first party in the other direction of the 235 connection. 237 6. Congestion Control 239 The RTP congestion control requirements are defined in [1]. As noted in 240 [1], all transport protocols used on the Internet need to address 241 congestion control in some way, and RTP is not an exception. 243 In addition, the congestion control requirements for the Audio/Video 244 Profile are defined in [2]. The basic congestion control requirement 245 defined in [2] is that RTP sessions should compete fairly with TCP flows 246 that share the network. As the framing method uses TCP, it competes 247 fairly with other TCP flows by definition. 249 A. Acknowledgements 251 This memo, in part, documents discussions on the AVT mailing list about 252 TCP and RTP. Thanks to all of the participants in these discussions. 254 B. Security Considerations 256 Implementors should carefully read the Security Considerations sections 257 of the RTP [1] and RTP/AVP [2] documents, as most of the issues 258 discussed in these sections directly apply to RTP streams framed over 259 TCP. 261 Session descriptions that specify connection-oriented media sessions 262 (such as the example session shown in Figures 3-4 of Section 5) raise 263 unique security concerns for streaming media. The Security 264 Considerations section of [3] describes these issues in detail. 266 Below, we discuss security issues that are unique to the framing method 267 defined in Section 2. 269 Attackers may send framed packets with large LENGTH values, to exploit 270 security holes in applications. For example, a C implementation may 271 declare a 1500-byte array as a stack variable, and use LENGTH as the 272 bound on the loop that reads the framed packet into the array. This 273 code would work fine for friendly applications that use Etherframe-sized 274 RTP packets, but may be open to exploit by an attacker. 276 C. IANA Considerations 278 [4] defines the syntax of session description media lines. We reproduce 279 this definition in Figure 2 of Section 4 of this memo. In Section 4, we 280 define a new token value for the field of media lines: 281 "TCP/RTP/AVP". Section 4 specifies the semantics associated with the 282 field token, and Section 5 shows an example of its use in a 283 session description. 285 D. References 287 D.1 Normative References 289 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. 290 "RTP: A transport protocol for real-time applications", RFC 3550, July 291 2003. 293 [2] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video 294 Conferences with Minimal Control", RFC 3551, July 2003. 296 [3] Yon, D. and G. Camarillo. Connection-Oriented Media Transport in 297 the Session Description Protocol (SDP), 298 draft-ietf-mmusic-sdp-comedia-07.txt. 300 [4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session 301 Description Protocol", draft-ietf-mmusic-sdp-new-18.txt. 303 [5] Bradner, S. "Key words for use in RFCs to Indicate Requirement 304 Levels", BCP 14, RFC 2119, March 1997. 306 E. Authors' Address 308 John Lazzaro 309 UC Berkeley 310 CS Division 311 315 Soda Hall 312 Berkeley CA 94720-1776 313 Email: lazzaro@cs.berkeley.edu 315 F. Intellectual Property Rights Statement 317 The IETF takes no position regarding the validity or scope of any 318 Intellectual Property Rights or other rights that might be claimed to 319 pertain to the implementation or use of the technology described in this 320 document or the extent to which any license under such rights might or 321 might not be available; nor does it represent that it has made any 322 independent effort to identify any such rights. Information on the 323 procedures with respect to rights in RFC documents can be found in BCP 324 78 and BCP 79. 326 Copies of IPR disclosures made to the IETF Secretariat and any 327 assurances of licenses to be made available, or the result of an attempt 328 made to obtain a general license or permission for the use of such 329 proprietary rights by implementers or users of this specification can be 330 obtained from the IETF on-line IPR repository at 331 http://www.ietf.org/ipr. 333 The IETF invites any interested party to bring to its attention any 334 copyrights, patents or patent applications, or other proprietary rights 335 that may cover technology that may be required to implement this 336 standard. Please address the information to the IETF at ietf- 337 ipr@ietf.org. 339 G. Full Copyright Statement 341 Copyright (C) The Internet Society (2004). This document is subject to 342 the rights, licenses and restrictions contained in BCP 78, and except as 343 set forth therein, the authors retain all their rights. 345 This document and the information contained herein are provided 346 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 347 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 348 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 349 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 350 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 351 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 352 PARTICULAR PURPOSE. 354 Acknowledgement 356 Funding for the RFC Editor function is currently provided by the 357 Internet Society. 359 H. Change Log for 361 [Note to RFC Editors: this Appendix, and its Table of Contents listing, 362 should be removed from the final version of the memo] 364 The "TCP/RTP/SAVP" token value has been removed from the draft.