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
