Re: [MMUSIC] RTP denial of service

[Jonathan Rosenberg <[e-mail]>]

Sorry for the delay in responding, Magnus. Responses inline.

Magnus Westerlund wrote:

> Hi Jonathan,
> 
> I have now had time to read your draft. It summaries the problem of the 
> attack fairly well. However I think one can elaborate a bit more on some 
> use cases and in relation to NAT traversal.
> 
> First, the problem of destination addresses in combination with NATs 
> that use multiple addresses. If a NAT would assign different NAT 
> mappings to different external addresses there is a problem with the 
> limiting text that RTSP has. This also is present for a single RTP 
> session where RTP and RTCP will be separate flows. This leads to that 
> simple limitations can't be used while still NAT traversal or TURN 
> servers are in use.

Yes, I agree. That is a general RTSP issue.

> 
> Secondly the RTCP prevention that you mention in chapter 3 has more 
> flaws then you describe, but not one of them you describe I would say.

OK, well I'm glad we agree even though its for the wrong reasons...

> I 
> don't see a reason to force the sending side to have this stop and go 
> behaviour you describe. I would more work in the terms of how TFRC 
> behave, I think. If no RTCP reports are received the sending bit-rate is 
> throttled back, to almost non existing levels. This will limit the 
> severity of the attack. However with using many sessions it might still 
> be possible to achieve enough force amplification.

I'm not that familiar with TFRC. How is the initial rate set? That 
could make a big difference too.

> 
> The flaw you missed in your description of using RTCP as limiting factor 
> is first that if the attacker directs a RTCP stream to itself and only 
> the RTP stream to the target, it can simple generate false RTCP reports.

Ah - good point. I hadnt thought of that. Normally its not possible, 
but draft-ietf-mmusic-sdp4nat will allow this.

>  The senders RTCP reports contains the number of packets sent, which 
> makes it easy to increase the RTCP receiver reports extended counter. 
> The initial RTP sequence number are usually transmitted in RTSP's 
> RTP-Info header. Therefore all necessary information for faking a 
> perfect reception pattern exist, keeping any congestion control based on 
> RTCP reports happy.

Right.

> 
> Third, the solution space. As you mention an alternative to using STUN 
> in this requesting mechanism would be to develop a RTP payload format 
> and RTCP packet type to contain necessary information of granting a 
> media stream. What may be missing in STUN is the possibility to provide 
> information about the media stream that the receiver accepts.

That information is conveyed in the signaling protocol. Clearly this 
information is only useful when there is NOT an attack, so the 
recipient would be privy to the signaling.

> 
> However I don't know if such a solution would be any better. Maybe on 
> the paper it would have a clearer demultiplexing than between STUN and 
> RTP. However STUN can be used with any media protocol that can be 
> differentiated on the first byte, while a RTP/RTCP solution would be 
> limited to that protocol.

Right.

> 
> Fourth, have you looked at what solutions DCCP would provide to this 
> problem? I think that the session establishment could ensure that the 
> client accepts the media stream.

Yes, I believe it would. However, we have some time to go before that 
really becomes deployable.

> 
> Fifth, what is the current status of ICE? Can we expect any progress for 
> ICE within the IETF.

We will be discussing this today in mmusic. Yesterday, sipping 
re-affirmed its desire to move forward with ICE. We agreed that there 
are really two documents. One is the actual ICE mechanism, which is 
not sip specific at all. The other is use cases that show how ICE is 
used with SIP. THe latter will be happening in sipping, as an 
alternative to the current draft-ietf-sipping-nat-scenarios document. 
The former, however, appeared to be more of an mmusic issue. So, the 
sipping group wants mmusic to take ICE as a work item, in fact.

> 
> Sixth, doesn't one need to use STUN with authentication to prevent other 
> security attacks that based on falsifying STUN responses, even when the 
> session establisher is not an attacker?

Yes, and thats why there is authentication in stun. Mostly the 
authenticaiton is of the SERVER - the client identity is not that 
important.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com


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