Re: [tor-relays] About relay size

[teor]

> On 4 Oct 2017, at 01:38, grarpamp  wrote:
> 
> ... Exits would have
> to tag their support of "exit v4 and/or v6 to clearnet"
> in consensus so circuits get built to a place that
> can actually ship the client's cells out to clearnet.
> Relays WAN function already offer inbound connection
> capabilities by their listed OR IP format in consensus,
> but not yet any outbound IP version, which client must
> also know from consensus and compute to reach next input.

The ExitPolicy ad IPv6Exit options on Exits are put into the relay's
descriptor, which gets turned into the microdescriptor, which clients
use to select exits.

And most clients just send a DNS name and a set of IP version flags.

For the rare cases where literal addresses are used, or there are
IPv6-only websites over DNS, tor could be smarter.

We accept patches, but it's not a high priority, because it works for
almost all hostnames / addresses that clients actually use.

> Building WAN paths is different from what is carried within.
> So that, it seems possible, if in consensus, to make WAN path like...
> v6 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v6 ==> v6 clearnet
> v4 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v4 ==> v4 clearnet

This abstraction layer exists in tor and it works fine.

> On 4 Oct 2017, at 00:49, Scott Bennett  wrote:
> 
> teor  wrote:
> 
>> 
>>> On 3 Oct 2017, at 08:52, Scott Bennett  wrote:
>>> 
>>> teor  wrote:
>>> 
 
 On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
 
>>> In the meantime, I think it would be great to have IPv6-only relays, to
>>> avoid this kind of NAT-related issues.
>> 
>> We'd love to make this happen, but the anonymity implications
>> of mixed IPv4-only and IPv6-only (non-clique) networks need
>> further research. Search the list archives for details.
>> 
>   Couldn't that be taken care of in the tor client code?  For example, a
> client, having chosen a path through which an IPv6-only relay, could 
> extend
> the path by one hop to tunnel through a node with both types of interface
> published?
 
 Yes, clients choose paths, and could choose them using these kinds of
 restrictions. But current tor relay versions won't extend to other relays
 over IPv6. Because we don't understand the anonymity implications of
 restricting the next relay in the path based on the previous relay. Which
 is why we need further research.
>>> 
>>>Here's a procedure:  if the next hop/destination does not use a protocol
>>> in common with the client/current hop, a dual-protocoled node must be
>>> interposed; else use the originally selected hop/destination directly.
>> 
>> But is this procedure safe?
> 
> Why might it not be safe?

Because it may make clients distinguishable from each other. Client
indistinguishability is a key part of tor's anonymity design. I encourage you to
read the original Tor paper.

>> And is it an efficient use of resources to add extra hops?
> 
> Well, the additional hops ought to increase the safety.  Wouldn't that
> have to be considered in an efficiency calculation?
> 
>> (That is, is there a more efficient 3-hop algorithm that's just as safe?)
>> We need research to answer these questions.
> 
> It seems to me that a) using a small number (i.e., 3) of hops reduces
> safety and b) a constant number of hops also reduces safety.  Added hops to
> make an unpredictable path length ought to counter the alleged safety issues
> in choosing hops from a smaller pool.

No, because added hops make clients distinguishable via latency, and as far as
we can tell, they don't increase safety. There's a paper on this, too.

> Also, unless the pool of dual-protocol
> hops is much smaller than the number of relays available, say, ten years ago,
> I don't see a reason to worry.  (We were thrilled to have 900 - 1300 up at
> any one time.)

Tor provides better anonymity guarantees than it used to ten years ago.
So it's today's anonymity we need to measure against, not 2007's.

