draft-ietf-avt-rtp-framing-contrans-02.txt   draft-ietf-avt-rtp-framing-contrans-03.txt 
INTERNET-DRAFT John Lazzaro INTERNET-DRAFT John Lazzaro
June 24, 2004 CS Division July 2, 2004 CS Division
Expires: December 24, 2004 UC Berkeley Expires: January 2, 2005 UC Berkeley
Framing RTP and RTCP Packets over Connection-Oriented Transport Framing RTP and RTCP Packets over Connection-Oriented Transport
<draft-ietf-avt-rtp-framing-contrans-02.txt> <draft-ietf-avt-rtp-framing-contrans-03.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable patent By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668. which I become aware will be disclosed, in accordance with RFC 3668.
By submitting this Internet-Draft, I accept the provisions of Section 3 By submitting this Internet-Draft, I accept the provisions of Section 3
of RFC 3667 (BCP 78). of RFC 3667 (BCP 78).
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 24, 2004. This Internet-Draft will expire on January 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo defines a method for framing Real Time Protocol (RTP) and This memo defines a method for framing Real Time Protocol (RTP) and
Real Time Control Protocol (RTCP) packets onto connection-oriented Real Time Control Protocol (RTCP) packets onto connection-oriented
transport (such as TCP). The memo also defines how to specify the transport (such as TCP). The memo also defines how to specify the
skipping to change at page 2, line 22 skipping to change at page 2, line 22
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 6 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 6
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
B. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 B. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6
C. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 7 C. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 7
D. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 D. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
D.1 Normative References . . . . . . . . . . . . . . . . . . . 7 D.1 Normative References . . . . . . . . . . . . . . . . . . . 7
E. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 8 E. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 8
F. Intellectual Property Rights Statement . . . . . . . . . . . . . 8 F. Intellectual Property Rights Statement . . . . . . . . . . . . . 8
G. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 G. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8
H. Change Log for <draft-ietf-avt-rtp-framing-contrans-02.txt> . . . 10 H. Change Log for <draft-ietf-avt-rtp-framing-contrans-03.txt> . . . 10
1. Introduction 1. Introduction
The Audio/Video Profile (AVP, [1]) for the Real-Time Protocol (RTP, [2]) The Audio/Video Profile (AVP, [1]) for the Real-Time Protocol (RTP, [2])
does not define a method for framing RTP and Real Time Control Protocol does not define a method for framing RTP and Real Time Control Protocol
(RTCP) packets onto connection-oriented transport protocols (such as (RTCP) packets onto connection-oriented transport protocols (such as
TCP). However, earlier versions of RTP/AVP did define a framing method, TCP). However, earlier versions of RTP/AVP did define a framing method,
and this method is in use in several implementations. and this method is in use in several implementations.
In this memo, we document the method and show how a session description In this memo, we document the method and show how a session description
[4] may specify the use of the method. [4] may specify the use of the method.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [11]. document are to be interpreted as described in BCP 14, RFC 2119 [5].
2. The Framing Method 2. The Framing Method
Figure 1 defines the framing method. Figure 1 defines the framing method.
0 1 2 3 0 1 2 3
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 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
--------------------------------------------------------------- ---------------------------------------------------------------
| LENGTH | RTP or RTCP packet ... | | LENGTH | RTP or RTCP packet ... |
--------------------------------------------------------------- ---------------------------------------------------------------
skipping to change at page 4, line 36 skipping to change at page 4, line 36
In this section, we show how session descriptions may specify RTP In this section, we show how session descriptions may specify RTP
streams that use the framing method. streams that use the framing method.
Figure 2 shows the syntax of a media (m=) line [4] of a session Figure 2 shows the syntax of a media (m=) line [4] of a session
description: description:
"m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF "m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF
Figure 2 -- Syntax for an SDP media (m=) line (from [4]). Figure 2 -- Syntax for an SDP media (m=) line (from [4]).
To specify an RTP/AVP [1] [2] stream that uses the framing method over The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [1] [2]
TCP, the <proto> token MUST be set to "TCP/RTP/AVP". To specify a stream that uses the framing method over TCP.
Secure Real Time Protocol [6] stream that uses the framing method over
TCP, the <proto> token MUST be set to "TCP/RTP/SAVP".
The <fmt> tokens that follow <proto> MUST be unique unsigned integers in The <fmt> tokens that follow <proto> MUST be unique unsigned integers in
the range 0 to 127. The <fmt> tokens specify an RTP payload type the range 0 to 127. The <fmt> tokens specify an RTP payload type
associated with the stream. associated with the stream.
In all other respects, the session description syntax for the framing In all other respects, the session description syntax for the framing
method is identical to [3]. method is identical to [3].
The TCP <port> on the media line exclusively receives RTP packets. If a The TCP <port> on the media line exclusively receives RTP packets. If a
media stream uses RTCP, a second connection exclusively receives the media stream uses RTCP, a second connection exclusively receives the
RTCP packets. The port for the RTCP connection is chosen using the RTCP packets. The port for the RTCP connection is chosen using the
algorithms defined in [4] and in related documents. algorithms defined in [4] and in related documents.
The TCP connections MAY carry bi-directional traffic, following the The TCP connections MAY carry bi-directional traffic, following the
semantics defined in [3]. Both directions of a connection MUST carry semantics defined in [3]. Both directions of a connection MUST carry
the same type of packets (RTP or RTCP). The packets MUST exclusively the same type of packets (RTP or RTCP). The packets MUST exclusively
code the RTP or RTCP streams specified on the media line(s) associated code the RTP or RTCP streams specified on the media line(s) associated
with the connection. with the connection.
The RTP stream MUST have an unbroken sequence number order. RTCP stream The RTP stream MUST have an unbroken sequence number order. RTCP stream
packets MUST appear as defined in [2], with no lost or re-ordered packets MUST appear as defined in [2], with no lost or re-ordered
skipping to change at page 7, line 4 skipping to change at page 6, line 48
A. Acknowledgements A. Acknowledgements
This memo, in part, documents discussions on the AVT mailing list about This memo, in part, documents discussions on the AVT mailing list about
TCP and RTP. Thanks to all of the participants in these discussions. TCP and RTP. Thanks to all of the participants in these discussions.
B. Security Considerations B. Security Considerations
Implementors should carefully read the Security Considerations sections Implementors should carefully read the Security Considerations sections
of the RTP [1] and RTP/AVP [2] documents, as most of the issues of the RTP [1] and RTP/AVP [2] documents, as most of the issues
discussed in these sections directly apply to RTP streams framed over discussed in these sections directly apply to RTP streams framed over
TCP. Implementors should also review the Secure Real-time Transport TCP.
Protocol (SRTP, [6]), an RTP profile that addresses the security issues
discussed in [1] [2].
Below, we discuss security issues that are unique to the framing method. Session descriptions that specify connection-oriented media sessions
(such as the example session shown in Figures 3-4 of Section 5) raise
unique security concerns for streaming media. The Security
Considerations section of [3] describes these issues in detail.
Below, we discuss security issues that are unique to the framing method
defined in Section 2.
Attackers may send framed packets with large LENGTH values, to exploit Attackers may send framed packets with large LENGTH values, to exploit
security holes in applications. For example, a C implementation may security holes in applications. For example, a C implementation may
declare a 1500-byte array as a stack variable, and use LENGTH as the declare a 1500-byte array as a stack variable, and use LENGTH as the
bound on the loop that reads the framed packet into the array. This bound on the loop that reads the framed packet into the array. This
code would work fine for friendly applications that use Etherframe-sized code would work fine for friendly applications that use Etherframe-sized
RTP packets, but may be open to exploit by an attacker. RTP packets, but may be open to exploit by an attacker.
In addition to security issues related to RTP packet transport, there
are also security issues that concern the session descriptions of
connection-oriented media sessions. The security considerations section
of [3] describe these issues in detail.
C. IANA Considerations C. IANA Considerations
[4] defines the syntax of session description media lines. We reproduce [4] defines the syntax of session description media lines. We reproduce
this definition in Figure 2 of Section 4 of this memo. In Section 4, we this definition in Figure 2 of Section 4 of this memo. In Section 4, we
define two new token values for the <proto> field of media lines: define a new token value for the <proto> field of media lines:
"TCP/RTP/AVP" and "TCP/RTP/SAVP". Section 4 specifies the semantics "TCP/RTP/AVP". Section 4 specifies the semantics associated with the
associated with the <proto> field tokens, and Section 5 shows an example <proto> field token, and Section 5 shows an example of its use in a
of its use in a session description. session description.
D. References D. References
D.1 Normative References D.1 Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson.
"RTP: A transport protocol for real-time applications", RFC 3550, July "RTP: A transport protocol for real-time applications", RFC 3550, July
2003. 2003.
[2] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video [2] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video
skipping to change at page 8, line 8 skipping to change at page 8, line 5
[3] Yon, D. and G. Camarillo. Connection-Oriented Media Transport in [3] Yon, D. and G. Camarillo. Connection-Oriented Media Transport in
the Session Description Protocol (SDP), the Session Description Protocol (SDP),
draft-ietf-mmusic-sdp-comedia-07.txt. draft-ietf-mmusic-sdp-comedia-07.txt.
[4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session [4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-18.txt. Description Protocol", draft-ietf-mmusic-sdp-new-18.txt.
[5] Bradner, S. "Key words for use in RFCs to Indicate Requirement [5] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman.
"The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
E. Authors' Address E. Authors' Address
John Lazzaro John Lazzaro
UC Berkeley UC Berkeley
CS Division CS Division
315 Soda Hall 315 Soda Hall
Berkeley CA 94720-1776 Berkeley CA 94720-1776
Email: lazzaro@cs.berkeley.edu Email: lazzaro@cs.berkeley.edu
F. Intellectual Property Rights Statement F. Intellectual Property Rights Statement
skipping to change at page 9, line 12 skipping to change at page 9, line 4
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
H. Change Log for <draft-ietf-avt-rtp-framing-contrans-02.txt> H. Change Log for <draft-ietf-avt-rtp-framing-contrans-03.txt>
[Note to RFC Editors: this Appendix, and its Table of Contents listing, [Note to RFC Editors: this Appendix, and its Table of Contents listing,
should be removed from the final version of the memo] should be removed from the final version of the memo]
Section 4-5 and Appendix C have been rewritten to conform to the changes The "TCP/RTP/SAVP" <proto> token value has been removed from the draft.
in draft-ietf-mmusic-sdp-comedia-07.txt. Added a Congestion Control
section, and rewrote Security Considerations.
The "Status of this Memo", "Intellectual Property Rights Statement", and
"Full Copyright" now use the RFC 3667/3668 conventions. The document
passes idnits, modulo bugs in the script.
The major unresolved issue concerns the inclusion of "TCP/RTP/SAVP" as a
<proto> token to support SRTP. We do this in Section 4. Does this
inclusion bring up the same sort of controversies that resulted in TLS's
removal from draft-ietf-mmusic-sdp-comedia-07.txt? If so, should we
face into those controversies, or should we remove "TCP/RTP/SAVP" from
this document? Comments welcome.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/