Subject: [MMUSIC] RTSP and NATs

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Feb 2003 17:26:22 +0100

Hi,

Here is a proposal to the RTSP spec for how to handle NATs using STUN. 
Please read and comment. It is planned to discuss NAT's on wednessday's 
RTSP telecon.

Cheers

Magnus

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

15 RTSP through Firewalls & NATs

15.1 Introduction

   Today there is Network Address Translators (NAT)   [32]  everywhere
   and a protocol must make sure that it can work through them in some
   fashion. The problem with RTSP is that it carries information about
   network  addresses  and  ports  inside  itself. It is primarily the
   media streams that are being blocked by NAT, as the  given  address
   to send to is a local one.

   Firewalls are also middle boxes that needs to be  considered.  They
   are deployed to prevent non-desired traffic/protocols to be used or
   reach the protected network. RTSP is designed to allow  a  firewall
   to  let RTSP controlled streams through, if chosen to, with minimal
   implementation problems.

15.2 NAT

   Today there exist a number of different NAT types and usage  areas.
   The different NAT types, cited from STUN  [31]:

   Full Cone: A full cone NAT is one where all requests from the  same
        internal  IP  address and port are mapped to the same external
        IP address and port. Furthermore, any external host can send a
        packet to the internal host, by sending a packet to the mapped
        external address.

   Restricted Cone: A restricted cone NAT is one  where  all  requests
        from  the  same internal IP address and port are mapped to the
        same external IP address and port. Unlike a full cone NAT,  an
        external  host  (with  IP  address X) can send a packet to the
        internal host only if the internal host had previously sent  a
        packet to IP address X.

   Port Restricted Cone: A port restricted cone NAT  is  like  a  res-
        tricted  cone  NAT, but the restriction includes port numbers.
        Specifically, an external host can send a packet, with  source
        IP  address  X and source port P, to the internal host only if
        the internal host had previously sent a packet to IP address X
        and port P.

   Symmetric: A symmetric NAT is one where all requests from the  same
        internal  IP  address  and  port, to a specific destination IP
        address and port, are mapped to the same external  IP  address
        and port. If the same host sends a packet with the same source
        address and port, but to a different destination, a  different
        mapping  is  used.  Furthermore,  only  the external host that
        receives a packet can send a UDP packet back to  the  internal
        host.

   NAT's are used on both small and  large  scale.  The  normal  small
   scale  user is home user that has a NAT to allow multiple computers
   share the single IP address given by their  Internet  Service  Pro-
   vider  (ISP).  The  large scale users are the ISP's themselves that
   gives there users private addresses. This is done both for  control
   and lack of addresses.

