Balancing throughput versus getting Black-Holed
Hi All, I have a question. I would like to know other peoples experiences for exit nodes and the methods of mitigating getting black holed. I have a node that gets black-holed all the time now - it runs at 18Mibt - 41781FDC57238DAB955DF6D6E8400CEC5ACBE706 I have noticed smaller relays/exits on the same AS don't seem to run into the same problem. I was thinking of running two to three smaller exits at around 4MiBt or just going for a larger faster middle. Thoughs/Comments. I have been emailing the provider and their carrier but know one ever responds/reply's. Paul
What do you mean when you write "Black Holed" ? Are you referring to large sites online automatically blocking users, or your traffic being shut down by your provider? Rob On 2017-10-25 4:57 PM, Paul Templeton wrote:
Hi All,
I have a question. I would like to know other peoples experiences for exit nodes and the methods of mitigating getting black holed.
I have a node that gets black-holed all the time now - it runs at 18Mibt - 41781FDC57238DAB955DF6D6E8400CEC5ACBE706 I have noticed smaller relays/exits on the same AS don't seem to run into the same problem. I was thinking of running two to three smaller exits at around 4MiBt or just going for a larger faster middle. Thoughs/Comments.
I have been emailing the provider and their carrier but know one ever responds/reply's.
Paul _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
What do you mean when you write "Black Holed" ? Are you referring to large sites online automatically blocking users, or your traffic being shut down by your provider?
Yes and no - The carrier is doing it - so no traffic can get through to the providers system (My node- even me). It's automated and can be initiated by any entity using the carriers infrastructure. It's a simple Null Route - Someone is proberble oing a massive DDos... Paul
On 26 Oct 2017, at 09:06, Paul Templeton <paul@coffswifi.net> wrote:
What do you mean when you write "Black Holed" ? Are you referring to large sites online automatically blocking users, or your traffic being shut down by your provider?
Yes and no - The carrier is doing it - so no traffic can get through to the providers system (My node- even me). It's automated and can be initiated by any entity using the carriers infrastructure.
It's a simple Null Route - Someone is proberble oing a massive DDos...
I run one exit with exit traffic on a separate IP, and every week it gets a DoS attack from somewhere. My provider sends me an email when the DoS starts and ends. (Apparently someone thought it sensible to respond to some connections with a DoS, which is silly in a world with proxies.) The attacks generally only last ~15 minutes. How long is your relay blackholed for? You could: * use OutboundBindAddressExit to have your exit connections originate from another IP address * use a more responsive carrier, or one with better blackhole timeouts, if that is an option Eventually, we'd like to add an option to tor to split exit traffic over multiple IP addresses. If your provider only null routes a single IP address, that would help mitigate this issue. And save you setting up multiple relays. T
On 10/25/2017 11:31 AM, Paul Templeton wrote:
How long is your relay blackholed for? Usually 12Hrs - I'll look at a second IP to see if it helps a bit.
Having the ability to rotate address would be good... :)
Paul
I wonder how quickly the subnet would get black-holed. I've thought of doing that with IPv6. With a /64, the relay could use a new OutboundBindAddress for each circuit. But maybe the /64 would just get black-holed. DirPort and ORPort would, of course, be IPv4.
On 26 Oct 2017, at 10:23, Mirimir <mirimir@riseup.net> wrote:
On 10/25/2017 11:31 AM, Paul Templeton wrote:
How long is your relay blackholed for? Usually 12Hrs - I'll look at a second IP to see if it helps a bit.
Having the ability to rotate address would be good... :)
Paul
I wonder how quickly the subnet would get black-holed.
I've thought of doing that with IPv6. With a /64, the relay could use a new OutboundBindAddress for each circuit.
Or each stream. There's a design tradeoff here: using a different address for each stream provides less linkability between streams on the same circuit. But it may confuse remote websites that expect all requests from a page to come from the same source IP address. I think we would probably choose an IP per stream, because our design is willing to compromise usability on a few websites for privacy on all.
But maybe the /64 would just get black-holed.
Maybe. Shall we try it and see?
DirPort and ORPort would, of course, be IPv4.
Relays must have an IPv4 ORPort. Relays should also declare (if possible): * an IPv4 DirPort, to help other relays and tools like stem * an IPv6 ORPort, to help IPv6 clients T -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
On 10/25/2017 12:31 PM, teor wrote:
On 26 Oct 2017, at 10:23, Mirimir <mirimir@riseup.net> wrote:
On 10/25/2017 11:31 AM, Paul Templeton wrote:
How long is your relay blackholed for? Usually 12Hrs - I'll look at a second IP to see if it helps a bit.
Having the ability to rotate address would be good... :)
Paul
I wonder how quickly the subnet would get black-holed.
I've thought of doing that with IPv6. With a /64, the relay could use a new OutboundBindAddress for each circuit.
Or each stream.
Right, per stream :) That'd be cool.
There's a design tradeoff here: using a different address for each stream provides less linkability between streams on the same circuit. But it may confuse remote websites that expect all requests from a page to come from the same source IP address.
Could circuit vs stream be configurable in the client?
I think we would probably choose an IP per stream, because our design is willing to compromise usability on a few websites for privacy on all.
But maybe the /64 would just get black-holed.
Maybe. Shall we try it and see?
DirPort and ORPort would, of course, be IPv4.
Relays must have an IPv4 ORPort.
Relays should also declare (if possible): * an IPv4 DirPort, to help other relays and tools like stem * an IPv6 ORPort, to help IPv6 clients
T
-- Tim / teor
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 26 Oct 2017, at 10:39, Mirimir <mirimir@riseup.net> wrote:
On 10/25/2017 12:31 PM, teor wrote:
On 26 Oct 2017, at 10:23, Mirimir <mirimir@riseup.net> wrote:
On 10/25/2017 11:31 AM, Paul Templeton wrote:
How long is your relay blackholed for? Usually 12Hrs - I'll look at a second IP to see if it helps a bit.
Having the ability to rotate address would be good... :)
Paul
I wonder how quickly the subnet would get black-holed.
I've thought of doing that with IPv6. With a /64, the relay could use a new OutboundBindAddress for each circuit.
Or each stream.
Right, per stream :) That'd be cool.
There's a design tradeoff here: using a different address for each stream provides less linkability between streams on the same circuit. But it may confuse remote websites that expect all requests from a page to come from the same source IP address.
Could circuit vs stream be configurable in the client?
That would split the anonymity set of clients, making any client that chose the non-default option stand out. Clients like Tor Browser already do some fairly complicated things to isolate circuits from different websites, and I wouldn't want to interfere with that.
I think we would probably choose an IP per stream, because our design is willing to compromise usability on a few websites for privacy on all.
I'll also talk to the Tor Browser folks about this, because they may have an opinion. -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
participants (4)
-
Mirimir -
Paul Templeton -
Robert Keizer -
teor