Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

[James Y. <ji...@yo...>]

Aaron Sethman <and...@ra...> said:

> 
> 
> On Wed, 23 Apr 2003, Matthias Andree wrote:
> 
> > On Wed, 23 Apr 2003, James Yonan wrote:
> >
> > > I wonder if one could build a better tcp-over-tcp by doing some intelligent
> > > packet filtering on the higher level tcp connection, such as filtering out
> > > retransmits and fudging return ACKs -- essentially removing those
elements of
> > > the TCP protocol which are designed to make TCP work over an unreliable
link.
> >
> > I wonder if that's necessary. Tunnelling through TCP is inherently
> > reliable no matter what you send, so TCP-nested-in-TCP is just overkill.
> > Cheating the OS doesn't help. Maybe some LD_PRELOAD library that turns
> > stream sockets into dgram sockets for connections that use the tunnel is
> > sufficient. However, this doesn't actually apply to openvpn because
> > openvpn does TCP-over-UDP.
> 
> I think you've got it backwards.  I think James is talking about the layer
> that openvpn is tunnelling over.  Basically fiddling with it to keep that
> layer from doing a lot of the reliabilitiy stuff.  To be honest I'm not
> sure its possible without using raw sockets and constructing your own TCP
> packets.  Even then though, I don't think that would work for some
> people's needs like being able to shove it through an SSL proxy or
> something like that.

Actually, I was thinking more about the situation where people are forced to
tunnel IP over TCP, for whatever reason, when UDP is not an option.  Since IP
is designed to transit over an unreliable physical layer, when you tunnel it
over TCP (a la vpnd or IP over ssh) you end up with this problem:

http://sites.inka.de/sites/bigred/devel/tcp-tcp.html (see Stacking TCPs)

The key issue here is that when you tunnel IP over TCP, that will usually mean
TCP over TCP.  And this tends to break TCP's retransmission algorithm.  As the
article above states: "The upper layer will queue up more retransmissions
faster than the lower layer can process them".

So my idea is why not filter out the upper layer TCP retransmissions, and
synthesize the return ACKs so that the upper TCP layer doesn't begin the
exponential backing off of the retransmit timer that eventually will stall the
connection?  This process would essentially strip the upper layer TCP of its
reliability function, since now the lower TCP layer will provide that
function.  This is not difficult to implement, since to OpenVPN, the upper
layer protocols are all simply byte streams flowing over the TUN pipe.  They
can be filtered without resorting to raw sockets or any other such potentially
unportable constructs.

Using raw sockets would be another potential method -- instead of removing the
reliability function from the upper layer TCP layer, remove it from the lower
layer.  This would require a sort of fake-TCP implementation in user-space
with the reliability function stripped out.  On first glance, this seems to be
a more complicated approach because you would need to implement a lot of the
TCP protocol in user space, and you would need to depend on the OS supporting
raw sockets.  The approach outlined in the previous paragraph doesn't need raw
sockets, and it doesn't need to reimplement TCP.  It only needs to examine the
byte stream of IP packets flowing over the TUN device, filter out TCP
retransmits, and synthesize return TCP ACKs.

Each method tries to stabilize TCP-over-TCP by eliminating a redundant
reliability layer.  Both of these methods, while somewhat ugly, would
eliminate a big part of the robustness issue of IP over TCP, for those who
lack IP over UDP as an option.

James