15.2.1 STUN

   The STUN  [31] protocol allows a client to  discover  the  type  of
   NAT(s) he is behind and also discover a mappings public address and
   port number. The protocol also allows  discovery  of  the  mappings
   timeout period and can be used as keep alive mechanism.

   How useful this protocol is depends  on  the  type  of  NAT(s)  the
   client  is  behind.  If  the  user  is behind a full cone NAT, STUN
   allows the RTSP client to traverse the NAT with some simple  client
   side adaptations. For restricted cone NATs STUN is still useful but
   require some more adaptations. For  symmetric  NATs  STUN  requires
   such severe server adaptations that it is not practical to use.

   A RTSP client using RTP transport can use STUN to traverse  a  full
   cone NAT in the following way:

   1.   Use STUN to discover the type of NAT, if any, and the  timeout
        period  for any UDP mapping on the NAT. This is RECOMMENDED to
        be performed in the background as soon as IP  connectivity  is
        established.  If  this  is  performed  prior to the attempt to
        establish a streaming session the possible delays in the  ses-
        sion  establishment will be reduced. If no NAT is present, use
        the normal SETUP behavior.

   2.   The RTSP client determines the number of UDP ports  needed  by
        the  RTP  sessions  part of the multi-media presentation. This
        information is available in  the  media  description  protocol
        used,  e.g.  SDP. In general each RTP session will require two
        UDP ports, one for RTP, and one for RTCP. Ensure that the same
        public  IP  address  is used for each RTP/RTCP port pair esta-
        blished.

   3.   For each UDP port required, establish a mapping  and  discover
        the  public  IP  address  and port number with use of STUN. if
        successful this results in that the client now knows for  each
        port know the mapping: clients local address/port Leftrightar-
        row public address/port.

   4.   Perform the RTSP SETUP for each media. In the transport header
        the  following  parameters  SHOULD  be included with the given
        values:   "destination"   with   the   public   IP    address,
        "client_port"  with  the public port of the mapping determined
        to be used for RTP, "client_rtcp_port" with the port number of
        the   mapping   to   be   used   for   RTCP.   The   parameter
        "client_rtcp_port" needs to be  used  unless  the  client  has
        managed  to  establish  a mapping with two consecutive numbers
        starting with an even one.  To allow this to work servers MUST
        allow  a  client to setup the RTP stream on any port, not only
        even ports. The server SHALL respond with a  transport  header
        containing the source IP address of the media streams.

   5.   To keep the mappings alive the client SHOULD periodically send
        UDP traffic over all mappings needed for the session. STUN can
        be used to determine the timeout period of the NAT(s) UDP map-
        pings. For the mapping carrying RTCP traffic the periodic RTCP
        traffic may be sent frequently enough. If not or for RTP  car-
        rying  mappings,  empty  IP/UDP messages SHOULD be sent to the
        streaming servers discard port (port number 9).

   If a UDP mapping is lost above process is required to be  performed
   again and the media stream effected SETUP again.

   To allow the UDP packets to arrive from  the  server  to  a  client
   behind  a  restricted  NAT,  any  UDP  messages must be sent to the
   server. Therefore SHOULD the client, before  sending  a  RTSP  PLAY
   request  send  an  empty  UDP  message,  on each mapping, to the IP
   address given as the servers source address and  its  discard  port
   (port number 9). Otherwise no difference in procedure compared with
   a full cone NAT is needed.

   For a port restricted NAT the client  must  send  messages  to  the
   exact ports used by the server to send messages. This makes it pos-
   sible to use the above described process with the  following  addi-
   tions: For each port mapping, a UDP message needs to be sent to the
   servers source address/port. To minimize potential effects  on  the
   server  from  these messages the following type of messages MUST be
   sent. RTP: An empty UDP message with  out  any  payload.   RTCP:  A
   correctly  formed RTCP message. Unless enough bandwidth is assigned
   to RTCP it might not be possible to  keep  the  UDP  mapping  open.
   These  messages  SHOULD  be  sent before sending a PLAY request and
   then periodically according to the determined timeout time  of  the
   NAT.

   To be able to use STUN to traverse symmetric NATs the  STUN  server
   needs to be co-located with the streaming server media distribution
   ports. As this will create implementations difficulties and  possi-
   bly security problems this SHOULD NOT be done.

15.2.2 Application Level Gateways

   An Application Level Gateway (ALG) reads the application level mes-
   sages  and  perform necessary changes to allow the protocol to work
   through the middle box. However this behavior has some problems  in
   regards to RTSP:

   1.   Does not work when protocol is used with end-to-end  security.
        As the ALG can't inspect and change the application level mes-
        sages the protocol will fail over the middle box.

   2.   Needs to be updated if extensions to the protocol  are  added.
        Due  to  deployment  issues  with changing ALG's this may also
        break the end-to-end functionality of RTSP.

   Due to the above reasons it is RECOMMENDED to not use ALGs in NATs.
   This  is  especially important for NAT's targeted to home users and
   not ISPs. In that case it is recommended that NATs  are  full  cone
   and  that  the  RTSP client instead used STUN or the planned MIDCOM
   protocols.

   An ALG for the this specification would need to perform the follow-
   ing tasks and changes to RTSP:

   1.   Detect a SETUP request.  Create  UDP  mappings  (client  given
        IP/port  Leftrightarrow  public  IP/port) where needed for all
        possible transport specification in the  transport  header  of
        the request found in (1). Enter the public address and port(s)
        of these mappings  in  transport  header.  Mappings  SHALL  be
        created with consecutive public port number starting on a even
        number for RTP each stream.  Mappings SHOULD also be  given  a
        long timeout period, at least 5 minutes.

   2.   When the response is received from  the  server  the  ALG  MAY
        remove  the  unused UDP mappings, i.e. the ones not present in
        the transport header. The session ID SHOULD also be  bound  to
        the UDP mappings part of that session.

   3.   The ALG SHOULD keep alive the UDP mappings belonging to the an
        RTSP  session  as long as: RTSP messages with the session's ID
        has been sent in the last RTSP session  timeout  interval,  or
        UDP  messages  are  sent on any of the UDP mappings during the
        last RTSP timeout interval.

   4.   The ALG MAY remove a mapping as soon a TEARDOWN  response  has
        been received for that media stream.

