[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP and NATs
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 <mmusic@ietf.org>
cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)
Subject: [MMUSIC] RTSP and NATs
Magnus Westerlund Classification:
<magnus.westerlund@era.ericsson
.se>
Sent by:
mmusic-admin@ietf.org
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: magnus.westerlund@era.ericsson.se
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic