reconsidering default exit policy
Geoffrey Goodell
goodell at cassandra.eecs.harvard.edu
Fri Mar 11 14:29:43 UTC 2005
> I might be a good idea to filter out multicast space, though. That's
> 224.0.0.0/4. And other "special use" spaces:
>
> 0.0.0.0/8 "this" network - only for source,
> never destination
> 192.0.2.0/24 reserved for documentation and examples
> 198.18.0.0/15 reserved for benchmarks
> 240.0.0.0/4 "reserved for future use", and listed
> in the "martian" list; I suppose one
> doesn't expect assignments from this
> space before a long time, but it could
> happen, I guess. Or the space could be
> used for a totally different use.
>
> (multicast plus reserved aggregate to 224.0.0.0/3)
>
> TCP connections to 6to4 auto-router space (192.88.99.0/24) don't make
> much sense either; we can filter those.
Your argument is that we can filter these without hurting the Tor
network, and generally speaking you are probably right. However, we
should require POSITIVE reasons to filter, not NEGATIVE reasons not to
filter. There is a subtle difference. In particular, I do not believe
that there would be any advantage to filtering these ranges, i.e. I
cannot think of a plausible attack-with-lawsuits resulting from not
filtering these blocks.
Tor should adopt the most liberal policy that avoids making the general
population angry, not the most conservative policy that allows essential
functionality to continue. Thus, we should not filter address ranges
because their IANA-decreed owners hate us, and we should not filter
address ranges because they are reserved for some functionality that we
do not think is necessary for the Tor network to transit. These excuses
are insufficient.
The difference between a "bastard operator from Hell" and a
"good-natured operator" is not so much a matter of the particular
filtering policies they set. It is that the former believes in
filtering by default, and the latter believes in filtering only what
needs to be filtered. In the presence of doubt, let's not filter.
Geoff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20050311/e07af376/attachment.pgp>
More information about the tor-talk
mailing list