15.2.3 TCP Tunneling

   TCP tunneling is the final fallback  to  get  any  RTSP  controlled
   streaming to work through a NAT. As it is the client that establish
   the TCP connection to the server it  will  automatically  create  a
   binding  through  the  NAT. This connection can then be used by the
   server to send media packets in.

   Using TCP tunneling has the drawback on real-time  properties  that
   TCP has with "head of line" blocking. It may also have large varia-
   tions in through put due to the congestion control algorithm.   TCP
   tunneling must also be supported by both server and client.

   See section  10.11 for how to perform TCP tunneling.

15.3 Firewalls

   Firewalls exist for a purpose to protect a network from traffic not
   desired by the firewall owner. Therefore it is a policy decision if
   a firewall will let RTSP and its media streams through or not. RTSP
   is  designed  to  be  as easy as possible to process for a firewall
   with a policy to let the traffic pass through.

   The firewall will need to allow the media streams associated with a
   RTSP  session  pass through it. Therefore the firewall will need an
   ALG that reads RTSP SETUP and TEARDOWN  messages.  By  reading  the
   SETUP message the firewall can determine what type of transport and
   from where the media streams will use. Very common will be the need
   to open UDP ports for RTP/RTCP. By looking at the source and desti-
   nation addresses and ports the  opening  in  the  firewall  can  be
   minimized  to  the least necessary. The opening in the firewall can
   be closed after a teardown message for that session or the  session
   itself timesout.

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Tom Marshall <[email-masked]>
Date: Mon, 3 Feb 2003 10:15:18 -0800

> Please read and comment. It is planned to discuss NAT's on wednessday's 

I believe that a viable NAT traversal protocol should not require changes to
the protocols that it supports.  If it is desired that RTSP and STUN work
well together, I think the proper course of action is to modify the STUN
draft to allow requests for consecutive blocks of mapped UDP ports required
by RTSP and RTP.

Regardless of STUN, it may be useful to have a mechanism for non-contiguous
UDP port mappings.  I would argue in favor of a list based approach that has
general applicability instead of an approach that is specific to RTP.  For
example, the client_port attribute could use '/' to separate non-contiguous
ports:

Transport: rtp/avp/udp;unicast;client_port=7834/23478

Having said that, here are my thoughts on STUN in general:

I am not in favor of STUN.  There are other NAT traversal protocols[1] which
are already deployed and adding support for this one just muddies the waters
further.  If someone were to propose a simple and complete solution for all
NATs that everyone could get behind, that would be worth supporting.  STUN
is, by its own admission, not a complete solution[2].

The major focus of STUN seems to be the rapidly growing "NAT in a box" class
of router devices that have proliferated around broadband and wireless. 
Given the current lack of support for RTSP, why would we assume that vendors
will be any more willing to support STUN?  If the vendors won't support it,
then adding more Transport attributes creates more implementation headaches
for ourselves with little or no benefit.  I think the best solution is to
find out how to persuade the vendors to properly support RTSP.  It is really
not much more difficult to support than, say, FTP.

[1] Another example (with heavy industry backing) is http://www.upnp.org/ .

[2] From STUN draft: "STUN does not enable incoming UDP packets through
    symmetric NATs ..., which are common in large enterprises."

-- 
Windows 2000: Designed for the Internet. The Internet: Designed for UNIX.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Feb 2003 15:11:57 -0500

inline.

> draft to allow requests for consecutive blocks of mapped UDP ports required

No, that is impossible. You have misunderstood how STUN works.

STUN does not allocate the addresses. It merely tells the client what a 
regular, off the shelf NAT has allocated to a user. Since regular, 
off-the-shelf NATs do not know anything about RTP port pairings, two 
separate STUN requests will result in a nat allocating two bindings 
which are most likely not consecutive (or follow the odd/even rule). 
THis is dealt with through an SDP extension that allows a client to 
provide a specific address and port for SDP 
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt).

> Transport: rtp/avp/udp;unicast;client_port=7834/23478

Well, I will take this opportunity to once more complain, as I have done 
at IETF meetings in the past, of the continued cost of repeating 
protocol development related to session initiation twice - once for SIP, 
and once for RTSP. We already have a way to do this representation in 
SDP for SIP. Seems like we need to repeat such design now for RTSP.

> further. 

There are many topologies in which UPnP will not work. These icnlude:

* cases where the residential nat doesnt support it
* cases where there are multiple nats in tandem, such as cable operators 
that nat their networks
* enterprises with multiple access points to the public Internet

> If someone were to propose a simple and complete solution for all

Heh. How about world peace while you are at it.

The problem is this. Experience has shown that solutions which ALWAYS 
work tend to be way too expensive in situations that are far more 
simpler solution will do. There is therefore a cost/generality curve 
with a highly non-linear behavior, which results in solutions being 
defined across this curve. STUN happens to be extremely cheap to do in 
the cases where it works. THe most general solution, which are 
media-relay types of solutions, are very expensive because of the need 
to route media through intermediaries.

> will be any more willing to support STUN? 

You have again misunderstood how stun works. STUN requires no support in 
NATs. A provider that wants to provide streaming media services using 
rtsp would deploy the stun server, NOT the ISP or IP access provider of 
the end user.

> If the vendors won't support it,

I sinceerely doubt that.

What incentive has Linksys, Netgear, and the REAMS of other home nat 
boxes to support ALGs for RTSP? Are those companies the experts on RTSP? 
Surely not! The need to separate out applications from NATs and 
firewalls is central to the midcom working group and much of the other 
work going on in IETF.

ANYWAY, all of that said (just responding to this assault on STUN), I do 
not think STUN by itself is the right solution to RTSP nat traversal. 
THere are two options that are better.

OPTION 1: Symmtric RTP. See 
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-04.txt. 
Effectively, the IP address/ports provided by the RTSP client are 
ignored by the server. The client sends RTP/RTCP packets to the server, 
and the server sends media back to the client at the source ip/port that 
the RTP/RTCP came from. Requires no changes to the RTSP protocol, except 
to recommend this method. No STUN support needed. Works through all NAT 
types. It will require the client to send keepalive packets if there is 
a pause in media.

NB: This ONLY works if the RTSP server is on the public Internet!!!!

OPTION 2: Coming Soon
I am working on a draft (out before the -00 deadline end of this month) 
that finally unifies all of the mess of nat traversal together - STUN, 
TURN, symmetric RTP. It has the property that it always results in the 
optimal media path, lowest latency, lowest cost, and highest probability 
of working (i.e., you hear media), compared to any other technique. In 
the case of the RTSP server running on the public Internet, it would end 
up working a lot like OPTION 1 above. But, it would also work in cases 
where that was not true, for example, a client connecting to a media 
server in another enterprise that is behind a nat.

More to come soon.

In fact, one might say that the best approach for nat traversal is not 
to document it in the RTSP revision itself, as there are multiple 
solutions in any case. We have done that for sip, documenting solutions 
in a separate document:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-00.txt

Then there are other thigns coming like nsis. So, keeping this separate 
from RTSP itself is probably a good thing.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Tom Marshall <[email-masked]>
Date: Mon, 3 Feb 2003 14:39:39 -0800

> No, that is impossible. You have misunderstood how STUN works.

Yes, you are correct.  On initial reading of the STUN draft, I assumed
"server" meant the NAT device.  My understanding now is that the STUN server
resides on a publicly accessible address outside and independent from any
NAT.

> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt).

This draft again assumes that RTP is the only transport choice:

  rtcp-attribute =  "a=rtcp:" port

What if there were some other UDP based transport that required two UDP
ports (perhaps even "RTPng")?  You would need yet another draft to address
it.  Why not make the solution generic instead?

> SDP for SIP. Seems like we need to repeat such design now for RTSP.

I am not familiar with SIP (although I will read up on it before the next
meeting).  My only concern is that any modification to RTSP does not limit
itself needlessly.  If SIP has done so (and it appears that at least one SDP
draft is doing so), then perhaps those decisions should be reconsidered.

> Heh. How about world peace while you are at it.

And a complete IPv6 transition too, eh (reducing or eliminating NAT)? ;-)

> to route media through intermediaries.

I have just started looking at STUN but I have some questions:

1. Given a NAT that supports RTSP (eg. Linux 2.2 masquerading with an RTSP
   module loaded), will the client "detect" that it is behind a NAT?  If so,
   how does this affect the Transport: header as it passes through?  It
   seems to me that the RTSP enabled NAT will break the STUN-enabled
   Transport: header.  If this is the case, I think that STUN should be
   reconsidered (at least for RTSP) as would break an otherwise functional
   NAT setup.

2. Given a successful STUN setup, does the STUN client direct all UDP
   traffic to the STUN server as a relay point, or does the client assume
   that all UDP packets sent between the STUN mapped port and any outside
   address will have the same NAT mapping?  I will have to do some checking,
   but IIRC the Linux 'ipchains' NAT code does mappings with a '5-tuple':
   client ip, client port, nat port, server ip, server port.  If the latter
   case is assumed (no relay), I don't think that the STUN mappings would
   behave as described in the draft.  Packets sent to and from the appserver
   will have a different 5-tuple, and thus a different nat port, rendering
   STUN ineffective.  Has this case been considered?

> >If the vendors won't support it, then adding more Transport attributes
> >creates more implementation headaches for ourselves with little or no
> >benefit.  I think the best solution is to find out how to persuade the
> >vendors to properly support RTSP.  It is really not much more difficult
> >to support than, say, FTP.
> 
> I sinceerely doubt that.

Which do you doubt?  The implementation headaches or that RTSP support is
not difficult in NAT?

> NB: This ONLY works if the RTSP server is on the public Internet!!!!

This is similar to a technique that we (RealNetworks) use for our internal
transport.  It is quite effective (but not 100% of course).  The biggest
problem I see is that client->server RTP traffic is not expected.  There is
some chance that an intermediate device or proxy may behave badly.  But so
far, it seems to be the best choice.

> server in another enterprise that is behind a nat.

I will keep an eye out, thanks.

-- 
You can complain because roses have thorns, or you can rejoice because
thorns have roses.
        -- Abraham Lincoln

---

From: Colin Perkins <[email-masked]>
Date: Mon, 03 Feb 2003 18:04:02 -0500

--> Jonathan Rosenberg writes:
...
>from RTSP itself is probably a good thing.

Perhaps, although the RTSP spec should probably address any issues related
to NAT/firewall traversal. Especially since RTSP supports interleaving a
media stream on the control channel, which has quite different properties
than separate media.

Colin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Feb 2003 18:45:54 -0500

> it.  Why not make the solution generic instead?

Well, if thats so, I would have rather had such a debate in the context 
of the above draft. Anyway, I know of no other media stream that uses 
UDP that uses multiple ports AND that has an algorithmic relationship 
between those ports (i.e., has no way to express in the SDP which ports 
are needed). Seems like a non-problem.

> draft is doing so), then perhaps those decisions should be reconsidered.

Ultimately, I'd like to see SIP used to set up sessions both 
point-to-point and to media servers, and if control is needed, RTSP be 
introduced in order to achieve that end. There are many benefits from 
using a single protocol to achieve setup. We've stumbled onto one of 
them (duplication of specification work). Another is a single 
call/communications routing infrastructure. I have been hoping to find 
the time to write that up in an I-D, but there are always higher 
priority ones than chasing a goal that no one else seems to care about...

> And a complete IPv6 transition too, eh (reducing or eliminating NAT)? ;-)

Dont get me started...

>    module loaded), will the client "detect" that it is behind a NAT? 

Yes.

>    If so,

A smart ALG won't. It should know not to muck with IP addresses inside 
of the RTSP message if they are not private addresses (if stun is used, 
those addresses will have already been changed to public ones by the 
RTSP client). Indeed, one can imagine usign RTSP to setup a streaming 
media session to some third party device outside of the nat, in which 
case the ALG has to know not to change the IP. I wonder if the linux 
code you cite supports that.

Which, of course, brings me to my beef with ALG - the wrong people write 
them in general. Only an RTSP expert would probably know to look for 
such nuances (even then...), and Linksys and Netgear to not hire such 
people - its not their business.

>    traffic to the STUN server as a relay point,

No, the stun server is NOT a relay point.

>    or does the client assume
>    address will have the same NAT mapping? 

