Re: [AVTCORE] Possible Erratta in RFC2326 relating to 'source' parameter.

[Julius Friedman <[e-mail]>]

Please find my previous message without the attachment which seems to have
been the result of why it was not received.

--------------------

I have come across several entities which use the 'source' datum but it
usually contains their own [IP] Address, I am not sure why giving another
[IP] Address there would be useful since it would probably be routed anyway.

I just wanted to make sure I wasn't missing anything and you came up with a
perfect answer so, Thank you !

I would like to also point out that it also is a security concern because
it can allow a client to connect to another server and this just looks like
part of the RTSP negotiation;

I can then technically also use any Rtsp server to DOS another server by
having it attempt to connect to that server to setup something repeatedly.

Additionally the server @ 'source' has no way of knowing the client would
even be connecting to it and the client may not even be allowed to.

This is the text verbatim:

   source:
          If the source address for the stream is different than can be
          derived from the RTSP endpoint address (the server in playback
          or the client in recording), the source MAY be specified.

The SDP has been exchanged and would then contain the necessary
information about connection information, the source is the 'EndPoint'
[IP] Address / Port pair from which the 'Request' has been received,
taking any other such notion of this would not be beneficial in any
circumstance, including `proxying` because the proxy would handle
'EndPoint' negotiation and have it's own set of headers to support
such.

Based on these concerns can `source` be amended to indicate it's only
such and not defined for use in the 'RTP/AVP' profile?

It would also reduce some of the work in the latest draft which
indicate concerns about this parameter.

.Since we are on the subject of the 'Transport' header I have another
question 'ssrc' in the same parameter, I have written into the
'mmusic' group several times but for some reason they don't seem to be
responding.

Can a client send his 'ssrc' to the server?
 - (Obviously he can but) Is this already legal with the current spec?
 - If so how can the server distinguish it's own `ssrc` in the response?
(E.g. if the server doesn't want that client to use that `ssrc` for some
reason)

Why would this need to be done? in situations where a client is joining a
session where many participants may already be active (especially
multicast) it would be beneficial to avoid early 'ssrc' collisions with one
of those.

Yes the client can already do this by just waiting for the response to
assign it's own `ssrc` but the response does not indicate the 'ssrc' of ALL
participants only that of the media server, rtcp eventually sorts this out
with a Goodbye and then a new ssrc but none the less I assume that saving
that time and bandwidth and also having the option to assign both client
and server ssrc would also have other benefits.

Moving back to the part about the peculiar punctuation.. I believe these
peculiarities come from a notion that everything was text based.

The latest draft makes no changes at all to this besides defining more
syntax.

Since the binary framing was apparently an after thought (based on
information from the drafts which show interleaved data in a 'DATA' RTSP
response) I think this was remnant from that in some way or at least that's
the best I can possibly imagine.

Why the framing octet would also be listed as a 'safe' character is beyond
me, there were several other characters / octets which definitely could
have been used e.g. 0xC3 -> 0xFF.

The fact that the document makes so many statements about ease of parsing
and then literally and figuratively destroy this concept with bad decisions
such as the framing character as well as the interesting syntax for the
markup.

I will past some of those here :

1.4 <https://tools.ietf.org/html/rfc2326#section-1.4> Protocol Properties

   RTSP has the following properties:

....

   Easy to parse:
          RTSP can be parsed by standard HTTP or MIME parsers.



...



4 <https://tools.ietf.org/html/rfc2326#section-4> RTSP Message

   RTSP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 <https://tools.ietf.org/html/rfc2279>
[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
<https://tools.ietf.org/html/rfc2279> [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.



This literally becomes a nightmare when you have to reconstruct TCP
sequences.

I have attached a small 3MB zipped Wireshark capture which shows one such
case of my dealing with this issue.

This is only exacerbated by the fact the document allows packets up to the
maximum holding size in this mode AND specifies that packets with an
unknown context must be skipped...

Skipped how? Skipped as in past their header, past their data? Can that
text even be there?

We are talking about TCP and in such a case the data from a previous
segment was already received by the receiver and contains only some of the
data how would they skip data they have yet to receive?

I will explain why this is a security issue, Since there is no sequence
information in the binary header it must be trusted to contain valid length
values. Without inspecting the latter octets one can make no such
assumption about the type of binary data contained therein, especially if
there is no context assigned.

This if I can get a single TCP packet into a stream I can very easily
inject a lot of 'receive' space thus exponentially increasing my chances of
getting another packet into the stream.

I think that there should at the very least be a correlation between
'Block-Size' and the frame size such that frame sizes MUST NOT ever be
larger than that value if not already.

Furthermore I think that something needs to be done to specify how to deal
with nuisances such as 'more / less bytes available than indicated in
frame' especially when we also have 'Rtsp' messages which can be
interleaved at the same time in between frames (which can contain "$").

So to re-iterate my understanding of how things are in toto I have an
example I will outline below which is is a Rtsp Binary Interleaved sender
who tells a Rtsp Binary Interleaved client there is a frame of 48344 bytes
on channel 0.

The client received only 1328 bytes.

47016 bytes remain.

The client starts to receive again.

At this point there should only be the rest of the data in the frame (47016
bytes)

This data will come over several MSS sized segments, during which time the
socket may also be written to again (before the segment is transmitted to
the client).

{
    If the latter data happens to get to the receiver before the other
portions of the segment we have TCP 're-ordering' based on the sequence
number and may multiple ACK's for the early packets.

    If any data is missed we will have a re-transmission.

    The data being 'received' on the socket by the receiver coming from the
server comes from the data portion of the tcp packet which now contains
data from a previous segment.
}

The sender is now committed to sending the additional bytes as indicated
however if the sender stops sending this data or it's truncated it will
never make to the receiver. The stack will never be able to re-assemble the
packet and now framing sync is lost.

At this point ANY data consumed from the initial frame header and data
which was received must ALSO be dis-guarded but there is NO WAY for the
server to indicate this to the client... (This is why UDP is commonly used,
you get what you get and you don't what you don't)

There are a lot of articles outlining why TCP and RTP don't get along
mostly citing the overhead of re-transmissions so with Rtsp you think we
would have attempted to solve this not make it worse with bad encapsulation.

Something needs to be done about this because it's also a security concern,
e.g. if a client were to send a rtcp packet to the server which is very
larger and contains no data he could attempt to exhaust the resources of
that server (if they didn't monitor their rtcp bandwidth properly) or at
least force a higher amount of traffic.

So, information needs to be clear that there is no such thing as a packet
of less then 8 bytes under rtcp and 16 bytes under rtp. (Unless compression
is being used; ROHC or otherwise)

The null packet or any packet under 16 bytes would used for 'spacing' not a
'unknown' context, especially when I can have 255 channels, what unknown
context am I going to use then?

That is 4 octets for the `$` header, and the rest for the the packet header
which can then be inspected to be the same version, payloadtype and ssrc as
required by the client.

This prevents a client who may also send a "GET_PARAMETER" under
interleaved transport with weird headers and a body to attempt underflow
also which is something the current specification does nothing to protect
against.

"GET_PARAMATER rtsp://someuri/ RTSP/1.0\r\nCSeq:1\r\nDate:
xx:xx:xx\r\nContent-Length:24\r\n$UserAgent
$009\r\n$\0\0\aRTSP/1.$\0\0\r\n\r\nDatawith$IsNotAGoodIdea!\0\0"

This would allow applications to still take note of when a large frame was
seen but not be forced to act upon it and potentially lose data, and
depending on their implementation allow remote code execution.

I urge the committee to seriously look into these issues as they can have a
large impact.

https://isecpartners.github.io/fuzzing/vulnerabilities/2013/12/30/vlc-vulnerability.html

VLC seems protected against overflow after this but with some testing I
have determined that not only VLC but other servers and clients are
vulnerable to underflow this way as well making it both a server and client
issue.

I have more notes in my implementation @
https://net7mma.codeplex.com/SourceControl/latest#Rtp/RtpClient.cs if your
interested, it relates to one issue I saw where even though frame length
was good other data in the packet was invalid such as the 'Extension' or
the 'Length In Words Minus 1' or the ssrc etc.

Hopefully I didn't banter to much, it's rather late.

As for my other 'issues' / errata for RFC2435 has anything been determined
on them?

What about the one for RFC3550, has anyone sat down to do the math on that
one yet?

Thanks again for your time and response and have a Happy New Year if I
don't hear back by then!

Sincerely,
Julius Friedman


On Sun, Jan 4, 2015 at 3:28 PM, Julius Friedman <[e-mail]>
wrote:

> This is a re-transmission of my previous response which didn't seem to
> make it to the list...
>
> Is there any way to confirm if I am properly signed up?
>
> I have come across several entities which use the 'source' datum but it
> usually contains their own [IP] Address, I am not sure why giving another
> [IP] Address there would be useful since it would probably be routed anyway.
>
> I just wanted to make sure I wasn't missing anything and you came up with
> a perfect answer so, Thank you !
>
> I would like to also point out that it also is a security concern because
> it can allow a client to connect to another server and this just looks like
> part of the RTSP negotiation;
>
> I can then technically also use any Rtsp server to DOS another server by
> having it attempt to connect to that server to setup something repeatedly.
>
> Additionally the server @ 'source' has no way of knowing the client would
> even be connecting to it and the client may not even be allowed to.
>
> This is the text verbatim:
>
>    source:
>           If the source address for the stream is different than can be
>           derived from the RTSP endpoint address (the server in playback
>           or the client in recording), the source MAY be specified.
>
> The SDP has been exchanged and would then contain the necessary information about connection information, the source is the 'EndPoint' [IP] Address / Port pair from which the 'Request' has been received, taking any other such notion of this would not be beneficial in any circumstance, including `proxying` because the proxy would handle 'EndPoint' negotiation and have it's own set of headers to support such.
>
> Based on these concerns can `source` be amended to indicate it's only such and not defined for use in the 'RTP/AVP' profile?
>
> It would also reduce some of the work in the latest draft which indicate concerns about this parameter.
>
> .Since we are on the subject of the 'Transport' header I have another question 'ssrc' in the same parameter, I have written into the 'mmusic' group several times but for some reason they don't seem to be responding.
>
> Can a client send his 'ssrc' to the server?
>  - (Obviously he can but) Is this already legal with the current spec?
>  - If so how can the server distinguish it's own `ssrc` in the response?
> (E.g. if the server doesn't want that client to use that `ssrc` for some
> reason)
>
> Why would this need to be done? in situations where a client is joining a
> session where many participants may already be active (especially
> multicast) it would be beneficial to avoid early 'ssrc' collisions with one
> of those.
>
> Yes the client can already do this by just waiting for the response to
> assign it's own `ssrc` but the response does not indicate the 'ssrc' of ALL
> participants only that of the media server, rtcp eventually sorts this out
> with a Goodbye and then a new ssrc but none the less I assume that saving
> that time and bandwidth and also having the option to assign both client
> and server ssrc would also have other benefits.
>
> Moving back to the part about the peculiar punctuation.. I believe these
> peculiarities come from a notion that everything was text based.
>
> The latest draft makes no changes at all to this besides defining more
> syntax.
>
> Since the binary framing was apparently an after thought (based on
> information from the drafts which show interleaved data in a 'DATA' RTSP
> response) I think this was remnant from that in some way or at least that's
> the best I can possibly imagine.
>
> Why the framing octet would also be listed as a 'safe' character is beyond
> me, there were several other characters / octets which definitely could
> have been used e.g. 0xC3 -> 0xFF.
>
> The fact that the document makes so many statements about ease of parsing
> and then literally and figuratively destroy this concept with bad decisions
> such as the framing character as well as the interesting syntax for the
> markup.
>
> I will past some of those here :
>
> 1.4 <https://tools.ietf.org/html/rfc2326#section-1.4> Protocol Properties
>
>    RTSP has the following properties:
>
> ....
>
>    Easy to parse:
>           RTSP can be parsed by standard HTTP or MIME parsers.
>
>
>
> ...
>
>
>
> 4 <https://tools.ietf.org/html/rfc2326#section-4> RTSP Message
>
>    RTSP is a text-based protocol and uses the ISO 10646 character set in
>    UTF-8 encoding (RFC 2279 <https://tools.ietf.org/html/rfc2279> [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 <https://tools.ietf.org/html/rfc2279> [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.
>
>
>
> This literally becomes a nightmare when you have to reconstruct TCP
> sequences.
>
> I have attached a small 3MB zipped Wireshark capture which shows one such
> case of my dealing with this issue.
>
> This is only exacerbated by the fact the document allows packets up to the
> maximum holding size in this mode AND specifies that packets with an
> unknown context must be skipped...
>
> Skipped how? Skipped as in past their header, past their data? Can that
> text even be there?
>
> We are talking about TCP and in such a case the data from a previous
> segment was already received by the receiver and contains only some of the
> data how would they skip data they have yet to receive?
>
> I will explain why this is a security issue, Since there is no sequence
> information in the binary header it must be trusted to contain valid length
> values. Without inspecting the latter octets one can make no such
> assumption about the type of binary data contained therein, especially if
> there is no context assigned.
>
> This if I can get a single TCP packet into a stream I can very easily
> inject a lot of 'receive' space thus exponentially increasing my chances of
> getting another packet into the stream.
>
> I think that there should at the very least be a correlation between
> 'Block-Size' and the frame size such that frame sizes MUST NOT ever be
> larger than that value if not already.
>
> Furthermore I think that something needs to be done to specify how to deal
> with nuisances such as 'more / less bytes available than indicated in
> frame' especially when we also have 'Rtsp' messages which can be
> interleaved at the same time in between frames (which can contain "$").
>
> So to re-iterate my understanding of how things are in toto I have an
> example I will outline below which is is a Rtsp Binary Interleaved sender
> who tells a Rtsp Binary Interleaved client there is a frame of 48344 bytes
> on channel 0.
>
> The client received only 1328 bytes.
>
> 47016 bytes remain.
>
> The client starts to receive again.
>
> At this point there should only be the rest of the data in the frame
> (47016 bytes)
>
> This data will come over several MSS sized segments, during which time the
> socket may also be written to again (before the segment is transmitted to
> the client).
>
> {
>     If the latter data happens to get to the receiver before the other
> portions of the segment we have TCP 're-ordering' based on the sequence
> number and may multiple ACK's for the early packets.
>
>     If any data is missed we will have a re-transmission.
>
>     The data being 'received' on the socket by the receiver coming from
> the server comes from the data portion of the tcp packet which now contains
> data from a previous segment.
> }
>
> The sender is now committed to sending the additional bytes as indicated
> however if the sender stops sending this data or it's truncated it will
> never make to the receiver. The stack will never be able to re-assemble the
> packet and now framing sync is lost.
>
> At this point ANY data consumed from the initial frame header and data
> which was received must ALSO be dis-guarded but there is NO WAY for the
> server to indicate this to the client... (This is why UDP is commonly used,
> you get what you get and you don't what you don't)
>
> There are a lot of articles outlining why TCP and RTP don't get along
> mostly citing the overhead of re-transmissions so with Rtsp you think we
> would have attempted to solve this not make it worse with bad encapsulation.
>
> Something needs to be done about this because it's also a security
> concern, e.g. if a client were to send a rtcp packet to the server which is
> very larger and contains no data he could attempt to exhaust the resources
> of that server (if they didn't monitor their rtcp bandwidth properly) or at
> least force a higher amount of traffic.
>
> So, information needs to be clear that there is no such thing as a packet
> of less then 8 bytes under rtcp and 16 bytes under rtp. (Unless compression
> is being used; ROHC or otherwise)
>
> The null packet or any packet under 16 bytes would used for 'spacing' not
> a 'unknown' context, especially when I can have 255 channels, what unknown
> context am I going to use then?
>
> That is 4 octets for the `$` header, and the rest for the the packet
> header which can then be inspected to be the same version, payloadtype and
> ssrc as required by the client.
>
> This prevents a client who may also send a "GET_PARAMETER" under
> interleaved transport with weird headers and a body to attempt underflow
> also which is something the current specification does nothing to protect
> against.
>
> "GET_PARAMATER rtsp://someuri/ RTSP/1.0\r\nCSeq:1\r\nDate:
> xx:xx:xx\r\nContent-Length:24\r\n$UserAgent
> $009\r\n$\0\0\aRTSP/1.$\0\0\r\n\r\nDatawith$IsNotAGoodIdea!\0\0"
>
> This would allow applications to still take note of when a large frame was
> seen but not be forced to act upon it and potentially lose data, and
> depending on their implementation allow remote code execution.
>
> I urge the committee to seriously look into these issues as they can have
> a large impact.
>
>
> https://isecpartners.github.io/fuzzing/vulnerabilities/2013/12/30/vlc-vulnerability.html
>
> VLC seems protected against overflow after this but with some testing I
> have determined that not only VLC but other servers and clients are
> vulnerable to underflow this way as well making it both a server and client
> issue.
>
> I have more notes in my implementation @
> https://net7mma.codeplex.com/SourceControl/latest#Rtp/RtpClient.cs if
> your interested, it relates to one issue I saw where even though frame
> length was good other data in the packet was invalid such as the
> 'Extension' or the 'Length In Words Minus 1' or the ssrc etc.
>
> Hopefully I didn't banter to much, it's rather late.
>
> As for my other 'issues' / errata for RFC2435 has anything been determined
> on them?
>
> What about the one for RFC3550, has anyone sat down to do the math on that
> one yet?
>
> Thanks again for your time and response and have a Happy New Year if I
> don't hear back by then!
>
> Sincerely,
> Julius Friedman
>
>
>
> On Tue, Dec 30, 2014 at 3:33 PM, Dale R. Worley <[e-mail]>
> wrote:
>
>> Julius Friedman <[e-mail]> writes:
>> >  Transport           =    "Transport" ":"
>> >                             1\#transport-spec
>>
>> In a few places, RFC 2326 seems to use "\#" in place of "#".  There
>> doesn't seem to be any documentation for this.  There seems to be other
>> peculiar punctuation as well, including "\$" and "$'$".
>>
>> > Since 'source' is not listed I don't know the syntax, I assumed it to
>> > be an "IPAddress" however the text sates "address" so I imagine if I
>> > found a 'source=1.2.3.4:1554' that would be valid however I want to
>> > make sure since there isn't any syntax specified in the RFC.
>>
>> It's not clear to me that there *is* a "source=" parameter for the
>> Transport header.  Yes, there is prose describing source as a datum, but
>> there's no BNF for a corresponding parameter, and a quick search doesn't
>> turn up any instance of "Transport:  ...source=..." in any RFC or I-D.
>>
>> However, "source=" is shown in
>> http://heim.ifi.uio.no/~meccano/reflector/smallclient.html
>>
>> > Also I would wonder is there any restriction on specifying a port or
>> > address range also ? e.g. 'source=1.2.3.4/321202/2'
>>
>> Well, I see "parameter = [...] ";" "destination" [ "=" address ]", and
>>
>>    address             =    host
>>
>>    host      =   <A legal Internet host domain name of IP address
>>                  (in dotted decimal form), as defined by Section 2.1
>>                  of RFC 1123 \cite{rfc1123}>
>>
>> so it looks like <address> cannot specifiy an address range or a port.
>> I'd expect the port to be specified by the "client_port" and
>> "server_port" parameters.
>>
>> (BTW, it looks to me like the first "of" in the definition of <host>
>> should be "or".)
>>
>> > I believe there was a similar issue with Rtp-Info headers which was
>> > fixed in 'biz' however this among other issues were not addressed and
>> > I am wondering if any other updates will be made to this RFC before
>> > 2.0 Draft is finalized.
>>
>> An RFC is never "updated", although it can be obsoleted by a later RFC
>> that entirely replaces it.
>>
>> Dale
>>
>
>
>