Re: eliminating bogus port 43 exits

[grarpamp <grarpamp@xxxxxxxxx>]

While node operators are certainly welcome to characterize and
define both traffic and policy as deemed fit for their own purposes...

I might suggest that node operators examine things more fully in
order to make better policy decisions overall.

1 - The use of any given TCP port alone is not sufficient to qualify
traffic on it as "illegitimate, bogus, undeserving, invalid, scanner,
junk, etc". For all anyone knows, such traffic could be saving the
world, over ports otherwise unavailable to the client, EXACTLY as
per one of Tor's very legitimate use cases.

2 - Impact can be defined as number of connections over time and/or
bandwidth used. The operator would be well served by deploying and
using netflow analysis to better understand their exit's traffic.

2a - Tor itself should be intrumented with stats about attempted
circuit construction that fails due to exit policy.

3 - Further, there needs to be an understanding of what the traffic
ACTUALLY IS. Operators should be using tools such as wireshark,
tcpdump, bro, etc to determine the content. And if it turns out to
be encrypted to destinations and services unknown, NO such determination
can be made. The only thing left to go on is impact as in #2 above.

4 - /etc/services is defunct law and means very little these days.
App developers don't write to it, they just include a -p <port>
knob and a seemingly unused default. Clients use that -p knob to
avoid app conflicts, fix bum network policy, or simply to find a
hole that works for their perfectly legitimate uses, such as VPN's.

5 - There are many more whois servers than those listed, particularly
referral/delegated whois servers. The list is in permanent flux.

6 - Clients may have chosen certain exits to '[ab]use' for certain
ports, destinations, or activities, skewing the results for any
single exit or set of exits.

7 - It is well established practice at ISP's, corporations,
institutions, etc... that network admins may observe content in
order to determine policy direction, protect their network, and in
general, figure out what's up. Disclosing that content and/or acting
specifically on, or against, users, when the traffic was not collected
for that purpose, is entirely different and governed by strict laws,
at least in the US. Tor is no different than being a mini ISP, do
as any ISP would.

Bottom line, one must either:
1 - Take the corporate, block all but known stance. Hopefully know
 that people will still jam their unknowns through your knowns.
2 - Block/allow based on reasonably thorough analysis of content,
risk, load, etc.
3 - Block on whim, gut feel, religion, sunspots, etc.
4 - Allow all.

Unfortunately, #2 is usually the last to be chosen because it requires
the largest investment in time, knowledge, etc.


And lastly, as food for Tor development thought... there is no
interaction between Tor and kernel level packet filters. Most network
admins use such packet filters as their primary point of wizardry.
Tor could be enhanced with a mode of operation that interfaces in
real time with such filters to determine when to create circuits.