Re: [tram] Allow TURN to forward inbound connectivity checks without permission

[Nils Ohlmeier <[e-mail]>]

> On Mar 20, 2018, at 12:17, Simon Perreault <[e-mail]> wrote:
> 
> 2018-03-20 10:31 GMT+00:00 Konda, Tirumaleswar Reddy <[e-mail] <mailto:[e-mail]>>:
> the TURN client could be subjected to DDoS attack (e.g. spoofed STUN packets from attackers, client wastes cycles validating the message integrity, and could also be subjected to bandwidth-hogging attack).
> 
> 
> That would be new to TURN, but not new to the client: NAT pinholes, created with STUN or otherwise, expose the client similarly. So while this is certainly worth mentioning in the security considerations section, I don't see this as a blocker.
> 
> I also can't think of a way that this could be exploited to mount any kind of practical attack against a specific target…


I guess you could divide this into three categories:

- the TURN client is an ICE agent, which needs to be prepared to handle any incoming traffic already any way
- the TURN client is not an ICE agent, but a STUN client, and as Simon pointed out needs to be prepared to receive traffic through the pin holes it created
- the TURN client is purely a TURN client and only ever expected to get traffic back from the TURN relay

I would assume the last scenario is not very common, but I don’t have any numbers to back that up.
I think Simon is right that it’s worth mentioning in the security considerations.

Best
  Nils Ohlmeier