Re: MTU estimation…

[Daniel Lenski]

On Tue, Aug 15, 2017 at 11:03 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Tue, 2017-08-15 at 10:42 -0700, Daniel Lenski wrote:
>> David,
>> You're certainly right with this, uh, skeptical comment on the
>> ESP_OVERHEAD estimation in gpst.c …
>>
>>     /* XXX: Look at set_esp_algo() and tell me again what the biggest
>> supported IV is? */
>>     #define ESP_OVERHEAD (4 /* SPI */ + 4 /* sequence number */ + \
>>              20 /* biggest supported MAC (SHA1) */ + 16 /* biggest
>> supported IV (AES-128) */ + \
>>             1 /* pad length */ + 1 /* next header */ + \
>>
>> I copied it from a similar calculation from openconnect-internal.h:
>> http://git.infradead.org/users/dwmw2/openconnect.git/blob/1f079924c1684da5958747e24a0e91a3ea12d702:/openconnect-internal.h#l336
>>
>>     #define DTLS_OVERHEAD (1 /* packet + header */ + 13 /* DTLS header */ + \
>>              20 /* biggest supported MAC (SHA1) */ +  16 /* biggest
>> supported IV (AES-128) */ + \
>>              16 /* max padding */)
>>
>> I believe that *both* of these should be updated to:
>>
>>     32 /* biggest support IV (AES-256) */
>>
>> In practice, I have never seen or heard of a GP VPN that uses anything
>> other than aes128+sha1, but both the clients and servers appear to
>> include support for aes256 (and md5… woof).
>
> Christ, our MTU code is a mess, isn't it? And I still haven't resolved
> the problem with servers sending "too-large" packets, either.

The lyin' oversized packet issue is fixed for Juniper (where it's
found in the wild) with the receive_mtu patch from Nikolay Martynov,
and I do something similar for GP out of caution:

                int receive_mtu = MAX(2048, vpninfo->ip_info.mtu + 256);

> I believe that the legacy DTLS_OVERHEAD #define isn't really used in
> any cases that matter, though. Modern AnyConnect servers will use the
> base_mtu not the old tunnel mtu setting (and it probably *is* true that
> older ones don't do AES256). And the 'default' case in
> dtls_get_data_mtu() should never happen either.
>
> Either way, I note that in gpst when you call calculate_mtu() you have
> already been through gpst_parse_config_xml() so you do know precisely
> which ciphersuites are in use, right?

Good point. Can use that to calculate more accurately. Patch.

-Dan