Patch to apply QoS for DTLS

[Ralph Schmieder]

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
>