On 05/04/17 09:31, Steffan Karger wrote: > Hi, > > On 05-04-17 08:57, Gert Doering wrote: >> On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote: >>> I've attached v2 now which works without any config change: >> [..] >>> I prefer this version as it allows everybody to profit from it without >>> touching any config files. >> >> I can see the reasoning, but 25% feels a bit on the high side :-) - so >> let the ratholing begin what the number should be. >> >> Steffan, any views from the crypto side of things? > > Not really. I think the feature makes sense, and I like that this will > only *substract* from the set time (so not exceed any set limits). > > (And I agree that 25% feels on the high side - my gut says somewhere > around 10%, but I have no analysis to show why that would be better. > I'll leave picking that number to you.)
The default is 60 minutes. With 25% that means a time window of 15 minutes, so reneg-sec will occur between 45-60 minutes. I see this can be too much for some sites, and perhaps too little on sites which have many users. With 10%, the reneg-window is reduced to 54-60 minutes. For larger sites, this is most likely too small of a window - though far better than everyone at "exactly" 60 minutes. But I am also wondering if this randomness should only occur on the first renegotiation. If you have a 6 minutes time window and 100 connected clients, there is a big chance that at some point the randomness will cause a similar congestion again, as multiple clients to have the same delay. With 25% that chance is lower, but the chance increases again with more clients. So what if this randomness instead only occurs on the _first_ negotiation and then respect the --regneg-sec setting? Then clients will somewhat spread out and then keep a certain predictable renegotiation load. And if using 17%, you get a time window of roughly 10-11 minutes where renegotiation happens. With 100 clients, that means roughly (with a theoretical, ideal and even spread) 10 clients per minute. Which is more reasonable. With 200 clients, it is still getting crowded but not too bad. But all that said ... I think it would be wise to have an optional argument to --reneg-sec (in addition to the 'sec' argument we have today) which can be used to further open or close this time window. Larger sites will most likely want a larger time window than smaller ones. Btw ... is --reneg-sec pushable? (Too lazy to check the code, man page says "no"). If not, it would probably be a good idea to enable that. -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
