Re: [MMUSIC] RTSP and NATs

[Magnus Westerlund <magnus.westerlund@era.ericsson.se>]

Hi Philippe,

I get a bit confused by the below but I will try to answer stating my 
understanding of your questions.

philippe.gentric@philips.com wrote:

> Magnus,
>
> symetric RTP and my other mail about "confirmation"
> are the same spirit then no?
>
> it is the principle that "the server sends only if it has received something",
> and the something must be a nonce to make hacking harder:
> and the SSRC can serve that purpose
>
> is that what you mean ?
>  
Symmetric RTP and security challenge for the UDP flows are two slightly 
different things.

Symmetric RTP is based on that the client sends packet to the server 
that needs to have some protection against hijacking. That protection 
can be provided with SSRC of the client. This SSRC needs to be 
communicated between the client and server through other means (RTSP). 
This is not safe to a man in the middle attack.

Security challenge is different in some ways. This is my understanding 
of how it could work. In this case the client asks the server to send 
media to any single IP/port number. Before sending a lot of traffic to 
these ports, the server needs to ensure that these ports are prepared to 
receive this traffic. To ensure this we make a security challenge either 
from server to client or the other way around. For STUN and 
"destination" usage the client initiates the challenge. In case of 
symmetric RTP the client could send a response without the challenge to 
id it clearly. The goal is to ensure that the client agrees to receive 
the traffic. By having the receiver sign the message going from client 
to server with keys that are transported through other ways we can 
ensure that no other than the intended receiver can verify that it 
agrees. This makes it possible to protect also against man in the middle 
attacks. It will of course requires secure RTSP signaling.

The security challenge could as describe be taken into use also with 
symmetric RTP to identify that it is the correct receiver that sends 
these packets to use for binding. However this is still possible to 
attack and create an redirect by a man in the middle changing the 
packets source IP/port. By having a signed ACK we can at least ensure 
that the man in the middle can not do more than being a relay.

Conclusion is that the security challenge initiated from server towards 
client can be made safe assuming this mechanism. However symmetric RTP 
can never be safe against man in the middle attacks.

I hope that clarified the difference between the security challenge as a 
general mechanism and symmetric RTP as a special usage.

Best Regards

Magnus

--

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