Subject: Re: [MMUSIC] RTSP and NATs

From: [email-masked]
Date: Wed, 5 Feb 2003 18:31:29 +0100

Magnus,

I strongly support the recommendation to not use ALGs,
therefore STUN should be used instead but then you wrote:

 > 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.

I am surprised, I would have proposed _on the contrary_ a "SHOULD" here
(since traversing symetric NATs is a key feature) !

also what do you mean by  "implementation difficulties" ? (I really cannot see any ?)
and could you explicit what type of _additional_ security issues this would cause
(i.e. issues that are not inherent to running either a RTSP or a STUN server in the first place ?)

regards

Philippe Gentric
Software Architect
Philips MP4Net
"philippe dot gentric at philips dot com"
http://www.platform4.philips.com

                                                                                                                                              
                                                          To:   IETF MMUSIC WG <[email-masked]>                                              
                                                          cc:   (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                    
                                                          Subject:    [MMUSIC] RTSP and NATs                                                  
                                                                                                                                              
               Magnus Westerlund                          Classification:                                                                     
               <[email-masked]                                                                                                
               .se>                                                                                                                           
                                                                                                                                              
               Sent by:                                                                                                                       
               [email-masked]                                                                                                          
                                                                                                                                              
               03/02/2003 17:26                                                                                                               

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Feb 2003 19:45:42 +0100

Hi Philippe,

>(i.e. issues that are not inherent to running either a RTSP or a STUN server in the first place ?)
The problem of running STUN for a symmetric NAT is that the STUN server 
must be located at the servers sending port. So using the same RTSP 
mechanism that are used for traversing a cone-nat the client would:
1. first contact a well known port with the server for each his media 
stream to get the mapping of the stream. The client can't use any other 
then the well known port because it doesn't know what port to send to.
2. In the SETUP ask the server to send from its STUN servers well known 
port. It also needs to receive RTCP on that port.
3. For keep alive on the RTP port the client needs to send periodically 
STUN messages to the STUN server.

This is a mess for a implementor. It need to have a STUN server 
receiving the STUN messages while the RTP/RTCP stack should receive all 
other messages. Also all the clients need to reside on the same port 
number which creates a multiplexing nightmare.

If you change the setup phase so that the streams are first SETUP to 
dummy ports then reconfigured with a later message, the STUN could be 
located at each media streams source address. However in this setup it 
is actually better to use symmetric RTP in all regards except perhaps 
hi-jacking of media streams. However with certain restrictions you can 
actually end up with at least the same level of security that RTSP 
provides today.

How are you using STUN to traverse a symmetric NAT?

Best Regards

Magnus

-- 

Magnus Westerlund