Re: [Openvpn-users] migrating from lzo to lz4

[Jan J. K. <ja...@ni...>]

Hi,

On 16/11/17 09:42, Илья Шипицин wrote:
>
>
> 2017-11-16 13:35 GMT+05:00 David Sommerseth <op...@sf... <mailto:op...@sf...>>:
>
>     On 16/11/17 06:59, Илья Шипицин wrote:
>     > hi,
>     >
>     > I'm running vpn server since 2012, with comp-lzo enabled (on both client
>     > and server side)
>     >
>     > in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
>     >
>     > also, I'm considering switching to lz4 from lzo.
>     >
>     > any best practice how to switch lzo --> lz4 without operation interruption ?
>
>     First of all, I'd recommend you to do some performance testing on the
>     typical payload you're pushing through your tunnel.  You might find that
>     LZO can perform better than LZ4 in some scenarios with a lower CPU load.
>      But it is hard to come with a generic recommendation; it depends a lot
>     on what you push through your tunnel and how compressible that data
>     stream is.  A bit more info can be found here: <https://github.com/lz4/lz4/>
>
>     Another detail is the security aspects related to compressing data
>     streams.  The CRIME attack [0] is now an ageing side-channel attack
>     vector which is made possible due to compression.  And there are other
>     compression oracle attacks [1] too, like BREACH [2].
>
>     [0] <https://en.wikipedia.org/wiki/CRIME <https://en.wikipedia.org/wiki/CRIME>>
>     [1] <https://en.wikipedia.org/wiki/Oracle_attack <https://en.wikipedia.org/wiki/Oracle_attack>>
>     [2]
>     <https://threatpost.com/breach-compression-attack-steals-https-secrets-in-under-30-seconds/101579/
>     <https://threatpost.com/breach-compression-attack-steals-https-secrets-in-under-30-seconds/101579/>>
>
>     --compress is pushable.  Not sure if you can mix lzo and lz4
>
>
> it is a separate question, why pushing must be enabled (and it is not enabled by default).
>
this is mostly due to historical reasons: if you enable any form of compression, one byte is reserved in each packet for a 
possible compression flag. Thus, for incompressible data, it actually *hurts* performance to enable compression.


> however, I address here another question, are lzo and lz4 mutually exclusive ?
yes, they are: you can only specify one type of compression per server.
>
> according to man page, you must explicitely specify either "compression lzo" or "compression lz4".
>
>     compression, but I'd just add 'compression' in all the config files and
>
>
> just "compression" is somewhat not clearly covered by documentation. is it "stub" ? or is it "enable both lzo and lz4" ?
>
>     then only push 'compress {lzo,lz4}' to those clients that is reasonable
>     to use.  I would not, however, enable compression itself on by default -
>     just have the compression framing available.
>

by adding
   compression
or
   comp-lzo
to the client config, you turn on the compression bit in each packet, and thus allow the server to push the compression 
algorithm of choice to all clients.

HTH,

JJK