fwiw, the IPSec implementation of Mac OS X (ipsec-tools) has it on by default and there's no way for the user to turn it off (that I'm aware of). Not sure if this is also true for *bsd as Apple has added quite a few features. Thanks, -ralph Sent from my iPhone > On Oct 23, 2015, at 10:24, David Woodhouse <dwmw2 at infradead.org> wrote: > >> 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 >
