Subject: [MMUSIC] RTSP: Proxies and handling of unknown methods, headers and transport parameters

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Oct 2008 21:05:13 +0100

Hi,

This is an email concerning the following tracked bug:
https://sourceforge.net/support/tracker.php?aid=1898828

Note, this is a fairly long email, but there is suggestion to also
change the server behavior in this email!

We have several types of RTSP proxies, but one fundamental difference is
between the ones that insert themselves or some other entity in the
media transport or the ones that only concern themselves with the
signalling. The fact that we have several type makes the rules for how
proxies shall handle unknown RTSP methods, headers and transport
parameters a bit more difficult.

Methods:

The current text that regulates this is the following from section 13:

   If an RTSP agent does not support a particular method, it MUST return
   501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
   NOT try this method again for the given agent / resource combination.

As RTSP agents include proxies also, the current documented rule is that
a proxy needs to support the method it is forwarding. I think this
mostly makes sense, I can only see it be lessened for a specific type of
RTSP proxy which only function is to allow for logging of the RTSP
messages. But, even that is not certain to work, although likely. Thus I
suggest that we leave this as currently specified. Any objections?

Headers:

Headers are more problematic because a proxy can't really know what
purpose an unknown header is for. But it shouldn't be directly related
to the setup of media transport as these parameters all should be in the
transport header. Thus Access proxies or Security proxies does not need
to understand unknown headers and could forward them. An Caching proxy
may very well not have that luxury. But as a Caching proxy anyway need
to have full understanding of the media, a chaching proxy could be
required to understand all headers a server needs to understand.

My proposal for proxies is that they forward unknown headers and when
defining a header that a proxy needs to understand one uses a feature
tag that is put in the Proxy-Require header. When performing the
evaluation one should consider Access proxies and Security proxies. A
caching proxy has the choice to act as caching proxy and also ensure it
understands all feature tag in both the proxy-require and require header
or fallback to be an access proxy or similar and forward unknown header.
This seems to be in line with how servers treat unknown headers that
also should be ignored.

Transport specifications:

Now we are getting into the real problems. Servers that receive unknown
parameters are currently specified to ignore them. And if the client
requires the server to understand a parameter it is to add a feature tag
in require. Consider what this policy result in the proxy-require header
case makes this really unattractive. For proxies that don't insert
itself into the path this proxy-require prevents processing the message
at all. For proxies that pins the transport or translates it in any
fashion this is also causing extra round trips while it informs the
client about what it doesn't support. Similar issue do exist on the
server side causing unnecessary churn when requesting potentially
unsupported transports.

To resolve the above issue I suggest a general change in the handling of
unknown Transport header parameters. A RTSP agent receiving a request
with a Transport header SHALL ignore all transport specifications that
contains unknown transport parameters. That way in case there are
multiple transport specifications in the header the entity can strip
away the ones that contains unknown things. Please notice that it still
may be smart to define a feature tag for certain transport level
functionality so that one can learn support in OPTIONS request or other
methods including the supported header. But if one is using transport
parameters to get a certain functionality one can also specify a fall
back version that is expected to work with lower priority.

Comments?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "HAAS Christian" <[email-masked]>
Date: Wed, 29 Oct 2008 08:09:51 +0100

Hello!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Magnus Westerlund

> Methods:
> [...]
> Thus I suggest that we leave this as currently specified. Any objections?

Sounds ok; I don't even see a problem with logging proxies, since their prime
purpose is to log any message - and a minimum feature is grouping them
together according to CSeq and/or Session Ids, which should be enough for any
extension.

> [...]
> tag that is put in the Proxy-Require header. [...]

Ok. Would there be some guidelines as to which types of proxies to consider
for specifying a new feature (and its tag)?

> [...]
> A RTSP agent receiving a request with a Transport header SHALL
> ignore all transport specifications that contains unknown transport
> parameters. That way in case there are multiple transport
> specifications in the header the entity can strip away the ones
> that contains unknown things. [...]

