On Thu, 2015-10-22 at 08:07 +0200, Ralph Schmieder wrote: > > > This patch will currently modify the packets from the client to server > > only. Wouldn't it be more efficient if that included a header to server > > (e.g., X-DTLS-PassTOS = true), so that these packets include the tos as > > well? That of course would only work with ocserv. > > > > Could be an option. Both directions are totally independent, however. > Since QoS is controlled also independently on both ends (and, more > importantly, independent on everything in between, e.g. the WAN/ISP) > it does not make a lot of sense to signal this setting to the server > as the client has no control whatsoever on the server side. > > E.g. it can signal 'pass TOS, please" but even if the server then > marks the packets it could have no effect at all since it might not > be implemented on the server's network. I think it makes sense. This option is really an indication of paranoia level. The only people who really want it off would be the people who are really worried about information leakage. (Which would be stupid of them, given that an attacker can already make inferences from the size and regularity of the VoIP packets which are likely to be making use of it. If those people were pushing a patch to pad all VPN packets to the full MTU, to prevent inferences from being made about the ESP/DTLS packets on the public network, that might at least be less inconsistent of them.) So the --passtos option does make sense to control behaviour at *both* ends, I think. A *server* might want a paranoia option to force it off, and not just do what the client asks. Although I really do have little sympathy for those who want it off. I'm almost regretting the request to disable it by default ? I know it makes sense to err on the side of caution, and I do like to strive for consistency with other tools like OpenVPN though. I might go see if I can persuade OpenVPN to change to enabling it by default :) -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20151023/0c5d8656/attachment.bin>
