IDS bells ringing

Chris Palmer chris at eff.org
Wed Feb 1 03:33:02 UTC 2006


patgus wrote:

> For instance, a solution similar to hogwash

Incorporating an IDS into Tor (or just running one alongside Tor) has 
been proposed before. Nothing can stop Tor server operators from running 
an IDS on the Tor traffic.

But doing so has its problems, such as when the Tor exit policy is not 
the same as that of the IDS (or firewall) the Tor server is subject to. 
In that case, a server may be falsely advertising its capabilities, to 
the detriment of the Tor network.

There is also this comment in the technical FAQ wiki:

http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#head-ebe87162a46f267eb697e23fb77e85e4cf643dd0

"Adding an Intrusion Detection System to handle exit policies would 
increase the security complexity of Tor, and would likely not work 
anyway, as evidenced by the entire field of IDS and counter-IDS papers. 
Many potential abuse issues are resolved by the fact that Tor only 
transports valid TCP streams (as opposed to arbitrary IP including 
malformed packets and IP floods), so exit policies become even _more_ 
important as we become able to transport IP packets. We also need to 
compactly describe exit policies in the Tor directory, so clients can 
predict which nodes will allow their packets to exit -- and clients need 
to predict all the packets they will want to send in a session before 
picking their exit node!"

I have not read all the literature, but from what I've seen the entire 
IDS field is close to being discredited. (I could be wrong.) Like spam 
filtering, automated source code auditing and virus scanning, it's an 
AI-hard problem. Now, that doesn't mean you can't get good results, but 
it does mean you need to be a statistics genius with lots of free time, 
patience, and a very closely specified task domain.

The cost of failure when applying such tools to transport and network 
layer data is very high.

> At least then we could say that we were doing as much as is possible
> to prevent this and probably as much as any business in the industry.

I think we already are pretty close to doing as much as is reasonable. 
Yes, it's *possible* to apply network, transport, content and other 
layer filters, but it's not at all clear they're worth the cost, 
complexity, and entertaining new failure modes.

Tor's exit policies in the hands of a responsible operator, together 
with reasonable and polite negotiation, have been enough so far. At 
least they have been in my experience.

> lol, most risks in the computer industry need to be litigated, not
> mitigated. 'Tis a bit of a situation though, how do you hold
> Microsoft responsible without crushing Debian?

And/or legislated, as the argument goes. This is also a highly 
problematic proposition. Perhaps you could have some sort of vendor 
liability law providing a cause of action for when software fails, but 
with some kind of carve-out for FOSS software. That's a whole can of 
worms I don't want to get into, but if you want to know some of the 
potential problems, read up on anti-spyware legislation and proposals 
for legislation.



More information about the tor-talk mailing list