interface mtu calculation in 2.4 significantly different from 2.3

[Gert Döring]

debian bug report:

​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867113

with --link-mtu 1400, 2.3 sets ip ... mtu 1344 while 2.4 sets ip ... mtu 1278 (which is too small for IPv6).

I can see a few bytes being lost to account for worst-case crypto overhead before negotiation, but 80 extra bytes? This needs a closer look...

[Antonio Quartulli]

733 size_t
734 crypto_max_overhead(void)
735 {
736 return packet_id_size(true) + OPENVPN_MAX_IV_LENGTH
737 +OPENVPN_MAX_CIPHER_BLOCK_SIZE
738 +max_int(OPENVPN_MAX_HMAC_SIZE, OPENVPN_AEAD_TAG_LENGTH);
739 }

this is huge and was introduced with 2.4 (I guess due to ncp).

packet_id_size(true): 8
OPENVPN_MAX_IV_LENGTH: 16
OPENVPN_MAX_CIPHER_BLOCK_SIZE: 32:
OPENVPN_MAX_HMAC_SIZE: 64
OPENVPN_AEAD_TAG_LENGTH: 16

TOT: 120Bytes.

This function then affects the extra_frame member of the frame object that is used to defer the tun_mtu from the link_mtu.

This is a really pessimistic approach as it uses all the MAX values.

First of all: --auth is not negotiable (right?), so can't we use the size of the signature produced by the configured algorithm?

Second: could we use the maximum values of the configured ciphers (--cipher + --ncp-ciphers) ?

[Steffan Karger]

Yeah, those bounds can be tighter. Though the difference between 2.3 and 2.4 is not 80, but 66 bytes.

I've looked into this while implementing NCP, but even though it sounds simple I found it tricky to implement in the current codebase. I'll see if I can come up with a (somewhat clean) way to fix this.

But if someone else wants to have a go at it, please do!

[Steffan Karger]

The attached two commits introduce a more accurate worst case crypto overhead calculation, but introduce quite a bit of (tricky) code to do so. I'm not sure it's worth it...