>>> 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.
>>>
>>
>> Yes DATA_V2 adds 3 bytes compared to DATA_V1.
> I understand the 3 bytes (--peerid and such) but is there any way to NOT
> have such a low server-side MTU?
> Also note that having a different server-side MTU versus client-side MTU
> makes it even harder to tune the performance


Basically no. The Data V1 vs Data V2 discussion is basically done and V2
is here to stay. If 3 bytes really are too much (and we have a very
strong use case to save those bytes), having optionally reduce the auth
tag in AES-GCM/CachaPoly to something like 128 bit (16 bytes) or 160 bit
instead the current 256 bit (32 bytes) makes probably more sense. E.g.
Wireguard only uses 16 bytes auth tag and IPSec allows 16/12/8 bytes
according to RFC4106.

I don't think there is any real different client vs server mtu here
apart from potential bugs in the MTU code but not any fundamental

> thanks for all the clarifications - esp the cipher-negotiation.rst was
> very helpful.
> And I understand the argument about "polluting the discussion" but to me
> the *order* in which things are done is important. That is, for the 2.6
> release all MTU issues should be resolved , so that noone will ever have
> a need to debug MTU issues by dis- or enabling NCP.
> So I guess if things were done in the order
>   1) fix the MTU issues on both client and server side
>   2) drop --ncp-disable
> then you would not have heard any complaints from me.

That is an easy thing to say if you don't do the development.

But no, it doesn't work this way this time. I am simply not abanding my
30-40 outstanding patches now (that include also DCO), stop working on
them when they are nearly finished, spend all my time on MTU and then
later come back to the NCP/DCO/TLS session refactoring.

And I also don't want to invest time fixing MTU issues related to
disabled MTU if I remove that feature later. That is just wasted time.

And as Antonio said, we are committed to fixing these issues. We do not
plan to release a 2.6 version with broken MTU.

Arne



_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to