Since I seem to have accidentally come out of lurk mode anyway... Someone has submitted a patch for OpenConnect¹ to implement something very much like OpenVPN's --passtos option.
I prefer to remain consistent with OpenVPN and other tools where possible, so we've renamed the option to '--passtos' and my first reaction was to disable it by default, like OpenVPN does. Looking at it harder, though, I'm not sure I really want it disabled by default. It's useful for those who run VoIP over the VPN, and quite frankly the information leakage is minimal — if the attacker can't infer from those tiny packets at regular 20ms intervals that you're using VoIP, then they're probably clueless enough that they won't work it out from the QoS bits either :) Anyone seriously suggesting that --passtos should be off by default for security reasons should probably also need to submit a patch to pad all encrypted packets to the full MTU "to prevent information leakage through packet sizes" before they're taken seriously. Or taken away. Either works for me. So actually my preferred path for "being consistent with OpenVPN" is probably to enable it by default in OpenVPN too... unless I'm missing something? Also, I note that OpenVPN only supports this for Legacy IP — we should be copying the TCLASS bits from IPv6 packets too, right? And does it also make sense to copy the TOS/TCLASS bits from IPv6 payload into Legacy IP tunnel encapsulation, and vice versa? Despite the different names, are the bits expected to have the same meanings? Finally, what about ECN? Does it makes sense to copy the ECN bits? Will routers act upon those even for non-TCP packets, and does that then leave us wanting to deal with the resulting ICMP and convey the message back inside the VPN (which frankly fills me with horror, so let's not). -- dwmw2 ¹ http://lists.infradead.org/pipermail/openconnect-devel/2015-October/003238.html
smime.p7s
Description: S/MIME cryptographic signature