Does "strip away" for a (concerned) proxy mean filtering the unknown
transport type out before passing the message on? (Or just "don't try to
interpret, just pass it on")?
For clarity, I'd suggest the writing that a concerned proxy removes
transports unknown to it - if that leaves the header empty, an immediate
Transport Not Supported response is generated.
This is of course highly dependant on intercepting (and the presence of)
corresponding Required headers...

Regards,
ch
____________________________________________________
Christian Haas
Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 - 8353
Mobile   +43-664-60 850 - 8353
Fax       +43-1-811 50 - 77 8353
Web      www.frequentis.com
E-Mail    [email-masked]
 
Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Oct 2008 10:06:15 +0100

Thanks for the quick feedback.

I will try to write up some text changes for this today.

> together according to CSeq and/or Session Ids, which should be enough for any

So you would like to point out that there are an exception for a very
particular sort of proxies?

> for specifying a new feature (and its tag)?

Yes, I intended so.

> interpret, just pass it on")?

Yes, that becomes a requirement if you are pinning or translating the
transport. You will be required to understand what the client requests
because it will be the proxy that responds to what it does.

> corresponding Required headers...

Yes.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Oct 2008 15:23:16 +0100

Hi,

Here is the text parts that I suggest to change to address this issue.
Please comment.

5.2.  Message Headers

   See [H4.2].

   Unknown message headers SHALL be ignored by a RTSP server or client.
   An RTSP Proxy SHALL forward unknown message headers.  Message headers
   defined outside of this specification that are required to be
   interpret by the RTSP agent will need to use feature tags
   (Section 4.7) and include it in the appropriate Require
   (Section 16.42) or Proxy-Require (Section 16.35) header.

13. Last paragraph:

   If an RTSP agent does not support a particular method, it MUST return
   501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
   NOT try this method again for the given agent / resource combination.
   An RTSP proxy whos main function is to log or audit and not modify
   transport or media handling in any way MAY forward RTSP messages with
   unknown methods.  Note, the proxy stil needs to perform the minimal
   required processing, like adding the Via header.

16.35:

End of section before example:

See discussion in the Proxies section (Section 17.1) about when to
consider that a feature requires proxy support.

16.42:

Part of First paragraph:

This header does not apply to proxies, for the same functionality in
respect to proxies see Proxy-Require header (Section 16.35) with the
exception of media modifying proxies. Media modifying proxies due to
their nature of handling media in a way that is very similar to what a
server, do need to understand also the server features to correctly
serve the client.

At end of section

See discussion in the Proxies section (Section 17.1) about when to
consider that a feature requires proxy support.

16.51.  Transport

   The Transport request and response header field indicates which
   transport protocol is to be used and configures its parameters such
   as destination address, compression, multicast time-to-live and
   destination port for a single stream.  It sets those values not
   already determined by a presentation description.

   A Transport request header field MAY contain a list of transport
   options acceptable to the client, in the form of multiple transport
   specification entries.  Transport specifications are comma separated,
   listed in decreasing order of preference.  Parameters may be added to
   each transport specififcation, separated by a semicolon.  The server
   MUST return a Transport response-header field in the response to
   indicate the values actually chosen if any.  If not transport
   specification is supported an empty header is returned and the
   request SHALL be responded using the status code 461 (Unsupported
   Transport) (Section 15.4.13).  In case more than one transport
   specification was present in the request, the server MUST return the
   single (transport-spec) which was actually chosen if any.  The number
   of transport-spec entries is expected to be limited as the client
   will get guidance on what configurations that are possible from the
   presentation description.

   The Transport header field MAY also be used in subsequent SETUP
   requests to change transport parameters.  A server MAY refuse to
   change parameters of an existing stream.

   A transport specification may only contain one of any given parameter
   within it.  Parameters MAY be given in any order.  Additionally, it
   may only contain either of the unicast or the multicast transport
   type parameter.  All parameters needs to be understood in a transport
   specification, if not the transport specification SHALL be ignored.
   RTSP proxies of any type that uses or modifies the transport
   specification, e.g. acces proxy or security proxy, SHALL remove
   specifications with unknown parameters before forwarding the RTSP
   message.  If that result in no remaing transport specification the
   proxy shall send a 461 (Unsupported Transport) (Section 15.4.13)
   response with an empty Transport header.

17.  Proxies

   RTSP Proxies are RTSP agents that sit in between a client and a
   server.  A proxy can take on both the role as a client and as server
   depending on what it tries to accomplish.  Proxies are also
   introduced for several different reasons and the below are often
   combined.

   Caching Proxy:  This type of proxy is used to reduce the workload on
         servers and connections.  By caching a presentation, both
         description and media streams the proxy can serve a client
         content without requesting it from the server once it has been
         cached and hasn't become stale.  See the caching Section 18.
         This type of proxy is expected to also understand RTSP end-
         point functionality, i.e. functionality identified in the
         Require header in addition to what Proxy-Require demands.

   Translator Proxy:  This type of proxy is used to ensure that a RTSP
         client get access to servers and content on an external network
         or using content encodings not supported by the client.  The
         proxy performs the necessary translation of addresses,
         protocols or encodings.  This type of proxy is expected to also
         understand RTSP end-point functionality, i.e. functionality
         identified in the Require header in addition to what Proxy-
         Require demands.

   Access Proxy:  This type of proxy is used to ensure that a RTSP
         client get access to servers on an external network.  Thus this
         proxy is placed on the border between two domains, e.g. a
         private address space and the public internet.  The proxy
         performs the necessary translation, usually addresses.  This
         type of proxies are required to redirect the media to
         themselves or a controlled gateway that perform the translation
         before the media can reach the client.

   Security Proxy:  This type of proxy is used to help facilitate
         security functions around RTSP.  For example when having a
         firewalled network, the security proxy request that the
         necessary pinholes in the firewall is opened when a client in
         the protected network want to access media streams on the
         external side.This proxy can also limit the clients access to
         certain type of content.  This proxy can perform its function
         without redirecting the media between the server and client.
         However, in deployements with private address spaces this proxy
         is likely to be combined with the access proxy.  Anyway, the
         functionality of this proxy is usually closely tied into
         understand all aspects of how the media transport.

   Auditing Proxy:  RTSP proxies can also provide network owners with a
         logging and audit point for RTSP sessions, e.g. for
         corporations that tracks their employees usage of the network.
         This type of proxy can perform its function without inserting
         itself or any other node in the media transport.  This proxy
         type can also accept unknown methods as it doesn't interfere
         with the clients requests.

   All type of proxies can be used also when using secured communication
   with TLS as RTSP 2.0 allows the client to approve certificate chains
   used for connection establishment from a proxy, see Section 19.3.2.
   However that trust model may not be suitable for all type of
   deployment, and instead secured sessions do by-pass of the proxies.

   Access proxies SHOULD NOT be used in equipment like NATs and
   firewalls that aren't expected to be regularly maintained, like home
   or small office equipment.  In these cases it is better to use the
   NAT traversal procedures defined for RTSP 2.0
   [I-D.ietf-mmusic-rtsp-nat].  The reason for these recommendations is
   that any extensions of RTSP resulting in new media transport
   protocols or profiles, new parameters etc may fail in a proxy that
   isn't maintained.  Thus resulting in blocking further development of
   RTSP and its usage.

17.1.  Proxies and Protocol Extensions

   The existence of proxies must always be considered when developing
   new RTSP extensions.  Most type of proxies will need to implement any
   new method to operate correct in the presence of that extension.  New
   headers will be possible to introduce without being blocked by
   proxies not yet updated.  However, it is important to consider if
   this header and its function is required to be understood by the
   proxy or can be forwarded.  If the header needs to be understood a
   feature-tag representing the functionality needs to be included in
   the Proxy-Require header.  Below are guidelines for analysis if the
   header needs to be understood.  The transport header and its
   parameters also shows that headers that are extensible and requires
   correct interpretation in the proxy also requires handling rules.

   When defining a new RTSP header it needs to be considered if RTSP
   proxies are required to understand them to achieve correct
   functionality.  Determining this is not easy as the functionality for
   proxies are widely varied as can be understood from the above list of
   functionality.  When evaluating this one can dived the functionality
   into three main categories:

   Media modifying:  The caching and translator proxies are modifying
      the actual media and therefore needs to understand also request
      directed to the server that affects how the media is rendered.
      Thus this type of proxies needs to also understand the server side
      functionality.

   Transport modifying:  The access and the security proxy both need to
      understand the how the transport is performed, either for opening
      pinholes or to translate the outer headers, e.g.  IP and UDP.

   Non-modifying:  The audit proxy is special in that it do not modify
      the messages in other ways than to insert the Via header.  That
      makes it possible for this type to forward RTSP message that
      contains different type of unknown methods, headers or header
      parameters.

   Based on the above classification one should evaluate if ones
   functionality requires the Transport modifying type of proxies to
   understand it or not.

-- 

Magnus Westerlund

---

From: "HAAS Christian" <[email-masked]>
Date: Fri, 31 Oct 2008 08:03:19 +0100

Hello;

The additions are ok from my view, only one issue:

From: Magnus Westerlund [mailto:[email-masked]] 
> 16.51.  Transport
> [...]
> If not transport specification is supported an empty header
> is returned and the request SHALL be responded using the
> status code 461 (Unsupported Transport) (Section 15.4.13). 
> [...]

Apart from that the transport header does not allow to be empty (ABNF), I see
no reason to return it at all, since the response code already tells what the
problem is.
(The same paragraph is repeated for proxies).

But we could consider that the server does return a transport header in the
461 response, filled with a list of transport-spec that he supports (for
given resource). Since it's a general 'supporting' response, the
transport-spec might only consist of transport-id (like "RTP/UDP") and
possibly one of "multicast" or "unicast" parameter for further limitation.
Proxies in the chain would then as well remove any entries they don't support
(finally removing the header all together when the last entry was removed),
leaving the client with a list of possible transports which then could ask
the user to re-enable a transport that was not tried before.
But I don't know if this would be a wanted feature mainly for usability...

Regards,
ch

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Oct 2008 10:30:33 +0100

> (The same paragraph is repeated for proxies).

Okay, you are correct, it is not needed.

> But I don't know if this would be a wanted feature mainly for usability...

My personal view is that there is a big difference between capability
declaration which you want in the 461 response and the configuration and
configuration negotiation that Transport header carries normally. I
think there is a point to use another structure and thus a new header
for that.

I will log a feature request for this, for future consideration.

Cheers

Magnus Westerlund