STUn works a binding discovery mechanism ONLY if the client can assume 
that any client outside of the nat can send to that address.

> I will have to do some checking,

Certainly. This is called "symmetric NAT". Its common but to date the 
full-cone variety, which maps bindings by private IP/port alone, is 
quite prevalent amongst the home NATs. The presenec of a symmtric NAT is 
discoverable by STUN, in which case you need somethign else to receive 
media. Symmetric RTP, for example, is an application-specific method. 
Another would be TURN 
(http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-00.txt) which 
does use a relay.

> Which do you doubt?  The implementation headaches or that RTSP support is

That RTSP ALGs are likely to be supported widely in the vast array of 
$100 NAT boxes on the market. FTP *is* widely supported, but RTSP is a 
domain-specific protocol, and I suspect not on their radar screens.

> transport.  It is quite effective (but not 100% of course). 

I am curious about what problems you have encountered.

-Jonathan R.

---

From: Tom Marshall <[email-masked]>
Date: Mon, 3 Feb 2003 17:22:16 -0800

> are needed). Seems like a non-problem.

Prior to IPv6 there was no known way to express a numeric IP address such
that it would not fit into a 32-bit integer.  Now there is, and it is one
source of poring issues.  Of course this is not a problem now.  Can you say
with certainty that it will never be a problem?

There is no need to deliberately limit functionality in this way.  Perhaps
SDP is committed to its course, although it appears to still be in draft
stage.  We don't have to do the same with RTSP.

> code you cite supports that.

All of the four or so RTSP modules that I am familiar with simply look at
client_port= and perform a mapping.  In order to detect that a transport
spec is using STUN, the module would also need to check for a destination=
attribute.

> such nuances (even then...), 

Indeed.  I have written one of the modules referenced above and I did not
consider it.  On the other hand, the destination= parameter has always been
a security risk at the server side and I am reluctant to advocate using it. 

Unfortunately, the overlap of people who would check for the destination=
parameter and the people who know how to code ALGs is very very small. 
Perhaps this argues for simpler protocol specs?

> and Linksys and Netgear to not hire such people - its not their business.

It certainly is their business if they make the equipment.  It's enough of
their business that they provide an ALG for FTP.  But I think it should also
be (or should have been) the business of the IETF to design a NAT traversal
protocol which allows the client to directly request mapped ports from the
NAT device.  Such a protocol would reduce or eliminate the need for STUN and
friends, and it would provide a single protocol for the vendors to implement
instead of a running treadmill of RFCs.

But the vendors have already been given a single protocol to implement:
UPnP.  It was created from the desire for NAT control at the client and
appears to have a lot of support from NAT vendors already.  And this makes
me wonder why we are continuing to propose more NAT traversal solutions. 
Why not either recommend UPnP or design an equivalent?

> quite prevalent amongst the home NATs.

Interesting.  Where can I find out more about how many home networks use
which types of NAT?

> domain-specific protocol, and I suspect not on their radar screens.

Unfortunately, I doubt any protocols requiring special handling besides FTP
are on their radar screens.  But UPnP compliance is, and together with the
ALGs in Linux and FreeBSD and Symmetric RTP, I suspect that a vast majority
of the home NATs are covered without STUN.

> I am curious about what problems you have encountered.

I was not personally involved in the testing but I can probably find someone
who was.

-- 
Happiness isn't something you experience; it's something you remember.
        -- Oscar Levant

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Feb 2003 23:22:45 -0500

inline.

> with certainty that it will never be a problem?

Seems like a bit of an over-exaggerated analogy. As I said, for any new 
protocol that needs multiple ports, it should simply make sure that its 
SDP parameter definitions include them. In such a case you will never 
have a problem.

Anyway, the point is moot, since, based on my limited RTSP knowledge, 
SDP is not used in the client addresses anyway. Thus, you can't use the 
SDP draft above.

> spec is using STUN, the module would also need to check for a destination=

Right. Although, I must admit confusion. If the client doesnt provide a 
destination attribute, to what IP address is the media sent? It seems to 
me that the destination parameter would normally be there. Or perhaps 
you are saying it is there, but its not looked at by the ALG?

> a security risk at the server side and I am reluctant to advocate using it. 

I guess I don't understand how media is delivered to the client then.

