headers
Magnus Westerlund | 3 Feb 2003 17:26
Picon
Picon

RTSP and NATs

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
(Continue reading)

Permalink | Reply | 9 comments |
headers
Tom Marshall | 3 Feb 2003 19:15
Picon
Favicon

Re: RTSP and NATs

On Mon, Feb 03, 2003 at 05:26:22PM +0100, Magnus Westerlund wrote:
> 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.

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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jonathan Rosenberg | 3 Feb 2003 21:11

Re: RTSP and NATs

inline.

Tom Marshall wrote:
> On Mon, Feb 03, 2003 at 05:26:22PM +0100, Magnus Westerlund wrote:
> 
>>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.
> 
> 
> 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.

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

>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tom Marshall | 3 Feb 2003 23:39
Picon
Favicon

Re: RTSP and NATs

On Mon, Feb 03, 2003 at 03:11:57PM -0500, Jonathan Rosenberg wrote:
> inline.
> 
> Tom Marshall wrote:
> >On Mon, Feb 03, 2003 at 05:26:22PM +0100, Magnus Westerlund wrote:
> >
> >>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.
> >
> >
> >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.
> 
> 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.

> 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Colin Perkins | 4 Feb 2003 00:04
Picon
Favicon

Re: RTSP and NATs

--> Jonathan Rosenberg writes:
...
>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.

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
Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 4 Feb 2003 00:45

Re: RTSP and NATs


Tom Marshall wrote:

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

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.

> 
> 
>>>Regardless of STUN, it may be useful to have a mechanism for non-contiguous
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tom Marshall | 4 Feb 2003 02:22
Picon
Favicon

Re: RTSP and NATs

On Mon, Feb 03, 2003 at 06:45:54PM -0500, Jonathan Rosenberg wrote:
> 
> 
> Tom Marshall wrote:
> 
> >>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).
> >
> >
> >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?
> 
> 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.

Prior to IPv6 there was no known way to express a numeric IP address such
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan Rosenberg | 4 Feb 2003 04:54

Re: comedia-fix and the whole source address/port boondoggle

inline.

David Yon wrote:
> At 09:02 PM 1/14/2003, Jonathan Rosenberg wrote:
> 
>> Responses inline.
>>
>> David Yon wrote:
>>
>>> comedia-fix again raises the argument against embedding the source 
>>> address/port information in the SDP.  That is something that I still 
>>> feel strongly about, and work has progressed that makes use of it, 
>>> although not as a fail-safe session correlation mechanism.  We've 
>>> found that it's useful as a DoS counter-measure, using the following 
>>> design:
>>>     - An intermediate proxy on our network acts as a STUN-like
>>>       inverse-NAT translator to at least recover the likely address
>>>       from where the media will originate, and rewrites the SDP
>>>       if necessary.
>>
>>
>> It is quite a mystery to me how such a thing could possibly work in a 
>> causal fashion. The endpoint won't actually open any connections until 
>> after the offer/answer exchange has completed. The opening of the TCP 
>> connection is the thing which causes the NAT to assign a binding. So, 
>> the binding is assigned after the o/a exchange, but your proxy needs 
>> to know the binding before the exchange completes. So, I don't get it.
> 
> 
> It works on ranking rather than absolute correlation.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 4 Feb 2003 05:07

Re: comedia-fix-00 comments


David Yon wrote:
> At 09:58 PM 1/14/2003, Jonathan Rosenberg wrote:
> 
>> David,
>>
>> Ben, Paul and I discussed your comments extensively over the last week 
>> or so. Our conclusion was that we will not use comedia for simple 
>> messaging sessions. At a high level, the conclusion was that we were 
>> looking at "message sessions over TCP" and that comedia was perhaps 
>> optimized for "streaming media sessions over TCP". As such, many of 
>> our requirements that were critical, or assumptions we could make 
>> (such as demux within a single TCP connection) don't necessarily apply 
>> to streaming media over TCP.
>>
>> Now, I still think that much of what we proposed is valid. However, it 
>> is no longer critical to get it changed. So, keep that in mind as you 
>> read my responses below.
> 
> 
> The the meta-question is whether comedia-fix will continue to block 
> comedia's progress.  On one hand you imply above that it won't, but then 
> again we have the rest of this email that argues that comedia is 
> severely flawed.  So, where are we going from here?

I still have a big beef with the source IP/port, per separate email. 
Beyond that, I believe that the limitations of comedia will restrict its 
utility; certainly, they limited the ability for me to use it. But since 
I am not using it, I am not going to complain further about things where 
  nothing is broken per se, its just not what I think is the right
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 4 Feb 2003 05:22

Re: RTSP and NATs

inline.

Tom Marshall wrote:
> On Mon, Feb 03, 2003 at 06:45:54PM -0500, Jonathan Rosenberg wrote:
> 
>>
>>Tom Marshall wrote:
>>
>>
>>>>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).
>>>
>>>
>>>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?
>>
>>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
(Continue reading)

Permalink | Reply | 1 comment |

Gmane