Subject: RE: [MMUSIC] RTSP & NAT discussion on wednesday and thursday.

From: Thomas Zeng <[email-masked]>
Date: Tue, 15 Jul 2003 02:25:55 -0700

Dear Tom:

Yes, we have presented "various NAT traversal solutions along with their
strengths and weaknesses", but some of these solutions happen to require
protocol development (e.g. port co-Located STUN). 

Correct me if I am wrong, but I think none of the off-the-shelf, UDP based
solutions (e.g.,, STUN) work for Symmetric NAT, yet Symmetric NATs are
rather common. Here I don't count TURN and ICE yet since they are only IDs,
and even when they do become RFCs, their complexity seems to be high enough
such that implementors will, as a knee-jerky reaction, fall back to TCP
tunnelling for NAT traversal.

Perhaps  TCP tunnelling is acceptable (Magnus would disgree with me), or
perhaps we could develope a UDP based solution whose complexity is not much
worse than TCP tunnelling?

Then there is RTP DoS problem ...

Hence the change of direction, so to speak.

Cheers,
- thomas

-----Original Message-----
From: Tom Marshall [mailto:[email-masked]]
Sent: Monday, July 14, 2003 11:14 AM
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday.

> So please consider if you have any further requirements that should be 
> consider for this work. We should in the next weeks have some consensus 
> on what work we should perform regarding the solution for symmetric NATs 
> and RTSP. The result of this discussion will be used to decide on what 
> solution to select.

Perhaps I misread this, but it sounds like you are saying that we should
agree on one traversal solution.  I thought the RTSP NAT document was
intended (and does) present the various NAT traversal solutions along with
their strengths and weaknesses, and let the implemetors decide which to use?

-- 
...if the church put in half the time on covetousness that it does on lust,
 this would be a better world.
        -- Garrison Keillor, "Lake Wobegon Days"

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

---

From: Tom Marshall <[email-masked]>
Date: Tue, 15 Jul 2003 07:29:42 -0700

> Hence the change of direction, so to speak.

I believe these are all good arguments for documenting and supporting
Symmetric RTP in the draft:

 - Works through Symmetric NAT.
 - Works through ALGs.
 - Very simple to implement.
 - Does not change DoS threat level.

I believe that Symmetric RTP should be presented as a simple and basic NAT
traversal solution for the case where the server is in the open and the
client may be behind a NAT (the client need not know or care, because using
Symmetric RTP will not break things if it's not really behind a NAT).  We
can then continue on with the more complex cases, such as servers behind
NATs.

-- 
Apathy Club meeting this Friday.  If you want to come, you're not invited.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 10:35:11 -0400

inline.

>  - Does not change DoS threat level.

How do you arrive at that? Symmetric RTP has the problem I outlined in 
my draft. I just need to spoof the source of an IP packet, and then I 
can launch the attack.

-Jonathan R.

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

---

From: Tom Marshall <[email-masked]>
Date: Tue, 15 Jul 2003 07:50:23 -0700

> my draft. I just need to spoof the source of an IP packet, and then I 

A proper implementation on the server side will only accept a Symmetric RTP
packet which originates from the same IP as the RTSP control connection (and
yes, we should make sure to document this prominently).  Note that a client
could send a flood of media packets to another client on its own network,
but this is something that it can already do.  Thus the DoS threat level
remains unchanged.

-- 
For my birthday I got a humidifier and a de-humidifier...  I put them in
the same room and let them fight it out.
        -- Steven Wright

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 14:52:49 -0400

Tom Marshall wrote:

> yes, we should make sure to document this prominently).

That doesnt work with a nat that has more than one public IP. The RTP 
and RTSP requests might NAT to different addresses.

> Note that a client

It still seems like a problem, though.

-Jonathan R.

---

From: Tom Marshall <[email-masked]>
Date: Wed, 16 Jul 2003 00:33:11 -0700

> and RTSP requests might NAT to different addresses.

That is correct.  In such a case, a more complex mechanism would be needed. 
However, I have yet to enounter or even hear of such a NAT setup.  I think
it's safe to say that this is a rare corner case.

Symmetric RTP is a very simple solution that works in the vast majority of
implemented NATs (my guess is 99% or so) when the server is in the open and
the client is behind a NAT (or not).  I'm not trying to convince anyone
otherwise.  I'm only saying that there is a very heavy penalty in terms of
implementation complexity to get that extra 1% and we should keep a simple
option available for those who don't need to handle all of the possible
scenarios and corner cases.

> It still seems like a problem, though.

How so?

-- 
Logic is a systematic method of coming to the wrong conclusion with
confidence.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Jul 2003 03:37:58 -0400

inline.

> scenarios and corner cases.

I agree its the simplest solution in the cases where it works (though 
there is still that dos attack). The real issue is whether the group 
is interested in some of the other areas of applicability where the 
mechanism will not work, such as where the RTSP server is not in the 
open. If those are areas where you want RTSP to function, you would 
end up having two solutions, and you will have all the problems of 
figuring out which one to use. I've been down that route with SIP, and 
its not a pleasant one.

-Jonathan R.

---

From: Tom Marshall <[email-masked]>
Date: Wed, 16 Jul 2003 01:00:15 -0700

> figuring out which one to use. I've been down that route with SIP, and 

Regarding the dos attack, I maintain that the threat does not change from
the current usage without NAT traversal (provided the server enforces the
destination address constraint).  Please provide an example of a case where
the threat is increased if you believe otherwise.

Please correct me if I'm wrong (I'm not very familiar with SIP), but my
understanding is that SIP is primarily intended to be used in a peer to peer
model while RTSP is primarily intended to be used in a client server model. 
I suspect this is probably a big reason for the unpleasantness that you
mention.

For specific applications (such as ours), Symmetric RTP will cover about 99%
of the cases.  The remaining 1% are covered with TCP interleaving.  This has
been shown to be true with a similar mechanism in our proprietary RDT
transport.  It's unlikely that the added implementation complexity for the
other solutions will be worth the effort.  Therefore, Symmetric RTP is very
attractive in a real world application.

-- 
Most people are too busy to have time for anything important.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Jul 2003 11:05:20 +0200

Hi,

I have some comments about this. I think that we should rather consider 
what we need to solve the DoS attack scenario. The main reason for 
solving this in the RTSP setting is to lift the restriction that servers 
can send media only to the IP address the TCP connection comes from. If 
one can remove this restriction one very interesting use cases becomes 
available:

- Inviting RTSP servers into SIP calls or conferences. This is not 
possible otherwise if the controlling entity is different from the 
receiving entity. This will definitely be the case if one runs 
centralized conferencing with a focal point for all traffic.

There probably are more use cases when RTSP allows the use of other 
destination addresses.

They are in fact two problems, destination validation and NAT traversal. 
However they seem to using the same protocols and are connected, so I 
think we should take the opportunity to kill two birds with one stone.

However I think that we should be careful in the design of the 
mechanism. First it shouldn't incur more than the necessary extra RTT to 
do the validation in use cases where there is no NAT. For clients behind 
NATs there will be at least one extra RTT to create the address mappings 
in the NAT. The solution of servers behind NATs will be a low priority 
and the work may only consist of keeping the door open for such 
extensions unless they come very easily which I don't think.

Best Regards

Magnus Westerlund