On Tue, Jun 24, 2014 at 10:08 AM, David Woodhouse <dwmw2 at infradead.org> wrote: >> btw. regarding that, I realized that all anyconnect clients connecting >> to ocserv, the first seconds of the session perform an MTU discovery >> using DPD packets (over DTLS). These DPD packets range from the maximum >> MTU to small values, and have a padding with some fixed format (they do >> not just contain arbitrary data after the dpd header). I attach some >> example captures in case you're interested, but I wouldn't consider that >> as a blocker for 6.00. > Hm, joy. So that's a third way of negotiating the MTU, and this time > possibly even after the interface has been set up? That's a quite reasonable approach as one's idea of the MTU during negotiation may not be precise. I don't think it's an issue to change the MTU of the tun device at any point (at least if you know the name of the tun device and SIOCSIFMTU is available). > We haven't really understood how the X-CSTP-Base-MTU thing works yet, have > we? Or indeed how it can *ever* work reliably... which may explain why > there's now a new method :) My impression is that this is the other party's best guess of the MTU of the link (irrespective of the negotiated ciphersuite, just the mtu for raw packets). That's much easier to work with as you don't have to consider the difference of header size between TLS and DTLS. regards, Nikos
