Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions

From: Tom Marshall <[email-masked]>
Date: Wed, 30 Apr 2003 21:55:46 -0700

> >>Its an issue of - why are you inventing yet another thing when we 
> >>already have something on the table?
> >
> >
> >I can think of two reasons:
> >
> >1. The technique is already in use, and has been proven successful.  We
> >are
> >   trying to document that technique.
> 
> IETF proposed standards are not about documenting existing technique. 
> They are about proposing the right solution for all to implement.

Very well, perhaps I did not choose the proper wording.  My apologies.  I
have been reluctant to refer to symmetric rtp as a protocol because it's
extremely simple.  I think of it as a technique rather than a protocol.

I believe that it is a simple, elegant and comprehensive solution to the NAT
traversal problem for RTSP/RTP.  I would stop short of calling it "the"
right solution because real world scenarios inevitably prevent such a
definition.

> >2. It has advantages over STUN.  It is more successful than
> >nonmultiplexed
> >   STUN (eg. with 5-tuple NATs) and it does not require any protocol
> >   multiplexing to achieve maximum usefulness (it's a cleaner solution).
> 
> The only argument you are making here is that multiplexing is ugly. To 
> that I agree. But, if you want these fake RTP packets to not affect 
> RTCP, you are already basically saying that you are multiplexing a 
> non-RTP protocol on the RTP port. So I dont see the difference really.

First, let me state that my argument in the quoted message was not
comprehensive.  There are many arguments to be made for symmetric rtp and
multiplexing is only one.  Just off the top of my head, another advantage
that symmetric rtp holds over stun is that the destination= parameter
remains free for application use.

> >I can see where STUN may have uses for protocols other than RTP, and
> >that is
> >fine.  But to imply that STUN is the one grand solution and we shouldn't
> >pursue symmetric rtp is, in my opinion, a mistake.
> >
> 
> Well, as is pointed out in my ICE proposal:
> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt
> 
> The general approach solves a ton more cases than symmetric RTP alone 
> will. If you ever think that you will want RTSP in peer-to-peer cases, 
> symmetric RTP isnt going to cut it.

I somehow doubt your claim.  I can think of at least one case where
symmetric rtp will work where stun will not (yes, even multiplexed stun). 
In any case, "a ton" is a rather subjective number.

Are you advocating that symmetric rtp be abandoned entirely and that we
should all align behind stun as the single all-encompassing solution?  If
you are, I have a serious issue with that stance.  I can see why you might
have that opinion given your co-authorship with rfc3489, but I strongly
encourage you to evaluate each solution on its technical merits.  The
technique (or protocol, if yop prefer) behind symmetric rtp has been proven
to be quite effective, both in theory and in practice.

-- 
Mountain Dew and doughnuts...  because breakfast is the most important meal
of the day.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 May 2003 04:04:15 -0400

Tom Marshall wrote:

>>>  multiplexing to achieve maximum usefulness (it's a cleaner
> 
> solution).
> 

I'm not sure what this means. I agree that with symmetric RTP you don't 
specify an IP address to receive RTP, and with peer-to-peer stun you 
will, but I don't see this as a +/- in either direction.

>>>fine.  But to imply that STUN is the one grand solution and we
> 
> shouldn't
> 

Please elaborate.

> In any case, "a ton" is a rather subjective number.

Well, here are a few cases I know of where symmetric RTP will not work:

1. client and server both behind different nats, both are port restricted

2. client and server are both behind different nats, both are symmetric nat

3. client is in a public IP network, server is behind a nat

4. client and server are both in private networks, but there is a nat 
between the server and the client (multi-natted enterprise, for example)

None of these scenarios come up in the normal RTSP case where the server 
is on a public network. They arise in more peer-to-peer applications of 
RTSP, more common when used in conjunction with sip I suspect.

> should all align behind stun as the single all-encompassing solution?

My main interest is in trying to unify the nat traversal strategies for 
SIP and RTSP. There, it appears that ICE is the best way forward, and 
one component of that is the usage of peer-to-peer stun to verify 
connectivity. In the SIP case, there is just no need for symmetric RTP, 
since its function is encompassed within the ICE algorithm. The set of 
nat traversal cases for ICE is a superset of those covered by symmetric 
RTP. I am fairly sure I can prove that, but I would love to hear about 
this case you say works for symmetric RTP but not peer-to-peer STUN 
within an ICE context.

I have also recently discovered that the ICE methodology solves a very 
hard DoS attack which has been discussed in this context. The general 
problem is that a client connects to a server, and provides the server 
with a fake IP address/port to which media should be sent. This fake 
address/port is the address of the target. In the case of the symmetric 
RTP approach, this is done by having the client send RTP packets to the 
server using a spoofed source address.

Generally speaking, the way to prevent DoS attacks when amplification is 
a natural property of the protocol (as it is here), is to make sure you 
only send stuff to places that want it. With ICE, the server would 
immediately send a STUN request to the client to verify connectivity. 
The server would not actually send media unless a STUN response was 
received. Effectively, the connectivity check performed by stun has a 
side effect of verifying that the recipient WANTS the media. So, if the 
recipient of the STUN request is the target of a DoS attack, they 
wouldn't send a STUN response at all and therefore, no media is ever 
sent to them.

You could use RTCP for a similar kind of function, but its timescales 
are too large to be really effective at preventign this attack, IMHO.

> If
> encourage you to evaluate each solution on its technical merits. 

These kinds of personal accusations about do nothing to progress a 
discussion, Tom. Please, can we keep the discussion civil? I have done 
nothing but argue for things based on technical merits. I have been 
working on the problems of firewall and nat traversal for multimedia for 
many years, and my conclusions on the applicability of symmetric RTP vs. 
ICE/p2p stun are based on real issues (like the cases above) that I have 
seen arise.

  The
> to be quite effective, both in theory and in practice.

No doubt. It was added to the co-media spec at the urging of myself and 
others quite some time ago. I agree it works, and it works very well in 
cases where one side is always on a network reachable by the other. But, 
that case is not all cases, and the double nat cases are not handled by 
symmetric RTP.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Tom Marshall <[email-masked]>
Date: Thu, 1 May 2003 07:43:18 -0700

> will, but I don't see this as a +/- in either direction.

I see it as an advantage for symmetric rtp.  The original RTSP specification
was written with no NAT traversal strategies in mind, AFAIK.  The
destination parameter was meant for other purposes.  I don't know of any
practical application off the top of my head, but I must assume that at
least one exists.  Any such application is incompatible with STUN.

> >symmetric rtp will work where stun will not (yes, even multiplexed

Aside from the case pointed out above regarding the availability of the
destination parameter, there is also the case where a network administrator
prohibits the destination parameter from passing through the firewall.
Given the refusal of many administrators to allow _any_ UDP at all, I think
this case will have at least some practical application.

> 1. client and server both behind different nats, both are port restricted

Yes, nonmultiplexed stun works nicely here.

> 2. client and server are both behind different nats, both are symmetric nat

I don't see how any solution could be successful if the symmetric nat is of
the 5-tuple kind.

> 3. client is in a public IP network, server is behind a nat

I am assuming that in this case, the server is the STUN client and the
application is some sort of peer-to-peer scenario (because I find it
unlikely that a "traditional" RTSP server would have STUN client code).

The problem for RTP is that it flows from server to client.  The server's
NAT should have no problem sending RTP but it will appear to originate from
a different port than specified in the SETUP response.  This may or may not
be a problem, depending on how strict the client's receive code is written. 
There are enough "traditional" cases where RTP packets come from a different
source than expected that our code does not check the transport packet
source address.

RTCP will be a bigger problem because the server will not receive the
client's packets.  But since we are assuming that the server is a STUN
client in this scenario, let's also assume that the client is a symmetric
rtp client.  I think both would work equally well here.

> between the server and the client (multi-natted enterprise, for example)

I don't think this is really a separate case.  It's just a smaller case of
a nat on a network.

> SIP and RTSP.

I am sorry, but I don't see why this is a requirement.  SIP and RTSP serve
different purposes for different audiences.  Why do you want to force them
to use the same NAT strategy?

> server using a spoofed source address.

This DoS is exactly one of the reasons why I like symmetric rtp.  There is
no destination parameter.  But you do bring up a good point: a responsible
symmetric rtp application should ignore packets that have a different source
address from the RTSP connection.

I have yet to read the ICE proposal, so I can't comment much further.  I
will read it today.

> ICE/p2p stun are based on real issues (like the cases above) that I have 

Sorry.  But it seems that you take every opportunity to cut down everything
but STUN.  You were the one who "ranted" that ALGs are problematic on 2 Apr. 
This is certainly true (what real-world solution is ever bug-free?) but they
are a necessary part of NAT.  STUN is certainly a clever solution for some
use cases but it is not an all-encompassing solution.  It has its place, and
so does symmetric rtp, and so do ALGs.  NAT is a complicated beast with many
different implementations, and so our traversal mechanisms must be flexible. 
Any one protocol or technique can never work in all scenarios.

Again, are you advocating that symmetric rtp be abandoned entirely and that
we should all align behind STUN as the single all-encompassing solution?  If
not, then this discussion is probably at a good stopping point.  My interest
here was answering the question regarding why there are multiple NAT
traversal strategies, and I think that question has been answered.

> the double nat cases are not handled by symmetric RTP.

My initial reaction is that they are.  Why would symmetric rtp fail with a
double nat?

-- 
Beware of Programmers who carry screwdrivers.
        -- Leonard Brandwein