On 16/05/2021 19:14, Arne Schwabe wrote:
First of all, I do like Steffan's proposal:
> Remove the option, and:
> * if auth != none -> replay prevention is always enabled;
> * if auth == none -> replay prevention is disabled.
And with "remove the option", if it exists in a config, it should be
considered a NOOP.
Then on compatibility ...
Given 2, how clear is our timeline on sunsetting non-AEAD ciphers? That
would automatically sunset --no-replay. (I've lost track a bit...)
Heated debate as that is equal to drop compatibility completely with
OpenVPN 2.3. We have already a heated debate if dropping 2.3 config
compatibility is possible or not (e.g. you need to add ciphers to
data-ciphers to still to connect to a 2.3 peer).
Just to be clear, since I have been involved in several of these
discussions. I consider 2.3 dead. I care about 2.4 and upwards, based
on the agreement we had long time ago about which versions we want to
support [0]. 2.3 is now in git-only support and we have only promised
that support level until end of June (essentially ~6 more weeks).
[0] <https://community.openvpn.net/openvpn/wiki/SupportedVersions>
For me, I care only about 2.4 and newer at this point. If someone
desperately need to support 2.3 clients, it is not our task to provide
such support. If someone need a 2.6 client to connect to a 2.3 server,
that is also not our task to provide. If 2.3 is so badly needed, you
cannot expect to blend in 2.6 without issues.
We cannot be held hostage due to our users incapability to upgrade, even
when related to hardware. Our current support time is quite reasonable,
where we go from full -> old stable -> git-only -> unsupported which
takes about 2.5 year. If a site cares about their VPN setup, that is
more than long enough time to plan and deploy an upgrade. *And* it is
the distributor itself who must carry the main support burden if they
decide to support versions not supported by the upstream project. So
for LTS distributions, it is the LTS distribution providing the packages
which defines when their LTS distribution goes EOL - and they support
the packages they provide in that LTS distribution.
That said, we can strive to support older versions, but we should not
spend lots of time and energy supporting it just for the sake of
supporting it.
What I do care about is that _client_ configuration files targetted for
_2.4_ clients can connect to 2.4 and newer servers without modifying the
configuration files. But I am at the same time willing to accept that
DCO will change that game. Also, if a site has deployed a server
configuration for 2.5 or 2.6 explicitly and have accordingly scoped
their client configuration for the same version, supporting older
clients should _not_ be expected to work. But for existing 2.4 servers,
we should not break configurations on 2.4 or newer clients. So
basically, 2.4/2.5/2.6 should be able to work out-of-the-box without any
changes, regardless of versions.
However, if connecting to a *DCO enabled host*, updating client
configurations *is* acceptable *because* that is a completely new
technology which is not targetting everything 2.4 supports by design
*and* _not_ making use of DCO will still work.
For sites wanting to support both DCO and non-DCO, we could consider
looking into ensuring that connection-blocks can be used where the
server side will have an openvpn server running with DCO and another one
without DCO. This means adding DCO on an already existing server could
be done using a different port or IP address (--local). Unless we want
ovpn-dco to be able to be a simple and passive forwarder of both control
and data channel packets if the configuration is not DCO compliant.
The challenge is that cipher/auth settings cannot be in a connection
block, which means the current behaviour in 2.4 need to be preserved,
unless we can push settings (NCP and related). It is also acceptable to
me that clients may ignore local cipher/auth settings which can be
pushed from the server.
But I also do know NCP is a bit tricky with the current DCO
implementation, where this needs to be settled on a DCO supported cipher
before connecting. Maybe we should consider a similar approach to
OpenVPN 3, where the tun/DCO interface is setup *after* the connection
to the server has been established with the PUSH_REPLY received and pass
UDP/TCP socket to ovpn-dco at that point *if* the server side
cipher/auth/compression is compliant with DCO? (Otherwise, use a tun
interface)
--
kind regards,
David Sommerseth
OpenVPN Inc
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
