On 24/02/2021 23:05, tincanteksup wrote:
On 24/02/2021 21:28, tincanteksup wrote:
On 24/02/2021 20:05, Marc SCHAEFER wrote:
On Wed, Feb 24, 2021 at 07:27:09PM +0000, tincanteksup wrote:
I wonder if IPv6 has any new features which can customise the
initial Syn
packet in any way ?
Not to my knowledge. Why would you want to do that?
Just a passing thought .. I think I just sort of re-invented
syn-cookies without realising it ;-)
I was thinking that IPv6 might have something like that actually
defined by RFC and built in to a syn packet. I mean, why not ?
In fact, this idea seems to TCP Fast Open
(https://tools.ietf.org/html/rfc7413)
Similar to but not the same as TFO.
In my idea, the initial client SYN would have an encrypted cookie if it
came from OpenVPN client. The server could simply drop all SYN *with
Zero ACK* which does not have this encrypted cookie, to be verified by
OpenVPN not IP stack. So data passed directly to the application for
review and no response from IP until the application allows it.
But after reading the RFC I realise this is way outside the scope of TFO
as it is currently being designed.
So, as I understand TFO the main goal is to shave off some round-trips
by sending a data payload together with the SYN packet from the client.
In OpenVPN context that would not need to be much different from how we
handle UDP packets today. This is essentially the difference between
UDP (stateless) and TCP (stateful).
With UDP, OpenVPN looks at the UDP packet arriving, does the
TLS-auth/crypt validation and drops the packet if it fails. If the
validation is good, the content is being decrypted and handled
accordingly. Since UDP is stateless, it does not reveal to the sender
if a packet was dropped or not - thus the port will seem to be
unavailable by port scans.
With normal TCP, first the SYN - SYN ACK - ACK dance happens and *then*
the first data packet is passed on from the kernel to OpenVPN where can
look at and do the TLS-auth/crypt validation. But since TCP is
stateful, it has already signalled to the sender that "I have a service
available on this port" - and this is before OpenVPN kicks in.
Now with TFO in play, from a very simplistic view, the client would need
to send data together with the ACK. At this point OpenVPN would get the
data and can do the TLS-auth/crypt validation and close the connection
if it fails. In this case, it would be a mixture of UDP and TCP for
OpenVPN. Yes, OpenVPN can shut the connection down quicker. But it
will still signal to the client that "yes, I have a service available on
this port".
But I'm really not sure if there is a big gain in OpenVPN of doing that.
It makes the initial TCP handshake faster, yes. But that happens in
the beginning of a VPN session and on reconnections where the previous
connection was lost/closed. Once the TCP handshake has passed, you
don't notice this at all - it's all the same connection.
TFO has a bigger advantage in short-lived TCP sessions (like web
browsers) where you open several independent TCP connections to fetch
data in parallel and then close them down. Here TFO will have an edge.
Now you might argue about the crypto part in the TFO SYN cookies, but
that is entirely handled by the kernel and TCP stack - nothing OpenVPN
(or any other application) will need to or can care about.
This Linux Weekly News article has a nice walk-through of TFO at an
earlier development stage:
<https://lwn.net/Articles/508865/>
--
kind regards,
David Sommerseth
OpenVPN Inc
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
