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

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

Hi,

On 16/11/17 11:29, Илья Шипицин wrote:
>
>
> 2017-11-16 15:21 GMT+05:00 Jan Just Keijser <ja...@ni... <mailto: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.
>
>
> so, if clients support pushes (2.3 or higher), I can leave "comp-lzo" in client configs .... enable "compress lz4" in server 
> configs and push it ?
> those clients who do not support pushes will get broken ?
>
yes, pretty much: all clients that have 'comp-lzo' in the client config and that support LZ4 can be told to use LZ4 compression 
by adding
   push "compress lz4"
in the server config.
"push-peer-info" will tell you whether a client supports LZ4 or not.

JJK