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)
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. That will slowly
spread out the clients over the entire reneg-sec window, instead of
over just xx% of the window. The odds that 'all periods line up' that
David mentioned seem negligible to me. Especially assuming that
clients will occasionally reconnect at 'random' times. I did not do
the calculations, but can do that if you really want to.
Finally, we should probably only randomize by default on the server
side. We effectively renegotiate at min(server-reneg-interval,
client-reneg-interval), which will cause a bias towards the earlier
part of the interval if randomize at both sides.
-Steffan
------------------------------------------------------------------------------
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
