On Fri, 12 Jun 2009 15:24:33 -0400 grarpamp <grarp...@gmail.com>
wrote:
>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.
The problems with the above, however, run like this. whois is a
service that ought to be comparatively little used, at least relative
to https, yet unrestricted exits to port 43 and 443 resulted in port 43
exits numbering many times the port 443 exit count. Which are valid
and which not? Well, the ones going to known, legitimate whois server
IP addresses are either valid or they aren't getting what they *are*
trying to get. I agree that it is possible that the ones going to other
IP addresses might truly be going to whois servers not identified in my
exit policy, but I am not currently able to believe that any large
fraction of them are.
>
>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.
Normal whois responses are not very large, a few KB at most, and
much smaller than the typical web page. Your definition above of the
impact is only part of the load. There is a significant cost to building
a circuit and to tearing it down later. When my port 43 exit counts
were several times the combined totals for all 320-odd other ports, it
looked to me very much as though something were not right and also that
it was quite a burden upon the tor network.
>
>2a - Tor itself should be intrumented with stats about attempted
>circuit construction that fails due to exit policy.
Really? I'm not sure how you would accomplish that in any meaningful
way. The normal situation is that a client examines the exit policies to
find exit nodes whose policies do allow the exit *before* the client
constructs the circuit. Thus there is normally no failure due to mismatches
between the client's requests and the exit nodes' policies. There are
exceptions, of course, which occur after an exit node's policy has been
changed but before the changed descriptor has been propagated to all clients.
When mismatches occur under this scenario, then both client and exit node
can tally them, but how useful would those tallies be?
>
>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.
Again, this appears to be untrue. If the connection is made to a
legitimate server, then the request is very likely legitimate. If it
is not a legitimate request for the service standardly offered on the
port number in question (whois, in this case), then the illegitimate
request is unlikely to get what it is looking for from the legitimate
server at that address.
>
>4 - /etc/services is defunct law and means very little these days.
It never was law; it was, and still is, an RFC. Keep in mind, too,
that port numbers < 1024 (e.g., port 43) are not only reserved numbers,
but *privileged* port numbers. It is true that people do deliberately
falsify the usage under some circumstances (e.g., the tor project's
recommendation that port 80 be used for ORPort of DirPort to allow
clients behind fascist firewalls to access the tor network), but these
are the exceptions that illustrate the rule.
>App developers don't write to it, they just include a -p <port>
Sure, they do.
>knob and a seemingly unused default. Clients use that -p knob to
>avoid app conflicts, fix bum network policy, or simply to find a
But that has always been true. See, for example, ancient commands
like telnet(1). Yet they typically have a default value that is the
number reserved by IANA for the service in question.
>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.
I pointed out in another followup a short time ago that my exit
policy leaves port 4321 (rwhois) unrestricted, yet the exit counts for
that port are very tiny, so I don't think that referrals account for a
significant portion of the unrestricted port 43 exit counts.
>
>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.
True. I don't know what can be done about that, though.
>
>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.
>
Other folks have already begun addressing this issue, and I can't
think of much of value to add to what they've already written.
>
>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.
>
Interesting thought. Would you elaborate a bit on what you have in
mind?
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
