>
>
> On 06/04/17 12:52, Steffan Karger wrote:
>> Hi,
>>
>> On 6 April 2017 at 12:26, David Sommerseth
>> <open...@sf.lists.topphemmelig.net> wrote:
>>> On 06/04/17 11:45, Simon Matter wrote:
>>>>
>>>>> I like Arne's and David's suggestion - the existing option "as is"
>>>>> will
>>>>> enable X% jitter, while a second parameter can specify a more
>>>>> specific
>>>>> range. Following Arne's argument about users and percent math, it
>>>>> might
>>>>> indeed be better to have "min max" here ("3500 3600"), because that
>>>>> is
>>>>> really easy to understand and explain.
>>>>
>>>> After all the discussion I prefer the simple solution. I've changed my
>>>> systems to the reduced 10% jitter and I'm wondering if it has to be
>>>> made
>>>> more complicated than this? I works very well and after some hours the
>>>> renegs have spread very well. If you ask me it's perfectly fine that
>>>> way
>>>> as long as the docs clearly state that a pseudo random 10% us deducted
>>>> from reneg-sec automatically to spread renegs.
>>>
>>> It must be configurable, based on many years experience with helping
>>> out
>>> on configuring OpenVPN tunnels. There are millions of OpenVPN
>>> configurations out in the world (and I don't even think I'm
>>> exaggerating
>>> that much even), many small ones and quite some large ones. There are
>>> VPN service providers with several hundred thousands paying customers,
>>> and there are an enormous amount of VPN service providers in addition.
>>> In addition to all the private and corporate deployments.
>>>
>>> So enforcing a good feature equally on all these configurations will
>>> backfire at us.
>>>
>>> And the more I think about the 10% randomness vlaue (or any
>>> percentage),
>>> I really wonder how clever that is. If a site uses --reneg-sec 1800 (I
>>> have seen that), that means a 3 minute window. If a site uses 14400 (4
>>> hours, I've seen that too), that gives a 24 minute window. These
>>> window
>>> sizes may be perfectly fine. But depending on the amount of connected
>>> users, this may be troublesome too.
>>>
>>> Last night I chatted with krzee on #openvpn-devel about this. He does
>>> quite some cool stuff with OpenVPN and have lots of IP phones
>>> connecting
>>> to VPN servers. He said that randomness by default may not be ideal
>>> for
>>> some of the setups he manages. But he loves the idea behind this
>>> feature.
>>>
>>> Krzee argued that configurations explicitly setting --reneg-sec 3600
>>> should not have any randomness. If a configuration does _not* set
>>> --reneg-sec, it may have randomness with 1 hour as the base. And those
>>> wanting better control of the time window should use:
>>> --reneg-sec min max
>>>
>>> I initially was of the opinion --reneg-sec 3600 should have randomness
>>> (the 10-17% base). But after having slept on it, I think Krzee have a
>>> good point. Setting --reneg-sec explicitly with only a single value
>>> should not have any randomness.
>>>
>>> With the 1 hour default, not setting --reneg-sec gives a time window of
>>> 6 minutes with 10%. That is a reasonable default unless explicitly
>>> overridden by either --reneg-sec 3600 (no randomness) or --reneg-sec
>>> 3000 4000 (with a 1000 seconds large time window)
>>
>> Wow, this discussion suddenly caught some attention! I'll chip in too.
>>
>> I was fine with not making this configurable, but the discussion
>> convinced me that people really want to be able to configure this, so
>> I agree we should.
>>
>> As for the option, I think Arne's proposal is the best:
>> --reneg-sec max [min]
>> where <nothing> == --reneg-sec 3600 == --reneg-sec 3600 3240 (assuming
>> 10% default randomization)
>
> The Initial proposal was --reneg-sec [min] max (horrible)
>
>>
>> Why? Because this
>> 1) doesn't change the meaning of the first argument based on whether
>> the second is present. That's just confusing.
>> 2) does by default what we expect is best for most users: randomize
>> the reneg-sec value
>> 3) still allows administrators to disable randomization
>> 4) 'max' and 'min' are hard to misinterpret ('window', 'jitter' or
>> 'offset' are much easier to misinterpret)
>>
>> As for 'first time only' or 'always': go for always.
>
> If it is set to always, you are permanently changing the function of
> --reneg-sec to always use random *or* no random at all, which the user
> cannot modify. This randomise is only required for the first period
> and subsequent periods should return to normal.
Without knowing exactly how OpenVPN does it, I'm against the first only
approach because it can still result in problems, depending on how the
interval logic is handled.
Time windows can, for one or the other reason, slowly move forward or
backward. If things go wrong, all time windows can slowly move closer and
closer to each other, until the difference between them melts down to
zero.
Simon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
