Re: [MMUSIC] RTSP & NAT: Symmetric RTP

[philippe.gentric@philips.com]

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
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic