[MMUSIC] [Technical Errata Reported] RFC2326 (4199)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC2326,
"Real Time Streaming Protocol (RTSP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=2326&eid=4199

--------------------------------------
Type: Technical
Reported by: Julius Friedman <[e-mail]>

Section: 4

Original Text
-------------
4 RTSP Message

   RTSP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but
   receivers should be prepared to also interpret CR and LF by
   themselves as line terminators.

     Text-based protocols make it easier to add optional parameters in a
     self-describing manner. Since the number of parameters and the
     frequency of commands is low, processing efficiency is not a
     concern. Text-based protocols, if done carefully, also allow easy
     implementation of research prototypes in scripting languages such
     as Tcl, Visual Basic and Perl.

     The 10646 character set avoids tricky character set switching, but
     is invisible to the application as long as US-ASCII is being used.
     This is also the encoding used for RTCP. ISO 8859-1 translates
     directly into Unicode with a high-order octet of zero. ISO 8859-1
     characters with the most-significant bit set are represented as
     1100001x 10xxxxxx. (See RFC 2279 [21])

   RTSP messages can be carried over any lower-layer transport protocol
   that is 8-bit clean.

   Requests contain methods, the object the method is operating upon and
   parameters to further describe the method. Methods are idempotent,
   unless otherwise noted. Methods are also designed to require little
   or no state maintenance at the media server.

Corrected Text
--------------


4 RTSP Message

   RTSP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but
   receivers should be prepared to also interpret CR and LF by
   themselves as line terminators.

     Text-based protocols make it easier to add optional parameters in a
     self-describing manner. Since the number of parameters and the
     frequency of commands is low, processing efficiency is not a
     concern. Text-based protocols, if done carefully, also allow easy
     implementation of research prototypes in scripting languages such
     as Tcl, Visual Basic and Perl.

     The 10646 character set avoids tricky character set switching, but
     is invisible to the application as long as US-ASCII is being used.
     This is also the encoding used for RTCP. ISO 8859-1 translates
     directly into Unicode with a high-order octet of zero. ISO 8859-1
     characters with the most-significant bit set are represented as
     1100001x 10xxxxxx. (See RFC 2279 [21])

   RTSP messages can be carried over any lower-layer transport protocol
   that is 8-bit clean.

   Requests contain methods, the object the method is operating upon and
   parameters to further describe the method. Methods are idempotent,
   unless otherwise noted. Methods are also designed to require little
   or no state maintenance at the media server.

*Please note the hexadecimal octet 0x36 should not be included in any 
part of a RTSP message, if present it should be replaced with binary 
escaped sequence as defined in: <consensus>*.

Notes
-----
Section [15.1 Base Syntax] makes the following definitions:
..
safe               =  "$" | "-" | "_" | "." | "+"
..
reserved           =  ";" | "/" | "?" | ":" | "@" | "&" | "="
extra              =  "!" | "*" | "$'$" | "(" | ")" | ","
unreserved         =  alpha | digit | safe | extra
xchar              =  unreserved | reserved | escape

However it doesn't explicitly state the association of "$" [hexadecimal 0x24]

Section [10.12 Embedded (Interleaved) Binary Data] specified a mechanism of transferring RTSP messages over a TCP connection with a application layer header consisting of the hexadecimal octet 0x24; followed by a single octet channel identifier and the RFC4571 length specifier of the frame.

Due to the fact 0x24 violates section 4's requirements based on the fact it cannot be masked with the octet (AND 0xc3) to ensure it is a valid character I am filing this errata.

The chosen octet may also be present, specifically in the types of RTSP messages which are interleaved during playback such as ANNOUNCE. E.g. 0x24 could be a part of the configuration specifying the bits per pixel or audio bit depth as part of the SDP inter alia.

In such cases the underlying parser would interpret this octet as the start of the defined application header and cause framing errors which could cause data loss as allow for buffer overflow attacks of carefully crafted binary data.

There are also definitions which need to be made in the stadard for what to do when less then the amount of bytes indicated by the application layer frame header are or are not present. (e.g. more or less bytes are required then are present during reception of the given the [$CXX] application header sequence).

It is based on these considerations among others that I recommend that "$" [hexadecimal octet 0x24] be added to the reserved list and if necessary an escaping mechanism be defined where it is replaced with an escaped sequence which is agreed upon after consensus.

Due to the fact that drafts also specify that RTSP can be extended with any type of message so long as the data is not "$" the first character it is ambiguous may also appear elsewhere in the status line.

There are also issues with the ambiguous definition of pdu fragmentation defined in the latest draft, e.g. the mechanism defined as possibly required when pdu's larger then 65535 bytes are used however it specified no way to convey how this occurs or why.

The same can also be said for "sink" and "source" however I will address those definitions et al when appropriate.

Thank you for your time!

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC2326 (no draft string recorded)
--------------------------------------
Title               : Real Time Streaming Protocol (RTSP)
Publication Date    : April 1998
Author(s)           : H. Schulzrinne, A. Rao, R. Lanphier
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG