> Why not simply block that entire network in the Exit policy? You're missing the point .. we already blocked our *own* /16 in the exit. The problem was the thousands of academic journals, all of which have distinct addresses, that consider any traffic from our /16 as being "on campus" and thus not needing of authentication. As the exit node resided with that /16, any traffic sourced from it would appear to be "on campus" from the perspective of the other entity.
I could have : a) created an exit policy thousands of lines long prohibiting a.b.c.d/32:* for each of them b) used IPtables to do the same thing, but that would not make the prohibition known to clients and break things. c) use entries in /etc/hosts to accomplish the same things as "b)" with the same results. We found that since the list of exit nodes is known, people would actively seek those that ended in .edu and try to rape the journals with them .. downloading entire issues of various scientific journals (this happens on-campus too from misguided students, but that's easier to track down). If the network spec could easily handle any number of exit nodes, each with a policy of unlimited length .. this wouldn't be a problem (other than the ongoing maintenance headache). Likewise, if we had a few /24s to stick stuff like this into that were outside the primary /16 we could make it work .. but IP space is getting harder to come by, and it's hard to justify additional allocations when you already have a class B (plus, it costs money). Before anyone tells me it's "broken" to authenticate just by IP address .. I already know that .. but that's how most of the academic publishers do it at the moment. For the record, the DMCA complaints, subpoenas, and various angry phone calls were never a problem. It was the theft of academic journals (and that doing so jeopardized our subscriptions) that did it in. Cheers, Michael Holstein Cleveland State University *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
