Re: Filtering out attacks?

[alexyz@xxxxxxxxxx]

On 17 May 2005 at 16:59, Adam Langley wrote:
> It's important to remember that the circuit route is decided at
> connection time - before any higher level information is available.
> Since this is the case, one cannot use information like "I won't
> connect to google.com" from the directory.
>
> Thus any application level filtering has to be network wide. The
> alternative is a non-deterministic "sometimes Google works, sometimes
> it doesn't" and that's a very bad user experience.
>
> (yes, a node could wait until after getting the first header before
> making the connection. That might work for some protocols. For HTTP it
> would have to be site level filtering only because many requests can
> be sent down the same connection. But we can do site level filtering
> already with exit rules. Don't underestimate how nice it is that Tor
> has so far avoided touching the traffic at all.)
>
> Do you have specific examples of where this would be a good idea?

I wasn´t really thinking of high level filtering such as IP filtering or content filtering but more
on (invalid) packet header filtering. For example, deliberate use of bad checksums, unusual
TCP flags or IP options, invalid sequence numbers, spoofed addresses, duplicate TCP
packets with differing payloads, packets with short TTLs that expire between targets, and so
on. Yes, this would break the connection after the node had negotiated with the client but
you can argue that the packets were invalid in the first place and should not be sent at all.

I guess what I was suggesting was an Intrusion Detection System filtering Tor´s output. IDS
systems can be very complex and I don´t think this should be Tor´s priority. I can always
resort to third-party applications if I wish to do so.