> instead of a running treadmill of RFCs.

Oh yes, no doubts there. midcom has been trying for years, and still no 
success. Even then, once its done, it doesn't work for many topoligies. 
The ultimate right answer is nsis, which would allow the client to 
directly ask for bindings through all nats that it will need to talk to. 
But, we are years and years away from such a thing seeing deployment.

> Why not either recommend UPnP or design an equivalent?

I indicated in another mail several problems with upnp. Another 
practical one is that its not that widely deployed yet. So, when an 
media company wants to deploy, do they wait and hope that people go off 
and buy upgrades to their nat, or hope all the nat vendors fall in line? 
No way. They want to be able to deploy the service now, without being 
dependent on features placed into home routers.

Anyway, ietf is working on their version of upnp, which is the midcom 
protocol.

> Interesting.  Where can I find out more about how many home networks use

I've heard reports of studies done on the subject, but have not seen 
concrete or quotable reports. I think such an analysis, especially 
tracking it over time, would be a great masters project for some student 
somewhere.

-Jonathan R.

---

From: Tom Marshall <[email-masked]>
Date: Mon, 3 Feb 2003 23:26:11 -0800

> SDP parameter definitions include them. In such a case you will never 

How is it better to require more work down the road (someone has to write a
draft, etc.) than build an extensible specification?  It may not be likely
that anyone will need the functionality, but it really does not require any
more work to provide up front and you may reduce the work later on.

What reason is there for not making an extensible solution (besides "it is
unlilkely anyone would ever use it")?

> SDP is not used in the client addresses anyway. Thus, you can't use the 

You were the one who mentioned it.  ;-)  It is analogous to the proposed
rtcp_client_port attribute in the RTSP Transport: header.

> you are saying it is there, but its not looked at by the ALG?

In the absence of a destination= attribute (which is far and away the most
common case as you may have inferred), the server sends to the same address
as the foreign end of the RTSP connection.  Disallowing the destination=
parameter pretty much eliminates the possibility for DoS abuse (hey server,
go flood this IP address with UDP data).  The possibility is more than idle
speculation -- a very similar DoS issue for online gaming servers was
recently discovered and published online (I forget which site but I can
probably find the article again if desired).  A few fat video stream makes
online game servers' response packets look like child's play.

-- 
There is nothing new under the sun, but there are lots of old things we
don't know yet.
        -- Ambrose Bierce

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Feb 2003 13:09:47 +0100

Hi,

I would like to try to summarize and give my comments to Tom's and
Jonathan's discussion. These are issues to continue to discuss here on
the list but which will also be brought up on tomorrow's RTSP
teleconference.

1. We might break out the NAT traversal part into a separate
specification. However we must look at how it relates to mechanisms that
will be in the base spec. I think it is important that as soon as
possible we outline these solutions.

2. The use of "client_rtcp_port" versus changing "client_port". Your are
correct that it might not be necessary to call it RTCP port. What we
will need for STUN support is to possibility to specify two explicit
port numbers without relation to each other. The general case would then
to allow to specify any set of port numbers in both directions. This
will cover any future transport protocol. However I went on to a new
parameter to avoid changing the already present parameters syntax. If
people find this acceptable then we can basically do anything with
"client_port".

3. Symmetric RTP.
- STUN over cone nats work without changing the servers, where symmetric
RTP requires server changes.
- Symmetric has hi-jacking potentials that will impossible to protect
against without RTP/RTCP based ID/authentication scheme.
- Needs binding mechanism for RTP/RTCP packets to the correct RTSP Session.
- Potential RTSP middle box (proxies, caches) problems. Should any way
be fixed for future RECORD servers.
- Otherwise of course a nice solution.

4. ALG's
- ALG: Deployment issues, especially for extensions
- ALG: Sub-standard implementations
- Prevent end-to-end security.
- Interactions between ALG's STUN is a potential problem.

5. UPnP or MIDCOM.
- Time to deploy these solutions.
- no real conflict, if UPnP/midcom is available use it.

6. Jonathan's other proposal
Please provide it so that we can discuss it.

7. Use of "Destination" parameter for NAT/ALG's
- Destination might be needed if NAT maps using several IP addresses to
same client.
- Needs client based authentication of that address/port in RTSP message
to work in secure ways.

Best Regards

Magnus Westerlund