Delivery-Date: Sat, 07 Jun 2014 15:42:27 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by moria.seul.org (Postfix) with ESMTPS id 469C01E0A64
	for <archiver@seul.org>; Sat,  7 Jun 2014 15:42:25 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5A3532F96F;
	Sat,  7 Jun 2014 19:42:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 7F14E2F801
 for <tor-talk@lists.torproject.org>; Sat,  7 Jun 2014 19:32:09 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 60quj_eX956Z for <tor-talk@lists.torproject.org>;
 Sat,  7 Jun 2014 19:32:09 +0000 (UTC)
Received: from mari.romanrm.net (mari.romanrm.net
 [IPv6:2400:8500:1301:801:157:7:203:202])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 161FD2F367
 for <tor-talk@lists.torproject.org>; Sat,  7 Jun 2014 19:32:09 +0000 (UTC)
Received: from natsu (unknown [IPv6:fd39::a60:6eff:fef3:b5b3])
 by mari.romanrm.net (Postfix) with ESMTPS id AC2A22161B;
 Sat,  7 Jun 2014 19:32:01 +0000 (UTC)
Date: Sun, 8 Jun 2014 01:31:57 +0600
From: Roman Mamedov <rm@romanrm.net>
To: tor-talk@lists.torproject.org
Message-ID: <20140608013157.5a139bb7@natsu>
In-Reply-To: <CAD2Ti29NYWC+FUvbTGxTXEGVSjW5k1HP2NezjF4NfbOZWKVe+Q@mail.gmail.com>
References: <20140607151420.6cde8acd@natsu>
 <CAD2Ti29NYWC+FUvbTGxTXEGVSjW5k1HP2NezjF4NfbOZWKVe+Q@mail.gmail.com>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Subject: Re: [tor-talk] Problematic ORPorts
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0700038666481696871=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

--===============0700038666481696871==
Content-Type: multipart/signed; micalg=PGP-SHA1;
 boundary="Sig_/+fGWQ.W9b3X8RklELkn.U+4"; protocol="application/pgp-signature"

--Sig_/+fGWQ.W9b3X8RklELkn.U+4
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 7 Jun 2014 14:02:43 -0400
grarpamp <grarpamp@gmail.com> wrote:

> > So my idea is, maybe consider making directory authorities blacklist so=
me
> > ports as being unacceptable as ORPorts, 22 and 53 come to mind for a st=
art,
> > along with maybe 25 to avoid false alarms from anti-spam countermeasure=
s.
>=20
> ORport config exists to give better anti blocking/censorship
> performance. So Tor should not exclude any OR port/protocol.
> The problem is with you and your ISP, not other relays who
> have fine working relationships with their ISP regarding binding
> to those ports.

First of all, if an end-user is affected by censorship, they are likely to =
use
Tor Bridges anyway, so the need of plain relays on standard ports does not
seem to be of much significance.

Second, to the contrary of what you describe regarding ISP relationships, it
could very well be that running a relay on a port like 22 or 53 is caused by
the opposite, i.e. by their ISP not being fully informed of what the relay
operator is doing on their machine, and as a result with the said operator
only being able to request opening/forwarding of a few innocent-looking por=
ts
from their network administrator (e.g. at an university or school). Sure th=
ey
are doing this out of their best intentions to contribute bandwidth to Tor,
but if such 'contribution' ends up knocking five other much faster relays f=
rom
being able to act as relays anymore, how positive is it really.

> A relay operator who feels they are at risk of making such
> contact should probably work with their host or find another
> one instead of narrowing their possible outbound paths. (The
> impact to tor network of RelayNoORPorts would depend on
> percent nodes having your noisy ORport and traffic weights.
> May also affect clients reaching specific exit relay using said
> ports. And add more overhead signaling. Better to find new host.)

One issue is often the very fact that having a lot of such connections can =
be
problematic might only be discovered post-factum*, i.e. after the user alre=
ady
has been forcefully "parted" with their VPS or dedi (prepaid for a some
significant period too). Trying to explain about Tor in this case can easily
result in some less-than-qualified or overly cautious ISPs banning all Tor =
on
their network altogether ("oh so it was Tor that caused these SSH or DNS
attacks? OK, from now on adding a 'no Tor' rule into the ToS").

* Sure you might argue that any relay operator needs to be upfront about
running a relay with their ISP, but really, the easiest and the most workab=
le
solution when running a non-exit relay is (or at least was, before these
port 22 and port 53 relays) to stay "below the radar".

Another issue is that the pool of hosts providing cheap or reasonably priced
unmetered VPSes or dedicated servers is far from being infinite, that you
could so easily just abandon one and move over to the next one.

--=20
With respect,
Roman

--Sig_/+fGWQ.W9b3X8RklELkn.U+4
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlOTaK0ACgkQTLKSvz+PZwjdPgCfZIGze8aU+4IAG0zm27zJdFJ0
ZlwAn1ZEITG1QEbiSqG4fVlKZvvd/qzM
=JuAR
-----END PGP SIGNATURE-----

--Sig_/+fGWQ.W9b3X8RklELkn.U+4--

--===============0700038666481696871==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

--===============0700038666481696871==--

