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

From: Ari Keranen <[email-masked]>
Date: Thu, 19 May 2011 17:29:26 +0300

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.

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?

Cheers,
Ari

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 May 2011 11:25:51 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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,
> 
> > 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.

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

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

-d

> 
> 
> Cheers,
> Ari
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ari Keranen <[email-masked]>
Date: Wed, 25 May 2011 14:04:07 +0300

> could be launched.  The other way is that RFC5245 could be used

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)

> 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

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 25 May 2011 09:02:55 -0700

> From: Ari Keranen [mailto:[email-masked]]
> Sent: Wednesday, May 25, 2011 4:04 AM
> To: Dan Wing
> Cc: 'mmusic WG'
> Subject: Re: [MMUSIC] ICE TCP and TCP amplification attack (mitigation)
> 
> 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:
> 
> [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.

Such a statement seems out of scope for TURN-TCP, but it's the best we can
do without updating ICE itself to mention the TCP attack, I guess.

> 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
..................................^^^^
                                "other"
> MUST close the connection and consider all pairs with that remote
> candidate as failed.
> 

Ok.

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

5 sounds plenty.

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

Yes.

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

Yes, that is also a good idea.

-d

> Ari=