>>> The client-to-first-hop situation is analogous to using a set of entry 
>>> guards
>>> today, so that much should be okay.  What do IPv6-only clients currently do?
>> 
>> Choose a relay with an IPv6 ORPort.
>> (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
>> 
>> IPv6-only clients need to be manually configured using "ClientUseIPv4 0",
>> because this feature is still experimental. We think it will be safer when 
>> all
>> dual-stack clients use some IPv6 guards.
>> 
> Dual-protocol clients connecting to dual-protocol entry nodes ought to
> choose randomly which protocol to use.  Similarly, a dual-protocol relay
> extending to another dual-protocol relay ought to choose randomly which
> protocol to use for the connection.  Both clients and relays would have the
> option of retrying 

Re: [tor-relays] About relay size

[grarpamp]

Little thought yet but related, figured if client host is dual stack,
could separate "client over WAN via IPv to reach relay"
function from traffic routed into tor's cells for carriage to pop
out other side, like a VPN for IP versions. Exits would have
to tag their support of "exit v4 and/or v6 to clearnet"
in consensus so circuits get built to a place that
can actually ship the client's cells out to clearnet.
Relays WAN function already offer inbound connection
capabilities by their listed OR IP format in consensus,
but not yet any outbound IP version, which client must
also know from consensus and compute to reach next input.
Building WAN paths is different from what is carried within.
So that, it seems possible, if in consensus, to make WAN path like...
v6 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v6 ==> v6 clearnet
v4 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v4 ==> v4 clearnet
Not quite sure why yet, or if theory correct.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Feedback wanted: letter to my university's library

[Scott Bennett]

Alison Macrina  wrote:

> Scott Bennet> If he discovers that neither his campus library nor the
> university as a
> > whole is already officially running at least one relay, this may be a better
> > way to teach them.  If, rather than going for a relay, which is quite likely
> > to scare them until they understand more and better about tor, AJ were
> > instead to campaign to get the library to install the tor browser bundle
> > onto its publicly available computers, that alone would be a terrific
> > coup and might engender a great deal of student support for tor on campus
> > over time.  (The library would, of course, need to find a way to lock down
> > the settings of the installed bundle, so that it couldn't be turned into
> > a relay by users, but that should not be difficult to do.)  If he succeeded
> > in getting the tor browser bundle added to the library's most likely tightly
> > limited list of applications available on its public machines, he could then
> > wait a while to see what the staff members thought of it.  If they decided
> > after watching it in use for a while that it was a good thing to have made
> > available to their users, you might then approach another department that
> > operates a student computer lab to try to get TBB installed there.  If the
> > library employees liked it, they might give the prospective department a
> > positive recommendation.  If AJ played it right and it usually turned out
> > well, he might eventually cover much of the campus with TBB installations.
> > In any case, getting the TBB installed would educate far more people about
> > anonymity and privacy issues than merely getting a relay installed that most
> > people would never be aware of.
>
> This is a great idea, and the slides I shared in my last email could
> help get this conversation started (the slides cover Tor Browser as well
> as relays and other Tor stuff). If AJ is interested I can connect him
> with other libraries I've worked with that have installed Tor Browser on
> all of their public computers.
>
 I, for one, am very happy to know that Alison and her organization are
making those materials available.  They have the potential to assist many
people like AJ in making the public more aware of the issues and of the tools
available to help it protect/recover its privacy and anonymity.
 Alison, do you also have materials on using HTTPS where available
instead of HTTP?  The dangers inherent in allowing Java or JavaScript to be
enabled in one's web browser?  Cookies?  Tools like the HTTPSeverywhere and
NoScript plug-ins for Firefox?  The reasons for avoiding the use of telnet
clients and which tools to use instead for remote logins?  If not, they would
make great additions, particularly pages that explain how to convince
librarians about these matters?
 Let me give an example.  I have for at least ten years asked my local
public library to provide a) a secure shell client, b) a secure web browser
for ordinary use where anonymity is not a concern, c) a secure FTP client,
and d) the TBB for use by those who desire anonymity.  They have always
refused to budge.  They run an unsecurable OS on their public computers.  They
provide only Internet Explorer for web access.  I'm unsure whether they still
allow any FTP access at all.  As you can imagine, they have severely limited
the usefulness of their computers to the library patrons they claim to serve.
I could not, for example, submit my on-line application to renew my flight
instructor certificate via the library's computers.
 They have refused to let me speak with those making the decisions about
what is provided on their public computers, much less to make an organized
presentation to them.  I was told that the decisions about software on the
computers are made by the library board, not even by the IT staff.  What is
a good approach to get better results?  I am at a loss as to how to get the
library to emerge from the stone age into the age of the Cheka, much less
that of the NSA, FSB, search engine profilers, botnets, packet sniffers,
spyware, etc.
 Disclaimer:  I confess that I have no idea how prevalent my public
library's attitudes and policies are among public libraries in the U.S. today,
so I can't make any claims about widespread need for the sort of materials
I'm asking about.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *

Re: [tor-relays] About relay size

[Scott Bennett]

teor  wrote:

>
> > On 3 Oct 2017, at 08:52, Scott Bennett  wrote:
> > 
> > teor  wrote:
> > 
> >> 
> >> On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
> >> 
> > In the meantime, I think it would be great to have IPv6-only relays, to
> > avoid this kind of NAT-related issues.
>  
>  We'd love to make this happen, but the anonymity implications
>  of mixed IPv4-only and IPv6-only (non-clique) networks need
>  further research. Search the list archives for details.
>  
> >>>Couldn't that be taken care of in the tor client code?  For example, a
> >>> client, having chosen a path through which an IPv6-only relay, could 
> >>> extend
> >>> the path by one hop to tunnel through a node with both types of interface
> >>> published?
> >> 
> >> Yes, clients choose paths, and could choose them using these kinds of
> >> restrictions. But current tor relay versions won't extend to other relays
> >> over IPv6. Because we don't understand the anonymity implications of
> >> restricting the next relay in the path based on the previous relay. Which
> >> is why we need further research.
> > 
> > Here's a procedure:  if the next hop/destination does not use a protocol
> > in common with the client/current hop, a dual-protocoled node must be
> > interposed; else use the originally selected hop/destination directly.
>
> But is this procedure safe?

 Why might it not be safe?

