Subject: [MMUSIC] RTP denial of service

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Jul 2003 01:16:06 -0400

Folks,

I'd like to draw your attention to the following I-D that I submitted 
recently:

http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp-denialofservice-00.txt

This draft describes a denial-of-service attack using RTP. This attack 
can be launched using any protocol that uses an offer/answer-like SDP 
exchange, including SIP and RTSP. The draft also discusses ICE as a 
solution to the problem.

Comments welcome.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Jul 2003 13:41:45 +0200

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.

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

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

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.

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.

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.

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

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?

Best Regards

Magnus Westerlund

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Jul 2003 18:37:04 -0400

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

> simple limitations can't be used while still NAT traversal or TURN 

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

> 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 

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

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

> perfect reception pattern exist, keeping any congestion control based on 

Right.

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

> limited to that protocol.

Right.

> 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 

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.

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