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

["Dan Wing" <[e-mail]>]

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

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.
> 
> (since apparently the remote candidate was not an ICE agent, but could
> be a victim of a DoS attack)

Ok.

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

5 sounds plenty.

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

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


> 
> 
> Cheers,
> Ari=