Re: [MMUSIC] ICE TCP and TCP amplification attack (mitigation)

[Ari Keranen <[e-mail]>]

On May 23, 2011, at 9:25 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Ari Keranen
>> Sent: Thursday, May 19, 2011 7:29 AM
>> To: mmusic WG
>> Subject: [MMUSIC] ICE TCP and TCP amplification attack (mitigation)
>> 
>> Hi all,
>> 
>> Flemming identified a possible TCP amplification attack in ICE TCP:
>> 
>> On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote:
>>> - Section 12
>>> I believe there is a TCP amplification attack similar to the STUN
>> amplification attack that requires consideration, since the TCP
>> connection is established prior to any STUN/ICE checks and involves TCP
>> state creation on the part of the attacked party.
>> 
>> That is, an attacker could put in the SDP offer a set of passive
>> reflexive candidates with the address of the victim and the answerer
>> would make a bunch of TCP connections towards the victim.
> 
> That attack is inherent to ICE itself, and not the fault or cause of
> the TURN-TCP specification.  If text is added to TURN-TCP, it would
> be nice to couch it with something like:
> 
>  A STUN amplification attack is described in Section 18.5.2 of 
>  [RFC5245], but unfortunately that specification did not describe
>  how [RFC5245] can also be used to launch a TCP amplification
>  attack.  
> 
> and the describe how TURN-TCP is but one way the TCP amplification
> could be launched.  The other way is that RFC5245 could be used
> without TURN-TCP.

I guess this is not really problem with TURN-TCP, but rather with ICE TCP, whether you use TURN or not. But you're right, the basic amplification attack is inherent to ICE itself. TCP just makes it worse since the victim needs to create TCP connection state instead of just dropping unsolicited UDP packets. Maybe we could say something along the lines of:

  A STUN amplification attack is described in Section 18.5.2 of [RFC5245]. Same considerations apply to TCP, but the amplification effect with TCP is larger due to need for establishing a TCP connection before any checks are performed. Therefore, an ICE agent SHOULD NOT have more than X outstanding TCP connection attempts with the same peer to the same IP address.


Regarding this attack, we could also add to the end of section 7.1 (STUN Client Procedures) in ICE TCP something like:

[once the connection is established] if the peer's response to the connectivity check is something else than a STUN message, the agent MUST close the connection and consider all pairs with that remote candidate as failed.

(since apparently the remote candidate was not an ICE agent, but could be a victim of a DoS attack)

>> A possible mitigation, as Flemming suggested, would be to limit the
>> number of outstanding TCP connection attempts to the same IP-address.
>> That sounds reasonable to me, since having many (un-frozen) candidates
>> from the same IP address seem unlikely anyway, but are there any other
>> ideas?
> 
> That sounds like a good approach.  

OK, then we'd need a recommended number; how many outstanding attempts to the same IP address do we allow?

Technically, one should be enough for all "normal" cases (right?), but maybe, e.g., more than one interface may in fact be behind the same CGN so more could be useful in some scenarios. How about 5? That should be enough for even more exotic cases, but yet make any DoS attack pretty weak.

> I wonder if Errata should be raised against RFC5245, instead or in
> addition?

Do you mean that RFC5245 should also mention the added effect of TCP?

Anyhow, probably also 5245(bis) could limit the number of outstanding checks to the same IP address even if UDP is used and consider non-STUN responses as a sign of invalid candidate, as discussed above.


Cheers,
Ari