[tor-talk] using UDPGW and tun2socks over Tor

[Nathan Freitas]

Is there any reason we shouldn't consider supporting UDP over Tor with
Orbot, by tunneling the packets using the combination of badvpn's
tun2socks and udpgw ("udp gateway") feature? This has come up as we are
implementing the Android VPNService, and discovered how easy to
implement and well performing the badvpn UDP tunneling capability is.

It does mean that someone would have to operate the
gateway/infrastructure portion of udpgw at a capacity necessary to
handle all udp streaming traffic sent for all Orbot users, but I would
consider that to be feasible. Perhaps udpgw instances can be run along
side all Tor exit nodes?

This means we can support SIP calling over Tor, video conference and
streaming, among other applications.

https://code.google.com/p/badvpn/
https://code.google.com/p/badvpn/wiki/tun2socks
https://github.com/ambrop72/badvpn

+n

[grarpamp]

Post by Nathan Freitas
Is there any reason we shouldn't consider supporting UDP over Tor with
Orbot, by tunneling the packets using the combination of badvpn's
tun2socks and udpgw ("udp gateway") feature?

There's no reason raw IP itself (any/none of its numbered protocols)
shouldn't / couldn't be transported over Tor using OpnVPN (at least
until Tor itself is extended as such).

Post by Nathan Freitas
This has come up as we are
implementing the Android VPNService, and discovered how easy to
implement and well performing the badvpn UDP tunneling capability is.
This means we can support SIP calling over Tor, video conference and
streaming, among other applications...
https://code.google.com/p/badvpn/
https://code.google.com/p/badvpn/wiki/tun2socks
https://github.com/ambrop72/badvpn

... Not necessarily, unless you're statically mapping all the people
(IP's) you want to communicate with beforehand, (which you can't with
random unknown participants ie: Bittorrent, or people on dynamic or
mobile), you're currently constrained by address collisions:
- Trying to pack the entire IPv4 address space you might want to
'call' into your tiny 10.0.0.0/24 adapter space. Same for put entire IPv6
space into your private IPv6/48 adapter space.
- Similarly what you're going to do when Tor moves to wider than
80bit onion addressing which currently fits nicely into a private IPv6/48.
(Need a secure IPv6<->onion address mapping layer pushed into a
DHT/blockchain or just resorting to trusting some volunteer run in-net
lookup service.)

edit: Just noticed badvpn's mention of pushing a *VM* on a 10 address
through socks with this, at least for TCP, which is simpler. As opposed
to pushing any app on the raw iron through a *VPN* which could be
constrained as above. Left this anyway for thought in related things.

Post by Nathan Freitas
It does mean that someone would have to operate the
gateway/infrastructure portion of udpgw at a capacity necessary to
handle all udp streaming traffic sent for all Orbot users, but I would
consider that to be feasible. Perhaps udpgw instances can be run along
side all Tor exit nodes?

Read below thread flowing on both tor-talk and tor-relays, flows over
May and June, with better specification/answers in later posts.
https://lists.torproject.org/pipermail/tor-relays/2014-May/004516.html
Subject: Ops request: Deploy OpenVPN terminators

[grarpamp]

Post by Nathan Freitas
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.

[Nathan Freitas]

Post by grarpamp

Post by Nathan Freitas
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.

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.

[grarpamp]

Post by Nathan Freitas

Post by grarpamp

Post by Nathan Freitas
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.

Post by Nathan Freitas
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.