Patch to apply QoS for DTLS

[David Woodhouse]

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>