Hi,
On 08/04/21 17:52, Gert Doering wrote:
Hi,
On Thu, Apr 08, 2021 at 05:30:52PM +0200, Jan Just Keijser wrote:
I don't have any evidence with 2.5 right now but this is just a matter
of use/principle to me: I can very well see that I would like to have a
setup *without* NCP as I simply do not need it (e.g. my cipher is
hardwired to aes-256-gcm) and in that case I don't *want* NCP to ensure
my setup is 100% predictable.
By setting "--data-ciphers AES-256-GCM" on the client side, you achieve
a 100% predictable outcome. No other cipher will be offered or accepted.
Ah a new 2.5 option - I assume the same thing is true for adding this on
the server side?
And I see that --data-ciphers works only in combination with NCP, that
is, if you do
--data-ciphers aes-256-gcm --ncp-disable
then --data-ciphers is effectively ignored. Nice ;)
Disabling this option means you give me less control over the setup and
I don't like that, thus Feature-NAK.
Removing that option means "less confusing code variants that can lead
to 'it works with NCP but not with NCP disabled'".
Since I test all these variants, and find the confusing corner cases, it
would be good to have less code paths throughout OpenVPN, especially
in the server option negotiation and key setup phases.
I'd say that removing the ability to disable NCP can happen *only* when
all negative side-effects of enabling it have been mitigated fully. On
a slow link the NCP overhead can be quite disastrous and not just during
connection setup, but during the *whole* session. To me, yet another
reason for Feature-NAK
The overhead of NCP is roughly "some 100 bytes sent extra from client to
server in the TLS handshake phase" (to announce the acceptable ciphers)
and "cipher xxx" in the PUSH_REPLY.
There is no overhead in the data phase.
Please explain how this can be "quite disastrous"?
(Of course, if NCP negotiates a cipher with more overhead than you'd
like to use, that would be "more overhead" - but this is fully under
the client's control with --data-ciphers. It even works with "none",
provided both client and server permit this)
I was thinking about this email discussion we had in October 2018:
On 29/10/18 18:08, Gert Doering wrote:
On Mon, Oct 29, 2018 at 05:40:04PM +0100, Jan Just Keijser wrote:
So, the '32' is easily explained. However, the rest of the MTU
calculation baffles me.
Part of this is "peer-id" (+3 bytes) and "the theoretical maximum
crypto + hmac overhead" which 2.3 calculates "for the cipher chosen"
and 2.4 needs to calculale for the worst-case cipher+auth, since it does
not know what the server will push.
In other words, you do not want to know - and the whole "match
configured client/server tun-mtu/link-mtu OCC thingie" is a real
nuisance.
so I now understand the client MTU:
openvpn 2.3.18 -> mtu = 1431
openvpn 2.4.6 -> mtu = 1428 which accounts for peer-id (+3)
but the *server* mtu?!?!?! I would have expected that with
--ncp-disable added I would end up with more or less the same MTU as
with the 2.3 code. Instead I see
openvpn 2.3.18 -> mtu = 1431
openvpn 2.4.6 -> mtu = 1379
which is 62 bytes LESS , so even with peer-id subtracted (does it
apply to the server MTU?) I end up with 59 bytes unaccounted for *in
tun mode*.
and I was hoping that this would be resolved before removing something
like --ncp-disable. Having said that, I now see that with openvpn 2.5,
the server mtu is still 1379 in my setup, regardless of whether I use
--ncp-disable or not - seems to me that is still too low.
On the client side I now see even more confusing fun:
Server has --ncp-disable set:
- with --cipher aes-256-cbc the client side MTU is 1428
- with --cipher aes-256-gcm the client side MTU is 1376 <--- huh?
Server does not have --ncp-disable set:
- with --cipher aes-256-cbc the client side MTU is 1428
- with --cipher aes-256-gcm the client side MTU is 1448
(ok I understand the latter).
What I'd really like to see is a way to get the server-side MTU to also
be 1428/1448 using the right magic options - any idea if that's possible?
The lower the MTU on either side, the lower the maximum bandwidth -
which will hurt especially over low-bandwidth links.
Also, when this option is dropped, does that mean that a 2.4/2.5 client
with the option set can no longer connect to a 2.6 server?
Conclusion: a further overhaul of the ncp/cipher/data-ciphers logic
might be in order...
Which is one of my gut reasons for saying : don't remove --ncp-disable
until this mess is thoroughly sorted out.
JM2CW,
JJK
=============
Client config:
client
proto udp
remote $SERVER
port 1194
dev tun
nobind
remote-cert-tls server
ca ca.crt
cert client1.crt
key client1.key
cipher aes-256-cbc
auth sha256
link-mtu 1500
fragment 0
mssfix 0
=============
Server config:
proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
dh dh2048.pem
ca ca.crt
cert server.crt
key server.key
persist-key
persist-tun
keepalive 10 60
topology subnet
cipher aes-256-cbc
auth sha256
link-mtu 1500
fragment 0
mssfix 0
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
