MTU estimation…

[David Woodhouse]

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.

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170815/dd62fb93/attachment-0001.bin>