[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Another Virtual Network Environment needs your I/O

On Fri, 2015-10-16 at 15:31 +0000, Yawning Angel wrote:
> Cute.  The networking part works in a near-identical manner Orbot's
> Android VPN mode, under the hood, except they opted to use a 3rd party
> implementation (that bundles lwIP IIRC).


> Why did you write your own IP/ICMP/TCP (partial) implementations
> instead of using something like lwip? 

When I was researching my idea I came across lwIP and was planning to
use it. Unfortunately I could not find documentation. It's not on the
project homepage and the wikia pages were not helpful too. What I needed
was the info provided by the lwIP paper by Adam Dunkel. Found this paper
yesterday trough the wikipedia article about lwIP.

I always try to understand a technology that I use, even if I use an
implementation by someone else. So I studied the TCP protocol. From this
I got the idea that a full TCP protocol implementation was not needed to
correctly handle *my* tun traffic. Writing a simplified TCP protocol
would give me some major advantages: perfect integration with my design
and no extra external dependencies.

> As your blog post notes "There are still some loose ends", most of
> these should be known issues (From quickly skimming the code, there is

Fair enough, the loose ends are:

- The proxy uses two connections, an upstream connection and a TCP
connection. If one of the two connections closes, the other connection
is closed immediately. There is however a (very?) small change that
there is still data in a buffer that must be written to the open
connection. The open connection should close after this data is written.

- Needs more testing. I have tested the program in a loose way. For
hours and hours I have watched YouTube videos, visited nasty websites
(lots of advertisements, scripts and simultaneous connections), and
downloaded very large files using WGET. Everything seems to work, but
*seems* is not enough it most be *proven* to work correctly. 

- No unit tests.  

> a possibility I've missed things or I'm wrong):
>  * No IPv6.
>  * No congestion control (TCP Tahoe is fairly trivial to implement,
>    and would be more than sufficient).

Congestion control is used to prevent dropped segments. This can not
happen on the User Space <-> kernel connection of a tun interface. The
TCP-window flow control prevents this. 

> > The second question I have is: are there  programs / protocols which
> > should be blocked by avne? For example: I think its a bad idea to
> > support unencrypted POP3.
> I think users should be allowed to shoot themselves in the foot if they
> want to.

"Want to" implies that the user is aware of the danger. Most users have
no idea about the dangers of using a particular protocol over Tor. I
want to protect these users.

> Should be easily portable to the U*IXes, Windows will give you pain,
> but I'm not sure you care.

I care, and I think it can be ported to Windows. Since there are no
kernel namespaces, another way to force all traffic through the tun
interface must be found. It can be done by using the Windows firewall
like this:



tor-dev mailing list