Delivery-Date: Tue, 28 Oct 2014 13:40:09 -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.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID
	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 khazad-dum.seul.org (Postfix) with ESMTPS id 68BD31E08C6;
	Tue, 28 Oct 2014 13:40:08 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 9AAC831046;
	Tue, 28 Oct 2014 17:40:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 747C02F6D4
 for <tor-talk@lists.torproject.org>; Tue, 28 Oct 2014 17:40:00 +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 W_A6m_VbgMLb for <tor-talk@lists.torproject.org>;
 Tue, 28 Oct 2014 17:40:00 +0000 (UTC)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com
 [IPv6:2607:f8b0:400c:c03::22e])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 4BFB42E923
 for <tor-talk@lists.torproject.org>; Tue, 28 Oct 2014 17:40:00 +0000 (UTC)
Received: by mail-vc0-f174.google.com with SMTP id hq12so644946vcb.19
 for <tor-talk@lists.torproject.org>; Tue, 28 Oct 2014 10:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=6or9N8rmjylBCzoZGzpLrot4SeBL1sk/5If1HKpSZvI=;
 b=F96ixoqkY+DkK8WfwMX26gaNj2zVlvhHeH+cIoiH4/TWDQlWzynIIfaLWVoEQjgle/
 nwd0gYTec0EgYzF1rzvnQljB9tM7c5+/WjSPZorCxLT11Eij9UNjBs49WRypNfky/AHu
 hv9l7Ea+hbzbkxSvq203eltBI3smC4PMck6U7Cq/hX4bViRkH/5qgln47Cqti4J08L8u
 UeS9ggKB5WimWc08T8sPA9Qhlztw23o2uFCe4QK8aythg4U1py0bd28nYZbmb/2g5XjL
 ry7xCi0NzmTuS3mD9469pp4m4ZkJqj+XrK3bkT2R8+tQZQBvkrLcMpADKpPyueOcrtqi
 NNow==
MIME-Version: 1.0
X-Received: by 10.221.46.135 with SMTP id uo7mr1042190vcb.42.1414517997678;
 Tue, 28 Oct 2014 10:39:57 -0700 (PDT)
Received: by 10.221.64.74 with HTTP; Tue, 28 Oct 2014 10:39:57 -0700 (PDT)
In-Reply-To: <1414504557.117485.184221605.751E6CD6@webmail.messagingengine.com>
References: <1414128957.1286791.182745789.27EF00B3@webmail.messagingengine.com>
 <CAD2Ti2_DYRJZ-+sg1Zgwp0cuU6g_q-aZF+z9ets0=_kv6am-1Q@mail.gmail.com>
 <CAD2Ti2-Tc9wabaqBcp93Q--8ey+1UUxH0OALHmjRLMGjqbgyCA@mail.gmail.com>
 <512753.55494435393836332d31343036383939313433@popretr.messagingengine.com>
 <1414504557.117485.184221605.751E6CD6@webmail.messagingengine.com>
Date: Tue, 28 Oct 2014 13:39:57 -0400
Message-ID: <CAD2Ti2-eKarfrQwTCJJScs1S=wqU6c=aX-Q2_mbb81sS3kxzpg@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: tor-talk@lists.torproject.org
Cc: ambrop7@gmail.com
Subject: Re: [tor-talk] using UDPGW and tun2socks over Tor
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On Tue, Oct 28, 2014 at 9:55 AM, Nathan Freitas <nathan@freitas.net> wrote:
>>> This means we can support SIP calling over Tor, video conference and
>>> streaming, among other applications...
>
>> Tor as a client also needs support for inbound binds for some apps, at
>> least at the single per port level when interacting with internet at the
>> far
>> end. OpenVPN might, or could be extended to arbitrate those port
>> binding requests.
>> Hidden services do support such binds in hs-to-hs mode, at least
>> statically.

You can't *receive* 'calls' without inbound binding capabilities, or using
internet call servers in the middle as meetme proxies. Out of the box,
tor is crippled in that inbound regard when interacting with the internet.
If you refuse to give third party servers [meta]data, then you're stuck
with unidirectional calling. OpenVPN could do inbound TCP/UDP binds
at the exits, tun2socks TCP can't, don't know if udpgw UDP can.

> Thanks for the feedback. We aren't using OpenVPN itself really, just
> standard SOCKS for TCP, and then UDP tunneled inside of that SOCKS
> connection using this udpgw-client/daemon system.
>
> The VPN code that is part of the solution is more of a local loopback
> capability for Android that allows us to intercept that packets.

> Perhaps udpgw instances can be run along
> side all Tor exit nodes?

Tor transports only TCP. You outline running udpgw clients locally
and udpgw daemons on the exits such that badvpn can tunnel UDP
through udpgw client through badvpn over tor to the far udpgw daemon
then out to the internet.
In the linked mail thread I suggested running OpenVPN on the exits
(instead of udpgw daemon), that will give the user general access to
not just TCP and UDP but to all protocols from 0-255, most notably
ICMP and others typically used by network/system admins. As bonus
you also get optional inbound binds which badvpn-udpgw cannot do either.
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

The badvpn-udpgw TUN model presented to the VM is the same. Though
instead of handing all TCP to the local tor client via SOCKS5 and then
UDP to a udpgw exit over a TCP tunnel therein... all traffic gets tunnelled
with OpenVPN TCP connection over tor to OpenVPN on an exit.
Also, it seems badvpn-udpgw would leave each user TCP streams up
to tor client to route at will, but route UDP over tunnel to a fixed udpgw
exit and configuring the two to use the same exit would be complex.
Whereas OpenVPN tunnels everything to a fixed exit over a single
circuit. ('Fixed' could just as easily be random or rotated by the
configuring user as in the linked mail thread.) Unlike badvpn-udpgw,
OpenVPN also works on all relavent client and server platforms.

Hope that's a more comparison of badvpn-tun2socks/udpgw
to OpenVPN models for VM and general use.
-- 
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