> And is it an efficient use of resources to add extra hops?

 Well, the additional hops ought to increase the safety.  Wouldn't that
have to be considered in an efficiency calculation?

> (That is, is there a more efficient 3-hop algorithm that's just as safe?)
> We need research to answer these questions.

 It seems to me that a) using a small number (i.e., 3) of hops reduces
safety and b) a constant number of hops also reduces safety.  Added hops to
make an unpredictable path length ought to counter the alleged safety issues
in choosing hops from a smaller pool.  Also, unless the pool of dual-protocol
hops is much smaller than the number of relays available, say, ten years ago,
I don't see a reason to worry.  (We were thrilled to have 900 - 1300 up at
any one time.)
>
> > The client-to-first-hop situation is analogous to using a set of entry 
> > guards
> > today, so that much should be okay.  What do IPv6-only clients currently do?
>
> Choose a relay with an IPv6 ORPort.
> (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
>
> IPv6-only clients need to be manually configured using "ClientUseIPv4 0",
> because this feature is still experimental. We think it will be safer when all
> dual-stack clients use some IPv6 guards.
>
 Dual-protocol clients connecting to dual-protocol entry nodes ought to
choose randomly which protocol to use.  Similarly, a dual-protocol relay
extending to another dual-protocol relay ought to choose randomly which
protocol to use for the connection.  Both clients and relays would have the
option of retrying the attempt via the other protocol in the event a failed
attempt to connect.  This ought to have been implemented already, but can
still be done soon.

> > Allowing IPv6 destinations today limits exit-hop selections to dual-
> > protocol-capable exit nodes
>
> No, IPv4-only exits are still useful and used, because tor clients typically
> send DNS names to exits. IPv6 DNS records typically have IPv4 as well,
> so any exit will work. (There's a ticket for better handling of DNS that
> only resolves to IPv6.)
>
> And in the rare case of address literals, the client can choose a capable
> exit. (I think there's a ticket for this, too.)

 Okay, but those circuits are incidental to the circuit that a user wants,
which is limited to dual-protocol-capable nodes.
>
> > which is like using an "ExitNodesIPv6" (if there
> > were such a thing) line in torrc with a long and growing list of nodes.
>
> There are flags on SOCKSPort for IP versions, including PreferIPv6, which
> is the default.
>
> > How
> > long would that list have to be for the warning on the man page under the
> > ExitNodes statement definition to become unimportant?  How many were there
> > when IPv6 destinations were first allowed?
>
> The situation isn't analogous.
>
> For safety, IPv6 exit destinations were turned off by default until we had 
> enough
> IPv6 exits. Now they are on by default.

 I repeat:  how many were there when IPv6 destinations were first allowed?
How many when the default was changed?
>
> But we haven't done the same thing for relays, because we don't know how to
> design the feature so it's safe.

 As soon as there are as many IPv6-capable relays as there were IPv4
relays ten years ago, there will no longer be any reason not to enable their
use.  How close are we to reaching that number now?  Or have we already
passed it?
>
> > For interposing dual-protocoled nodes along the way, how many 

Re: [tor-relays] SSH Bruteforce Attempts

[teor]

> On 3 Oct 2017, at 22:35, tanous .c  wrote:
> 
> Have any of you had this sort of problem? I'm having difficulty determining 
> if this log information represents a normal exit relay ocurrence or if my 
> server has been compromised... What could i do in order to solve this?

Yes, Profihost sent me one recently that looked very similar.
Fortunately, I use OutboundBindAddress, so I knew it was
(very likely to be) exit traffic.

You can:
* do nothing
* respond and ask for verification that they want your exit
   to block their site, but explain that they need to block
   all Tor Exits for the traffic to stop
* add exit policy entries to block each of the mentioned
   IPs and ports
* block port 22 on your exit

I'll be doing nothing.

You should consider your provider's reaction, because they
may want you do something about the complaint, even if
it's something ineffective.

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

[tor-relays] SSH Bruteforce Attempts

[tanous .c]

Hi,
I have been running one  tor exit relay for about 51 days and i recently
got this abuse
report:



Good afternoon,

Your Ip address (212.47.239.73) has been reported to us by profihost
because it seems to have attempted to bruteforce.
Thank you to take the necessary action as soon as possible.
You will find more information about this report below this message.
Feel free to contact Online.net technical assistance for more information.
Online.net Abuse service
 --

(time is MET / GMT+1):
Tue Oct 3 08:59:40 2017: user: root service: ssh target: 77.75.252.250
source: 212.47.239.73 Tue Oct 3 08:59:10 2017: user: root service: ssh
target: 77.75.252.250 source: 212.47.239.73 Tue Oct 3 08:59:10 2017: user:
root service: ssh target: 77.75.252.250 source: 212.47.239.73 Tue Oct 3
08:36:18 2017: user: admin service: ssh target: 37.228.155.188 source:
212.47.239.73 Tue Oct 3 07:06:42 2017: user: user service: ssh target:
77.75.252.80 source: 212.47.239.73 Tue Oct 3 07:06:12 2017: user: user1
service: ssh target: 77.75.252.80 source: 212.47.239.73 Tue Oct 3 06:14:12
2017: user: admin service: ssh target: 77.75.251.85 source: 212.47.239.73
Tue Oct 3 06:01:41 2017: user: admin service: ssh target: 77.75.252.78
source: 212.47.239.73 Tue Oct 3 05:37:01 2017: user: admin service: ssh
target: 185.39.221.52 source: 212.47.239.73 Tue Oct 3 02:07:46 2017: user:
admin service: ssh target: 77.75.249.19 source: 212.47.239.73 Tue Oct 3
01:23:57 2017: user: admin service: ssh target: 85.158.176.137 source:
212.47.239.73 Mon Oct 2 20:10:45 2017: user: admin service: ssh target:
77.75.255.76 source: 212.47.239.73 Mon Oct 2 17:30:13 2017: user: admin
service: ssh target: 185.39.221.145 source: 212.47.239.73 Mon Oct 2
17:30:13 2017: user: admin service: ssh target: 185.39.221.145 source:
212.47.239.73 Mon Oct 2 17:09:32 2017: user: admin service: ssh target:
37.228.154.149 source: 212.47.239.73 Mon Oct 2 17:09:23 2017: user: admin
service: ssh target: 37.228.154.102 source: 212.47.239.73 Mon Oct 2
16:43:12 2017: user: admin service: ssh target: 77.75.252.233 source:
212.47.239.73 Mon Oct 2 16:23:41 2017: user: admin service: ssh target:
37.228.155.125 source: 212.47.239.73 Mon Oct 2 14:17:24 2017: user: admin
service: ssh target: 77.75.250.84 source: 212.47.239.73 Mon Oct 2 13:24:14
2017: user: supervisor service: ssh target: 37.228.159.139 source:
212.47.239.73 Mon Oct 2 13:24:14 2017: user: support service: ssh target:
37.228.159.139 source: 212.47.239.73 Mon Oct 2 13:23:44 2017: user: super
service: ssh target: 37.228.159.139 source: 212.47.239.73 Mon Oct 2
12:48:09 2017: user: user service: ssh target: 37.228.159.98 source:
212.47.239.73 Mon Oct 2 12:47:39 2017: user: user service: ssh target:
37.228.159.98 source: 212.47.239.73
 -- This data has been truncated because it was too long
--





Have any of you had this sort of problem? I'm having difficulty determining
if this log information represents a normal exit relay ocurrence or if my
server has been compromised... What could i do in order to solve this?

Thank you all,

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

Re: [tor-relays] About relay size

[Scott Bennett]

Roman Mamedov  wrote:

> On Tue, 3 Oct 2017 09:53:46 -0400
> teor  wrote:
>
> > > For interposing dual-protocoled nodes along the way, how many do there
> > > have to be for it to become "not too limiting"?
> > 
> > This is one of the questions we need researchers to answer.
>
> I can't help but feel you are overcomplicating this.
>
> Clients create a circuit by randomly picking 3 nodes out of the all-nodes
> pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over
> IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are
> IPv4-only, the whole selection can be thrown away and repeated.
>
> That way IPv6-only relays could get some usage on a totally random basis, with
> no compromises and no restraining "of the next hop based on the previous one",
> not hurting anonymity. Clients just need to know which nodes are IPv4-only,
> IPv6-only or dual-stack, to not attempt unworkable combinations, discarding
> them instead.

 Looks good to me, Roman.  I like it better than what I suggested, though
adding some variability to path length had some appeal, too.  Your way is
certainly simpler.
 If tor ever starts to support TCP over UDP and/or TCP over SCTP, that
will be a similar situation for a while, where some relays can do both and
others are limited to one protocol or the other.
>
> And as there are more and more dual-stack or IPv6-only relays, the "throw
> away" step will be needed less and less often.
>
 Yet the same process could be applied to the TCP-over-non-TCP situation
quite easily, too.  I think I like your way even better now.
 My memory is a bit hazy on this, but I seem to recall watching a video
file of Roger Dingledine giving a talk somewhere about tor long ago in which
he commented happily that the tor network had grown to where it usually had
at least 300 nodes up and running at all times of day.  If 300 were enough
for path selection before, aren't they still enough?  Aren't there at least
300 IPv6-only nodes and at least 300 dual-protocol nodes now?  And, of
course, there must have been a time when the network was smaller than 300...


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

> On 3 Oct 2017, at 10:57, Roman Mamedov  wrote:
> 
> On Tue, 3 Oct 2017 09:53:46 -0400
> teor  wrote:
> 
>>>For interposing dual-protocoled nodes along the way, how many do there
>>> have to be for it to become "not too limiting"?
>> 
>> This is one of the questions we need researchers to answer.
> 
> I can't help but feel you are overcomplicating this.
> 
> Clients create a circuit by randomly picking 3 nodes out of the all-nodes
> pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over
> IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are
> IPv4-only, the whole selection can be thrown away and repeated.
> 
> That way IPv6-only relays could get some usage on a totally random basis, with
> no compromises and no restraining "of the next hop based on the previous one",
> not hurting anonymity. Clients just need to know which nodes are IPv4-only,
> IPv6-only or dual-stack, to not attempt unworkable combinations, discarding
> them instead.

Discarding unworkable combinations and restraining node choices seem
equivalent to me, although the relay weights may be different.

> And as there are more and more dual-stack or IPv6-only relays, the "throw
> away" step will be needed less and less often.

If you think this will work and is safe for client anonymity, then the next step
is to write a tor proposal. Having a concrete design could help with
analysing the anonymity implications as well.

I think IPv6-only relays are a lower priority than better IPv6 and dual-stack
client support, and IPv6-only bridge support  But we could do both in the
same release.

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

Re: [tor-relays] Feedback wanted: letter to my university's library

[Alison Macrina]

Scott Bennet> If he discovers that neither his campus library nor the
university as a
> whole is already officially running at least one relay, this may be a better
> way to teach them.  If, rather than going for a relay, which is quite likely
> to scare them until they understand more and better about tor, AJ were
> instead to campaign to get the library to install the tor browser bundle
> onto its publicly available computers, that alone would be a terrific
> coup and might engender a great deal of student support for tor on campus
> over time.  (The library would, of course, need to find a way to lock down
> the settings of the installed bundle, so that it couldn't be turned into
> a relay by users, but that should not be difficult to do.)  If he succeeded
> in getting the tor browser bundle added to the library's most likely tightly
> limited list of applications available on its public machines, he could then
> wait a while to see what the staff members thought of it.  If they decided
> after watching it in use for a while that it was a good thing to have made
> available to their users, you might then approach another department that
> operates a student computer lab to try to get TBB installed there.  If the
> library employees liked it, they might give the prospective department a
> positive recommendation.  If AJ played it right and it usually turned out
> well, he might eventually cover much of the campus with TBB installations.
> In any case, getting the TBB installed would educate far more people about
> anonymity and privacy issues than merely getting a relay installed that most
> people would never be aware of.

This is a great idea, and the slides I shared in my last email could
help get this conversation started (the slides cover Tor Browser as well
as relays and other Tor stuff). If AJ is interested I can connect him
with other libraries I've worked with that have installed Tor Browser on
all of their public computers.

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

Re: [tor-relays] About relay size

[Roman Mamedov]

On Tue, 3 Oct 2017 09:53:46 -0400
teor  wrote:

> > For interposing dual-protocoled nodes along the way, how many do there
> > have to be for it to become "not too limiting"?
> 
> This is one of the questions we need researchers to answer.

I can't help but feel you are overcomplicating this.

Clients create a circuit by randomly picking 3 nodes out of the all-nodes
pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over
IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are
IPv4-only, the whole selection can be thrown away and repeated.

That way IPv6-only relays could get some usage on a totally random basis, with
no compromises and no restraining "of the next hop based on the previous one",
not hurting anonymity. Clients just need to know which nodes are IPv4-only,
IPv6-only or dual-stack, to not attempt unworkable combinations, discarding
them instead.

And as there are more and more dual-stack or IPv6-only relays, the "throw
away" step will be needed less and less often.

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

Re: [tor-relays] About relay size

[Scott Bennett]

teor  wrote:

>
>  A related question is can a relay with only an IPv4 address
>  published currently set an IPv6 OutboundBindAddress?
> >>> 
> >>> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
> >>> 
> >> That's okay, but what if the node is an entry-and-middle node only?
> >> 
> > Hmm.  On second thought, it's *not* okay because it means that such a
> > node cannot be a middle node because it could only connect to the IPv6
> > universe.  Or the man page is wrong about OutboundBindAddress.  Or there
> > is something else amiss.
>
> "This option may be used twice, once with an IPv4 address and once with
> an IPv6 address"
>
 I see the problem.  I'm running 0.3.1.6-rc at present, 0.3.2.1-alpha
has been installed since I last started tor, and the timestamp on the man
page says "Oct 2 2012". :-(  Now I have to track down why the man page
updates have not been getting installed.  Sigh.  Sorry for that bit of noise.
 The other questions remain, however, including the one above.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

> On 3 Oct 2017, at 08:52, Scott Bennett  wrote:
> 
> teor  wrote:
> 
>> 
>> On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
>> 
> In the meantime, I think it would be great to have IPv6-only relays, to
> avoid this kind of NAT-related issues.
 
 We'd love to make this happen, but the anonymity implications
 of mixed IPv4-only and IPv6-only (non-clique) networks need
 further research. Search the list archives for details.
 
>>>Couldn't that be taken care of in the tor client code?  For example, a
>>> client, having chosen a path through which an IPv6-only relay, could extend
>>> the path by one hop to tunnel through a node with both types of interface
>>> published?
>> 
>> Yes, clients choose paths, and could choose them using these kinds of
>> restrictions. But current tor relay versions won't extend to other relays
>> over IPv6. Because we don't understand the anonymity implications of
>> restricting the next relay in the path based on the previous relay. Which
>> is why we need further research.
> 
> Here's a procedure:  if the next hop/destination does not use a protocol
> in common with the client/current hop, a dual-protocoled node must be
> interposed; else use the originally selected hop/destination directly.

But is this procedure safe?
And is it an efficient use of resources to add extra hops?
(That is, is there a more efficient 3-hop algorithm that's just as safe?)
We need research to answer these questions.

> The client-to-first-hop situation is analogous to using a set of entry guards
> today, so that much should be okay.  What do IPv6-only clients currently do?

Choose a relay with an IPv6 ORPort.
(Or configure a bridge with an IPv6 ORPort or pluggable transport.)

IPv6-only clients need to be manually configured using "ClientUseIPv4 0",
because this feature is still experimental. We think it will be safer when all
dual-stack clients use some IPv6 guards.

> Allowing IPv6 destinations today limits exit-hop selections to dual-
> protocol-capable exit nodes

No, IPv4-only exits are still useful and used, because tor clients typically
send DNS names to exits. IPv6 DNS records typically have IPv4 as well,
so any exit will work. (There's a ticket for better handling of DNS that
only resolves to IPv6.)

And in the rare case of address literals, the client can choose a capable
exit. (I think there's a ticket for this, too.)

> which is like using an "ExitNodesIPv6" (if there
> were such a thing) line in torrc with a long and growing list of nodes.

There are flags on SOCKSPort for IP versions, including PreferIPv6, which
is the default.

> How
> long would that list have to be for the warning on the man page under the
> ExitNodes statement definition to become unimportant?  How many were there
> when IPv6 destinations were first allowed?

The situation isn't analogous.

For safety, IPv6 exit destinations were turned off by default until we had 
enough
IPv6 exits. Now they are on by default.

But we haven't done the same thing for relays, because we don't know how to
design the feature so it's safe.

> For interposing dual-protocoled nodes along the way, how many do there
> have to be for it to become "not too limiting"?

This is one of the questions we need researchers to answer.

>>> A related question is can a relay with only an IPv4 address
>>> published currently set an IPv6 OutboundBindAddress?
>> 
>> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
>> 
> That's okay, but what if the node is an entry-and-middle node only?

Relays don't extend to IPv6, so you can set the option, but it won't do
anything, because there are no outbound IPv6 connections.

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

Re: [tor-relays] About relay size

[teor]

 A related question is can a relay with only an IPv4 address
 published currently set an IPv6 OutboundBindAddress?
>>> 
>>> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
>>> 
>> That's okay, but what if the node is an entry-and-middle node only?
>> 
> Hmm.  On second thought, it's *not* okay because it means that such a
> node cannot be a middle node because it could only connect to the IPv6
> universe.  Or the man page is wrong about OutboundBindAddress.  Or there
> is something else amiss.

"This option may be used twice, once with an IPv4 address and once with
an IPv6 address"

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

Re: [tor-relays] About relay size

[Scott Bennett]

Scott Bennett  wrote:

> teor  wrote:
>
> >
> > On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
> >
> > >>> In the meantime, I think it would be great to have IPv6-only relays, to
> > >>> avoid this kind of NAT-related issues.
> > >> 
> > >> We'd love to make this happen, but the anonymity implications
> > >> of mixed IPv4-only and IPv6-only (non-clique) networks need
> > >> further research. Search the list archives for details.
> > >> 
> > > Couldn't that be taken care of in the tor client code?  For example, a
> > > client, having chosen a path through which an IPv6-only relay, could 
> > > extend
> > > the path by one hop to tunnel through a node with both types of interface
> > > published?
> >
> > Yes, clients choose paths, and could choose them using these kinds of
> > restrictions. But current tor relay versions won't extend to other relays
> > over IPv6. Because we don't understand the anonymity implications of
> > restricting the next relay in the path based on the previous relay. Which
> > is why we need further research.
>
>  Here's a procedure:  if the next hop/destination does not use a protocol
> in common with the client/current hop, a dual-protocoled node must be
> interposed; else use the originally selected hop/destination directly.  
> The client-to-first-hop situation is analogous to using a set of entry guards
> today, so that much should be okay.  What do IPv6-only clients currently do?
>  Allowing IPv6 destinations today limits exit-hop selections to dual-
> protocol-capable exit nodes, which is like using an "ExitNodesIPv6" (if there
> were such a thing) line in torrc with a long and growing list of nodes.  How
> long would that list have to be for the warning on the man page under the
> ExitNodes statement definition to become unimportant?  How many were there
> when IPv6 destinations were first allowed?
>  For interposing dual-protocoled nodes along the way, how many do there
> have to be for it to become "not too limiting"?
> >
> > > A related question is can a relay with only an IPv4 address
> > > published currently set an IPv6 OutboundBindAddress?
> >
> > Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
> >
>  That's okay, but what if the node is an entry-and-middle node only?
>
 Hmm.  On second thought, it's *not* okay because it means that such a
node cannot be a middle node because it could only connect to the IPv6
universe.  Or the man page is wrong about OutboundBindAddress.  Or there
is something else amiss.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Scott Bennett]

teor  wrote:

>
> On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
>
> >>> In the meantime, I think it would be great to have IPv6-only relays, to
> >>> avoid this kind of NAT-related issues.
> >> 
> >> We'd love to make this happen, but the anonymity implications
> >> of mixed IPv4-only and IPv6-only (non-clique) networks need
> >> further research. Search the list archives for details.
> >> 
> > Couldn't that be taken care of in the tor client code?  For example, a
> > client, having chosen a path through which an IPv6-only relay, could extend
> > the path by one hop to tunnel through a node with both types of interface
> > published?
>
> Yes, clients choose paths, and could choose them using these kinds of
> restrictions. But current tor relay versions won't extend to other relays
> over IPv6. Because we don't understand the anonymity implications of
> restricting the next relay in the path based on the previous relay. Which
> is why we need further research.

 Here's a procedure:  if the next hop/destination does not use a protocol
in common with the client/current hop, a dual-protocoled node must be
interposed; else use the originally selected hop/destination directly.  
The client-to-first-hop situation is analogous to using a set of entry guards
today, so that much should be okay.  What do IPv6-only clients currently do?
 Allowing IPv6 destinations today limits exit-hop selections to dual-
protocol-capable exit nodes, which is like using an "ExitNodesIPv6" (if there
were such a thing) line in torrc with a long and growing list of nodes.  How
long would that list have to be for the warning on the man page under the
ExitNodes statement definition to become unimportant?  How many were there
when IPv6 destinations were first allowed?
 For interposing dual-protocoled nodes along the way, how many do there
have to be for it to become "not too limiting"?
>
> > A related question is can a relay with only an IPv4 address
> > published currently set an IPv6 OutboundBindAddress?
>
> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
>
 That's okay, but what if the node is an entry-and-middle node only?


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Feedback wanted: letter to my university's library

[Scott Bennett]

Alison Macrina  wrote:

> Hi AJ,
>
> Thank you for supporting Tor! I think it's a great idea to try to work
> with your university library to run a relay. I run the Library Freedom
> Project which helps libraries understand and use privacy tools
> (libraryfreedomproject.org). I can give you some advice based on my
> experience.
>
> William Denton:
> > On 1 October 2017, AJ Jordan wrote:
> >
> >> However I've just started college at the University of Rochester,
> >> which obviously presents a great opportunity to set up a relay on a
> >> really great network. I'm planning to reach out to the library with
> >> the following email and would love some feedback:
> >
> > Scott Bennett had excellent advice,
>
> +1
>
> > Academic libraries can be very experimental in some of their work, but
> > they are generally risk-averse.  (This is good, because they're in the
> > business of preserving knowledge and cultural artifacts for decades and
> > centuries.)  There is, I'm afraid, close to zero chance they would let a
> > non-employee student run a server on their network---and running Tor,
> > even a non-exit relay, makes the chances even lower.
> >
> > However, don't give up.  I suggest thinking about this as a long-term
> > project that could get you involved with the library, faculty and campus
> > IT.  There must be people on campus interested in privacy issues, who
> > know about Tor, and perhaps who have been thinking about running a
> > relay.  These people could be librarians or they could be professors or
> > grad students in political science, communcations, journalism, computer
> > science, privacy studies, etc.  Find out who they are and approach
> > them!  Perhaps there is a student club interested in the same
> > issues---if not, you could start one.  Students and student groups
> > advocating for a Tor relay or exit, while demonstrating the importance
> > of Tor and how it fits in with the library's and university's mission,
> > would very much help the project be successful.
>
> William's advice is good. You definitely need to begin by building a
> relationship with the library. Don't be discouraged by the amount of
> work this may take; the payoff might end up being a cultural shift
> wherein the library, university IT, and CS departments all work on this
> as a project together!
>
> You'll want to approach the library by showing that Tor is an excellent
> way to uphold the values of librarianship, which are privacy,
> intellectual freedom, and access. Really, be explicit about it; don't
> assume that they'll just get why you think it matters. Here's something
> I wrote about intellectual freedom + Tor Browser a while ago and you can
> borrow the arguments I've made:
> https://www.scribd.com/document/272919852/Alison-Macrina-The-Tor-Browser-and-Intellectual-Freedom-in-the-Digital-Age
>
> As William said, libraries are mostly risk-averse, so you also need to
> be ready to answer their questions about legal and technical concerns.
> LFP has collected some resources to help with all of that here:
> https://github.com/LibraryFreedom/tor-exit-package/blob/master/resources.md.
>
> Before you email the university librarian, I'd start by talking to some
> of the regular academic librarians about your ideas and gauge their
> responses. Ask them if they've heard of the Library Freedom Project and
> feel free to send them any of our resources. See if they think the
> administration would be receptive to you offering a presentation about
> Tor to library staff (even better if you can make it open to students
> and faculty, too, because that can get you more support). You are
> welcome to adapt these slides for that presentation:
> https://libraryfreedomproject.org/allabouttor/. Make sure to show them
> this academic library that has used their Tor relay as a teaching tool
> for students:
> https://boingboing.net/2016/03/16/first-ever-tor-node-in-a-canad.html.
>
 I second all of the above by both Bill and Allison, and I am grateful
that they were able to express better and in far greater detail much of
what I was trying to say, while adding their own ideas in similar detail.
 Reading Bill's and Allison's followups stimulated an idea of another,
and possibly better, approach that I hope AJ will consider and that may
even be more likely to be approved and have greater effect in the long run.
If he discovers that neither his campus library nor the university as a
whole is already officially running at least one relay, this may be a better
way to teach them.  If, rather than going for a relay, which is quite likely
to scare them until they understand more and better about tor, AJ were
instead to campaign to get the library to install the tor browser bundle
onto its publicly available computers, that alone would be a terrific
coup and might engender a great deal of student support for tor on campus
over time.  (The library would, of course, need to find a way to lock down
the settings 

Re: [tor-relays] About relay size

[teor]

On 3 Oct 2017, at 03:07, Scott Bennett  wrote:

>>> In the meantime, I think it would be great to have IPv6-only relays, to
>>> avoid this kind of NAT-related issues.
>> 
>> We'd love to make this happen, but the anonymity implications
>> of mixed IPv4-only and IPv6-only (non-clique) networks need
>> further research. Search the list archives for details.
>> 
> Couldn't that be taken care of in the tor client code?  For example, a
> client, having chosen a path through which an IPv6-only relay, could extend
> the path by one hop to tunnel through a node with both types of interface
> published?

Yes, clients choose paths, and could choose them using these kinds of
restrictions. But current tor relay versions won't extend to other relays
over IPv6. Because we don't understand the anonymity implications of
restricting the next relay in the path based on the previous relay. Which
is why we need further research.

> A related question is can a relay with only an IPv4 address
> published currently set an IPv6 OutboundBindAddress?

Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.

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

Re: [tor-relays] About relay size

[Scott Bennett]

grarpamp  wrote:

> >> Or instead of router mode, try bridge mode feeding into any old pc running
>
> Noting that even some crappy hardware will still fall over when put in its
> so called "bridge" mode, which should just be some packet buffering
> between the wires and their encodings, but it's obviously still looking
> at the traffic above layer2. So you may still need to swap out hardware.
>
 Absolutely.  Another reason to avoid electronics store routers for tor
(or many other things) is the information in recently exposed documents that
the CIA started invading those devices and, where possible, "upgrading" their
firmware as standard practice at least a decade ago.

> >  because there is secondary storage (HDD and/or SSD), paging
> > is available if the routing functions' memory needs grow larger than the
>
> Sure, but there's no free substitute for RAM, and you probably don't want
> packets burning a hole in your SSD. Add more RAM if not maxed out.

 My point was intended to be only that having a regular computer handle
the routing means it doesn't have to die if available RAM be exhausted, i.e.,
not an argument for speed, but rather for survival under unusual loads.
Now that I'm more awake than when I wrote that, though, I realize I don't
recall whether routing and NAT tables and mbufs are page-fixed or pageable
anyway. :-(  It's still better to have a router that you own and the CIA
[probably] doesn't.

> disable swap, boot USB, set read-only, use small ramdisks for write paths.
> If used RAM for a used PC isn't in budget or isn't enough, then maybe
> spindle, but it won't be as fast. And eventually CPU or interrupts or i/o
> get swamped. Then you put a newer PC that can hold proper amounts
> of RAM, CPU, etc.

 Very true.  The device need also not be dedicated to just those functions.
Many people would prefer to stick a heavily used relay on their border gateway
machine to keep its traffic load off their LANs anyway.
 Also, if FreeBSD is used, kernel memory for routing tables, NAT tables
if used, and mbufs should be allocated from 4 MB superpages, allowing the
routing to run very fast.  And with an electronics store router, you don't
have the kernel configuration information available to look at, whereas you
do have that and all the rest as well if you install the OS yourself.  Let's
also not omit the ability to apply security fixes as they become available,
where the store-bought boxes would be running obsolete and unsafe OS in their
firmware, probably by the time the store sold them.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays