Re: [tor-relays] Exit node rejection of special IPv4 blocks

2014-04-23 Thread grarpamp
On Wed, Apr 23, 2014 at 6:26 PM, Roger Dingledine  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 mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Exit node rejection of special IPv4 blocks

2014-04-23 Thread Roger Dingledine
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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


[tor-relays] Exit node rejection of special IPv4 blocks

2014-04-23 Thread Zack Weinberg
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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays