I'd like a sanity check on this list of special-purpose IPv4 blocks which I'm currently forbidding in the CMU exit node's policy. I'm most uncertain about denying access to multicast (224.0.0.0/4) and 6to4 router anycast (192.88.99.0/24) -- I *think* there are no scenarios where someone would actually need to get at either of those via Tor, but I could be wrong.
# Reserved IPv4 addresses, sorted by RFC and then numerically reject 255.255.255.255/32:* # RFC 0919: "limited broadcast" reject 224.0.0.0/4:* # RFC 1112: multicast reject 240.0.0.0/4:* # RFC 1112: future addressing modes
reject 0.0.0.0/8:* # RFC 1122: "This host" source address reject 127.0.0.0/8:* # RFC 1122: Loopback
reject 10.0.0.0/8:* # RFC 1918: private use reject 172.16.0.0/12:* # " " " reject 192.168.0.0/16:* # " " "
reject 198.18.0.0/15:* # RFC 2544: test environments reject 192.88.99.0/24:* # RFC 3068: 6to4 relay anycast (???) reject 169.254.0.0/16:* # RFC 3927: link-local
reject 192.0.2.0/24:* # RFC 5737: documentation reject 198.51.100.0/24:* # " " " reject 203.0.113.0/24:* # " " "
reject 100.64.0.0/10:* # RFC 6598: "shared space"/"carrier grade NAT" reject 192.0.0.0/24:* # RFC 6890: future special purposes
TIA, zw
On Wed, Apr 23, 2014 at 03:12:36PM -0400, Zack Weinberg wrote:
I'd like a sanity check on this list of special-purpose IPv4 blocks which I'm currently forbidding in the CMU exit node's policy. I'm most uncertain about denying access to multicast (224.0.0.0/4) and 6to4 router anycast (192.88.99.0/24) -- I *think* there are no scenarios where someone would actually need to get at either of those via Tor, but I could be wrong.
Hi Zack,
Best practice is to only block addresses and destinations that you know you don't want to reach. When you block addresses where somebody tells you there should be nothing there, you're narrowing out the future. If the RFC changes tomorrow and you don't notice, suddenly you're blocking connections to a piece of Africa or whoever gets that IP space. And if indeed nobody is using it, why block it?
Thanks! --Roger
On Wed, Apr 23, 2014 at 6:26 PM, Roger Dingledine arma@mit.edu wrote:
On Wed, Apr 23, 2014 at 03:12:36PM -0400, Zack Weinberg wrote:
I'd like a sanity check on this list of special-purpose IPv4 blocks which I'm currently forbidding in the CMU exit node's policy. I'm
Best practice is to only block addresses and destinations that you know you don't want to reach. When you block addresses where somebody tells you there should be nothing there, you're narrowing out the future. If the RFC changes tomorrow and you don't notice, suddenly you're blocking connections to a piece of Africa or whoever gets that IP space.
Yes, a lot of BGP people did/do that, blocking not just the thou shalt not route stuff, but also just plain unallocated stuff, leading to partial blackouts and weird routing for ages after allocation till everyone updated their silly filters. Search "bogons".
And if indeed nobody is using it, why block it?
Everything is pretty well collated and described here... https://www.iana.org/numbers
6to4 appears global. Multicast won't work over Tor. Yet that huge swath of space would seem ripe for better management/assignment someday. Nanog would have that thread.
For shalt not... it probably doesn't matter if you block the whole non-global special purpose lot. A couple reasons should be obvious: - To protect yourself and nearby lan/wan systems from remote access via selective use of you as the exit towards those addresses. Obvious example is rfc1918 to gratuitously reconfigure your modem/router for you. - To stop building and wasting circuits for users who dump/leak packets with those destinations into Tor, such packet dests would not be forwarded/accepted by your ISP's routers anyways.
It would not be difficult for some relays to run a report on what is seen trying to exit them.
tor-relays@lists.torproject.org
-
grarpamp -
Roger Dingledine -
Zack Weinberg