Re: [tor-relays] Balancing throughput versus getting Black-Holed

2017-10-25 Thread teor 

> On 26 Oct 2017, at 10:39, Mirimir  wrote:
> 
> On 10/25/2017 12:31 PM, teor wrote:
>> 
>>> On 26 Oct 2017, at 10:23, Mirimir  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




signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Balancing throughput versus getting Black-Holed

2017-10-25 Thread teor 

> On 26 Oct 2017, at 10:23, Mirimir  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




signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Balancing throughput versus getting Black-Holed

2017-10-25 Thread Mirimir 
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.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Balancing throughput versus getting Black-Holed

2017-10-25 Thread Paul Templeton 

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

Re: [tor-relays] Balancing throughput versus getting Black-Holed

2017-10-25 Thread teor 

On 26 Oct 2017, at 09:06, Paul Templeton  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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Testing Golang relay implementation

2017-10-25 Thread teor 

> On 26 Oct 2017, at 06:58, Michael McLoughlin  wrote:
> 
> ...
> 
> In testing it took a little bit of finagling to get chutney to accept a 
> non-Tor "platform" item in the descriptor. Turned out adding a "proto" line 
> as well is enough.

I think this is a feature of the tor directory authority implementation, not 
chutney.
(Chutney doesn't do anything with platform or proto lines.)
Directory authorities will only synthesise a proto line for platforms that 
claim to be
Tor, because they can't be sure what features non-Tor platforms support.

> But it did occur to me that other code may assume the "platform" line takes a 
> certain form.

It shouldn't, that's what protocol lines are for.

But any alternate implementation will never be used as a v3 HSDir, because it
would need to claim to be Tor 0.3.0.8 or later for v3 onion services to use it. 
This
is a poor design decision on our part: just like consensus methods, when we 
break
a protocol version, we should allocate a new number, and check it.
(Or we should exclude broken versions from the consensus.)

I've opened this ticket to fix that:
https://trac.torproject.org/projects/tor/ticket/23998

> I can easily change the descriptor if necessary?

As long as it conforms to the spec, it's fine.

We should really fuzz descriptor parsers better.
But that's not an appropriate thing to do on the live network, and some
parser code only runs on descriptors on the live network.

T

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

Re: [tor-relays] Balancing throughput versus getting Black-Holed

2017-10-25 Thread Paul Templeton 

> 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

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

Re: [tor-relays] Balancing throughput versus getting Black-Holed

2017-10-25 Thread Robert Keizer 
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




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Balancing throughput versus getting Black-Holed

2017-10-25 Thread Paul Templeton 
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

Re: [tor-relays] Troubleshooting rasptor4273 (was: Decline in relays)

2017-10-25 Thread rasptor 4273 
> Are you behind a NAT?
Yup, that was it. On the day my relay disappeared from the consensus, I
reset my modem - having completely forgotten about the port forwarding...
So I set up port forwarding and my relay is present again in the Consensus
Health.

Thanks for the help!
Joep

On Wed, Oct 25, 2017 at 12:20 AM, teor  wrote:

>
> On 25 Oct 2017, at 08:35, rasptor 4273  wrote:
>
> However there's also a lot of this in that file:
> Oct 24 16:55:45.000 [warn] Your server (24.132.17.230:9001) has not
> managed to confirm that its ORPort is reachable. Please check your
> firewalls, ports, address, /etc/hosts file, etc.
> Oct 24 16:55:45.000 [warn] Your server (24.132.17.230:9030) has not
> managed to confirm that its DirPort is reachable. Please check your
> firewalls, ports, address, /etc/hosts file, etc.
>
>
> Your relay won't publish its descriptor until it confirms these ports are
> reachable.
>
> Has your IP address changed?
> Are you behind a NAT?
> Has your provider blocked these ports?
>
> T
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Testing Golang relay implementation

2017-10-25 Thread Roger Dingledine 
On Tue, Oct 24, 2017 at 10:54:38AM -0700, Michael McLoughlin wrote:
> Yes I am very aware of Tom van der Woerdt's previous work, and I am
> attempting to avoid some of the problems he faced. This implementation is
> pure Go, so I will not have cgo-based issues at least.

Great! Yes, I think the memory bloat was the main issue that stopped Tom.

Also, you should take a look at Alex's talk about his erlang Tor relay
implementation experiences, including lessons learned and why he became
less enthusiastic about maintaining a separate Tor relay implementation:
https://media.ccc.de/v/SHA2017-304-introducing_talla_an_erlang_implementation_of_tor

--Roger

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

Re: [tor-relays] Testing Golang relay implementation

2017-10-25 Thread nusenu 


Michael McLoughlin:
> Is the bug in my descriptor or the parser?

First of all it was a problem for the parser and they hotfixed it.
(I did not verify if your descriptor follows the specification, if it
does you should be fine.)


>>> https://trac.torproject.org/projects/tor/ticket/23981


-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Testing Golang relay implementation

2017-10-25 Thread Michael McLoughlin 
Is the bug in my descriptor or the parser?

In testing it took a little bit of finagling to get chutney to accept a
non-Tor "platform" item in the descriptor. Turned out adding a "proto" line
as well is enough. But it did occur to me that other code may assume the
"platform" line takes a certain form.

I can easily change the descriptor if necessary? I've included it below for
reference:

---

router pearl000 35.203.138.1 9001 0 0
signing-key
-BEGIN RSA PUBLIC KEY-
MIGJAoGBAKzTaN4tZGv1kiQWBzeuOk+ovr2LtIURlaVC38j6j/fQuYfuAZX/XvV1
fQr9EVh+T617dh+frt2D0QDuzLUvP3hpgVozW94w+Ib85pUCne03f4rj3QYu5Qtg
GvzShslZI6vgyy0g2jAOGa4jxT/UYAcKE5dQo8CBKA6Qb0P5Joc1AgMBAAE=
-END RSA PUBLIC KEY-
fingerprint 6832 5B4B 1E17 7374 B84D 372F 0304 6351 BEE7 FF6A
onion-key
-BEGIN RSA PUBLIC KEY-
MIGJAoGBANN/gLTe05kWKPSEyYJeknuxQst+cVsVmZrZgIYNXuhPn+3XnWhEc10r
ICa82FkB7hBH6REuW0ugGDc2QLwENmDiaBiFW1LDujEFeVlV8o0VSDwrL3VCPsPL
zC4/zHqR4DmLFXp5V238MKj85Pud04g65piZCIAsy6hiGMDCoGdtAgMBAAE=
-END RSA PUBLIC KEY-
ntor-onion-key ATSN2Q9KwCeRu35agh/ChjX8MsgM/FGFRDUX6o9Sbmk
platform Pearl 0fd5756 on Linux
contact pe...@m15n.org https://github.com/mmcloughlin/pearl
bandwidth 153600 307200 153600
published 2017-10-25 18:00:28
reject *:*
proto Link=4 LinkAuth=1 Relay=2
router-signature
-BEGIN SIGNATURE-
OyY0vQc5n2RYdkrXqfn09HoACJBx7GrBHZMnmNtlX5nJIL9N4eyyPvmxhmuC+A94
dDE0u/6w3nCABikFFLHcKaBAdmYBdxrzk3imfVjzYZazHWWr/se8HxK1jibP186A
8K8bdtMih127CGv3mn+g17uXFTbbuylM7r1xf8NpqRs=
-END SIGNATURE-



On Wed, Oct 25, 2017 at 12:34 PM, D.S. Ljungmark  wrote:

> So it's already finding bugs in other implementations?
>
> That's pretty awesome! ;-)
>
> //Spider
>
> On 25/10/17 21:16, nusenu wrote:
> > https://trac.torproject.org/projects/tor/ticket/23981#comment:9
> > wrote:
> >
> >> Looks like this issue is caused by a server descriptor produced by an
> >>  alternate Tor implementation that identifies itself as `"platform Pearl
> >>  0fd5756 on Linux"`. And that implementation uses a different order of
> >>  elements in its descriptor.
> >
> > :)
> >
> >
> >
> > ___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Testing Golang relay implementation

2017-10-25 Thread D.S. Ljungmark 
So it's already finding bugs in other implementations?

That's pretty awesome! ;-)

//Spider

On 25/10/17 21:16, nusenu wrote:
> https://trac.torproject.org/projects/tor/ticket/23981#comment:9
> wrote:
> 
>> Looks like this issue is caused by a server descriptor produced by an
>>  alternate Tor implementation that identifies itself as `"platform Pearl
>>  0fd5756 on Linux"`. And that implementation uses a different order of
>>  elements in its descriptor.
> 
> :)
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Testing Golang relay implementation

2017-10-25 Thread nusenu 
https://trac.torproject.org/projects/tor/ticket/23981#comment:9
wrote:

> Looks like this issue is caused by a server descriptor produced by an
>  alternate Tor implementation that identifies itself as `"platform Pearl
>  0fd5756 on Linux"`. And that implementation uses a different order of
>  elements in its descriptor.

:)

-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays