Subject: Re: [MMUSIC] RTP denial of service

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jul 2003 11:38:33 +0300

Jonathan,

Thanks for bringing up this problem. I agree that the attack
exists, and I also agree that nothing in the RTP packets (such
as SRTP) can help prevent such attacks. I not expert enough
to say anything about suitability of RTCP or STUN.

Attacks of a similar nature have been discussed in the context
of other protocols, for instance Mobile IPv6. The general
nature of such attacks is that a signaling protocol conveys
an address, and the lack of verification for this address
results in a vulnerability; attackers choose the address of
an innocent third party and start "bombing" this address
with packets. What makes these attacks bad is that the
attacker can initiate the attack with just few packets,
a legitimate entity in the network does all the hard work,
and the victim's link becomes congested.

The attack has always serious consequences due to its
amplification factor. In SIP, this factor is due to
the bandwidth difference in signaling vs. payload. In
Mobile IPv6, this factor was due to the ability to "open"
a connection, speed it up, and then move it towards the
victim.

What also makes the attack hard is that the packets to
the victim never come from the attacker, they come from
another, legitimate entity in the network. This makes the
tracing of the attack hard: the attacker may be traceable
from that entity, but can we be sure that the administrator
of the entity can be reached for assistance? This may be
easy if the entity is owned by an operator, but what if
its my home server or someone's windows PC? However,
assuming you do get the help of the administrator, there
seems to be a few different levels of hardness
for tracing the attacker then:

- No verification: The attack was initiated by a
   packet sent to the entity, no assurance of the
   authentication of the attacker or the validity
   of the source address in the packet.

   SIP INVITE without TLS and authentication appears
   to allow this, no?

   What makes this level tricky is that there are
   designs where DoS attackers can be traced even
   if they lie about their addresses, e.g. itrace.
   However, these mechanisms only work for bulk
   attacks, and here we only send a few signaling
   packets.

- Source address verification: The attack can only
   be launched after some exchange of packets, where
   the source address of the packet has been verified
   to be valid.

   In SIP, anon Digest would allow you to do source
   address verification. Similarly, even server-side
   only authenticated TLS would suffice for this
   check.

   Note: in Mobile IPv6, the address of the attacker
   was conveyed also in the packets to the victim,
   but this does not appear to be the case in SIP/RTP,
   because the RTP packets don't contain the address
   of the node that initiated the signaling.

- Authentication: the attacker's identity is
   authenticated in some manner, you can probably
   trace the attacker down to his postal address/passport/
   credit card.

I believe we should strive for making the tracing
of the attack at least so hard that the attacker has
to give his IP address information, i.e., make the first
case not allowed. Still, tracing is a post-attack
activity, expensive and unreliable. So I believe you
are right in trying to prevent such attacks.

A few words about prevention. Typically, a "return
routability test" approach is used, as I think you
are doing also for STUN. I'm not expert enough in
STUN to know if it provides sufficient binding
between requests and responses so that off-path
attackers can't easily spoof responses? But I would
guess you have taken this into account.

Another issue is whether there needs to be a binding
between the signaling exchange and the STUN exchange,
e.g. a session identifier or something like that? Or
is it sufficient to rely on the right timing? What about
busy servers, wouldn't the timing of the attack be
more likely to succeed with them?

Finally, the prevention mechanisms themselves may
be susceptible to an attack. An example: initiate
N sessions with different servers, all pointing to the
same victim node, who gets a lot of STUN queries.
This attack does not have amplification, but it
is hard to trace, harder than a direct dos packet
storm from a single source, and harder than than
a reflection attack. In some other cases, such
attacks have been made easier to trace by using
solely the source address of a packet in initiating
responses and protocol actions. But I understand
that this may not be an option here. Demanding
TlS/anon digest from all SIP signaling exchanges
does force the attacker to give up a lot of
information and some CPU cycles, so that may
be sufficient.

--Jari

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2003 04:06:13 -0400

Thanks for your comments. Responses inline.

> and the victim's link becomes congested.

Right. I agree its the same attack as can be done in Mobile IP.

>   SIP INVITE without TLS and authentication appears

Yes. We do have a way for a server to prevent this level, though. SIP 
provides an anonymous digest authentication. Really, the only purpose 
of this is for the server to verify that the client can be reached at 
their advertised IP address. I should probably mention in the I-D that 
servers ought to do this. Generally its a good idea not to process 
packets that are completely unauthenticated...

>   attacks, and here we only send a few signaling

Right. Worse yet, the signaling can be relayed through proxies, which 
would mask the identity of the attacker from the entity, if no 
authentication is used.

>   only authenticated TLS would suffice for this

Right, I see we are on the same page about anonymous digest here.

>   of the node that initiated the signaling.

Right.

> case not allowed.

Agreed.

> Still, tracing is a post-attack
> are doing also for STUN.

Right. Thats exactly why STUN works.

  I'm not expert enough in
> guess you have taken this into account.

Yes. STUN has a transaction ID present in the request, which has to be 
mirrored in the resposne. An off-path attacker would need to be able 
to eavesdrop the stun request in order to generate a response. STUN 
itself has extensive security considerations, and we protected it as 
best as possible.

> more likely to succeed with them?

Not sure I follow this. In ICE, the STUN exchange is correlated with 
the signaling exchange through the STUN username and password, which 
are conveyed in the SDP. Thus, when a UA receives a STUN request, it 
knows from the username and password the exact sip dialog and media 
stream its associated with.

I'm not sure what this has to do with busy servers, though.

> information and some CPU cycles, so that may

I think so. There are many other ways to launch the no-amplification 
version you describe. For example, sip itself! Send a response with a 
Via header pointing to the target. Or a request with a Route header 
pointing to the target.

-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