[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] RTSP & NAT: Symmetric RTP

Hi Philippe,

Comments below:
philippe.gentric@philips.com wrote:
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?

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


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

True.

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.


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


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

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: magnus.westerlund@era.ericsson.se



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic