Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP

From: [email-masked]
Date: Wed, 12 Feb 2003 15:50:46 +0100

Magnus,

I count  2 issues left :

1) STUN and RTP/RTCP co-located:

I dont understand your concern here?

the STUN draft says: "A STUN  server can even be embedded within an end system."
I assume it means exactly that, no?

in practice it is easy for the server to discreminate between incomming STUN and incomming RTP or RTCP,
since STUN and RTCP have completely different header structures;
alos the STUN header contain a 128 bits nonce and the RTP/RTCP headers contain
at least one 32 bits nonce ....
So first the risk of collision is extremely small...
secondly a good implementation will always include structural/coherence checks, right ?

so what harm can it do that mis-formed RTCP packets would not cause
in the first place anyway ?

2) Sending RTP at a different IP address than the RTSP client is un-secure.

True.

Unfortunately this is a property of RTSP today ;-)

A) for NATs we simply want to extend it so that the RTP and RTCP
can have both different IP addresses instead of "only" different port numbers
> the additional danger is small compared to the benefit
and:

B) there is a need to fix that security hole _anyway_

One possible fix would be to define a RTCP extension whereby
before sending RTP data the server sends a "confirmation request"
with a Nonce and waits (with as short a time out as possible)
for a RTCP "confirmation responce" containing the same nonce and
originating from the correct target IP.

defeating that is pretty difficult (afaik it requires a man in the middle
in control of a router to trap the request and spoof the reply,
with a guy in that position your concerns are probably elsewhere !-)

regards,

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Feb 2003 16:20:59 +0100

Hi Philippe,

Comments below:

>I assume it means exactly that, no?

My concern is that it is not a clean, well engineered solution. However 
I can agree that it is possible to make it work. The second question is 
to Jonathan.

>in the first place anyway ?

I just took to heart the security consideration chapter of STUN that 
recommends that STUN server should avoid having other services that can 
open security holes. So its just a question that the server needs to be 
well built in regards to security and handling of bad messages.

>Unfortunately this is a property of RTSP today ;-)

Actually, if you look at RFC 2326 you can read the following in regards 
to destination parameter in the transport header:
  "To avoid becoming the unwitting perpetrator of a remote-
  controlled denial-of-service attack, a server SHOULD
  authenticate the client and SHOULD log such attempts before
  allowing the client to direct a media stream to an address not
  chosen by the server. This is particularly important if RTSP
  commands are issued via UDP, but implementations cannot rely
  on TCP as reliable means of client identification by itself. A
  server SHOULD not allow a client to direct media streams to an
  address that differs from the address commands are coming
  from."

So if this should is followed, i.e. do not allow use of destination. 
Then RTSP is not that unsafe.

>>the additional danger is small compared to the benefit

This additional danger is way, way to big. You can't allow usage of 
client specified destination on any scale as it is such a potent DOS 
tool. a few messages can generate a multi Mbps attack on a target. So I 
don't see anyway of allowing such a security breach to be used.

>with a guy in that position your concerns are probably elsewhere !-)

I think we should look at ways to fix the whole. Because there are also 
other usage's then NAT traversal to such a mechanism.

So from a security perspective I see the useful traversal methods are:
- STUN for single IP NATs, preferable cone NATs.
- Symmetric RTP for symmetric and multi-IP NATs.

Regards

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]