Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 06/04/17 14:49, David Sommerseth wrote:
> On 06/04/17 15:37, debbie10t wrote:
>> Company A has 1,000 vpn users and (for what ever reason) they reboot
>> the server every 24 hours.  They experience the slow down because all
>> their vpn users are permanently connected.  They all connect at once.
>> This patch is not trying to address the initial connect it is trying
>> to address the subsequent reneg's all happening at once.
>
> This is not what --reneg-sec is about.  --reneg-sec does not control the
> initial connection.  What you want here is a randomized initial
> connection delay when client have lost connection to the openvpn server
> and needs to do a reCONNECT.
>
> That is an entirely different feature than reNEGOTIATION of established
> tunnels (which --reneg-sec targets).  However, randomizing --reneg-sec
> will improve the situation *after* the initial connect congestion, once
> the first renegotiation round starts.  At this point in time, things
> will start to spread out.
>
> But I emphasize again, --reneg-sec have never tried to solve randomizing
> of the _initial_ connect step.
>

Which is exactly what I said ..

 >> This patch is not trying to address the initial connect it is trying
 >> to address the subsequent reneg's all happening at once.

Regards

--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 06/04/17 15:37, debbie10t wrote:
> Company A has 1,000 vpn users and (for what ever reason) they reboot
> the server every 24 hours.  They experience the slow down because all
> their vpn users are permanently connected.  They all connect at once.
> This patch is not trying to address the initial connect it is trying
> to address the subsequent reneg's all happening at once.

This is not what --reneg-sec is about.  --reneg-sec does not control the
initial connection.  What you want here is a randomized initial
connection delay when client have lost connection to the openvpn server
and needs to do a reCONNECT.

That is an entirely different feature than reNEGOTIATION of established
tunnels (which --reneg-sec targets).  However, randomizing --reneg-sec
will improve the situation *after* the initial connect congestion, once
the first renegotiation round starts.  At this point in time, things
will start to spread out.

But I emphasize again, --reneg-sec have never tried to solve randomizing
of the _initial_ connect step.

-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

>
>
> On 06/04/17 12:52, Steffan Karger wrote:
>> Hi,
>>
>> On 6 April 2017 at 12:26, David Sommerseth
>>  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  == --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 

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 06/04/17 14:05, Gert Doering wrote:
> Hi,
>
> On Thu, Apr 06, 2017 at 01:49:04PM +0100, debbie10t wrote:
>> As you can see, the current proposal does not allow for first random,
>> followed by expected/normal/regular renegs. It is either *always* random
>> or *never* random .. I believe this is a poor decision.
>
> Your voice has been heard, and nobody else of the core team has been
> convinced.  It is not necessary to repeat that more often.

I believe the core team has made a poor decision and I am trying to 
explain clearly "why".

Take for example:

Company A has 1,000 vpn users and (for what ever reason) they reboot
the server every 24 hours.  They experience the slow down because all
their vpn users are permanently connected.  They all connect at once.
This patch is not trying to address the initial connect it is trying
to address the subsequent reneg's all happening at once.

So, Company A decides to use --reneg-sec max min

Subsequently, Company A receive a flood of complaints from users who are 
being constantly randomly reneg'd .. when they are accustomed to
regular hourly reneg's.

Company A either disables the randomisation ..
or tells their users "what" ?

The only justifiable randon reneg is the first one and Company A would 
be able to explain that to their users, that they must experience one 
random reneg or they all experience slow down at hourly intervals.


Regards

--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> Web servers these days are also multi-threaded (or "multi-forked"), so
> they can utilize multiple cores more efficiently.  OpenVPN is *single
> threaded*.  So when one client starts a TLS renegotiation, it blocks all
> the other connected clients until the renegotiation have completed.
> When you then have 100 connected clients spending 1-2 seconds on each
> renegotiation happening at the same time, you will have 100-200 seconds
> of slow and lagging VPN tunnel.  This does not mean that you will see a
> CPU spike, as each client is handled serialized (one by one) - not in
> parallel.

That's only true for single instance servers, with multiple OpenVPN
instances and limited CPU cores this quickly becomes an issue.

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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 06/04/17 14:49, debbie10t wrote:
> 
> As you can see, the current proposal does not allow for first random,
> followed by expected/normal/regular renegs. It is either *always* random
> or *never* random .. I believe this is a poor decision.

Even though I see arguments for first-only, I have no issues having the
current implementation being "always" or "none".

Adding a flag so the user can switch it to "first-only" will be a fairly
trivial patch to add.  In fact, I already now believe 66% of that
possible future patch will be updating the man page and Changes.rst.
The code itself to manage this will be probably around 10-15 lines of
code - possibly even less - when basing it on the "always" behaviour.

And if not a critical mass of users complains within a reasonable time
... well, then we don't need to bother.

No need to make even more noise about that now.


-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Gert Doering]

Hi,

On Thu, Apr 06, 2017 at 01:49:04PM +0100, debbie10t wrote:
> As you can see, the current proposal does not allow for first random,
> followed by expected/normal/regular renegs. It is either *always* random
> or *never* random .. I believe this is a poor decision.

Your voice has been heard, and nobody else of the core team has been
convinced.  It is not necessary to repeat that more often.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP 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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 06/04/17 12:52, Steffan Karger wrote:
> Hi,
>
> On 6 April 2017 at 12:26, David Sommerseth
>  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  == --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.

People are accustomed to a one hour period, I feel sure that randomising
the period permanently will drive people insane!

The point of putting this "into" openvpn binary is in order to break up
the "renegging" clients on the first reneg *only*, then changing back
to normal behaviour.  This "changing back" cannot be done via a script
because no scripts are called on --reneg-sec, therefore it *must* be
done by the binary.

As you can see, the current proposal does not allow for first random,
followed by expected/normal/regular renegs. It is either *always* random
or *never* random .. I believe this is a poor decision.


> That will slowly
> spread out the 

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Steffan Karger]

Hi,

On 6 April 2017 at 12:26, David Sommerseth
 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  == --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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 06/04/17 11:26, David Sommerseth wrote:

> 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)

I still believe this approach is wrong.

You are changing the meaning of an operand depending on the number of 
operands and changing the function of the directive depending on number
of operands and if the directive is explicitly specified or not.

This is equivalent to:

(no --server specified) = --server 10.8.0.0 255.255.255.0
vs
--server subnet mask (pool determined by default)
vs
--server *pool* subnet mask

And so I re-submit my protest!

The syntax for --reneg-sec should be "--reneg-sec seconds window"

where "--reneg-sec 3600" is as it is now !
where "--reneg-sec 3600 360" is as now with a 10% window of random.

Not specifying --reneg-sec at all should *not* imply a default window,
it should remain as it is now.

Additionally, "window" *could* be + or - allowing for window to be 
applied at the beginning of the session or at the end of the session.

Also, IMO this should be first-run *only*

I am sorry David but you have not changed my mind,
although the decision is, of course, down to the devs.

my2c
regards

--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

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)


-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 06/04/17 06:08, Илья Шипицин wrote:
> 
> 
> 2017-04-06 3:26 GMT+05:00 David Sommerseth
>  >:
> 
> On 05/04/17 23:43, Илья Шипицин wrote:
> > hello!
> >
> > just curious how renegotiation is handled in "https" ?
> > is it "an abbrevated ssl handshake" (RFC 2246) or ... ?
> 
> The HTTPS and OpenVPN protocol is not comparable in this regard at all.
> AFAIR, OpenVPN does not make use of the TLS renegotiation possibility at
> all.  So a renegotiation in OpenVPN actually results in a completely new
> and fresh TLS session, not related to previous TLS sessions at all.
> 
> 
> both HTTPS and OpenVPN are
> 
> 1) client-->server
> 2) long running
> 3) SSL based
> 
> 
> they are similar from many point of view
> 
> as, renegotiation does occur for https, and we do not observe "hourly"
> CPU peaks, I think it worth not reinventing the wheel here


This is equal to say HTTPS and OpenVPN are both networked applications,
disregarding the differences of *how* these applications really work.
Just like apples and oranges are both fruits.  They are still very much
different.

HTTPS in this context is quite misleading.  We need to primarily talk
about SSL/TLS.  HTTPS is basically HTTP over an SSL/TLS connection.  So
keep that in mind.  The same goes for any SSL/TLS enabled service
(IMAPS/POP3S, SMTP, XMPP, etc, etc)

A typical HTTPS connection consists of:

 a) The client connects to the HTTPS server using a *TCP* port,
 b) The TLS handshake happens (managed by the SSL library)
 c) Client sends plain text data to the SSL library
 d) SSL library encrypts the data
 e) Encrypted data is sent to the server
 f) Server decrypts data
 g) the webserver receives the (decrypted) plain text data,
processes the request and sends the plain text result to
SSL library
 h) SSL library encrypts the data
 i) Encrypted result is sent back to the client
 j) Client decrypts data, lets the application process the
plain text data
 k) Client closes the connection to the server

For *each* HTTPS request, these steps happens.  The TLS handshake is CPU
intensive and costs CPU cycles.  So there exists TLS extensions for
session resumption, which allows the following connections to re-use the
already negotiated encryption keys.  And to ensure this keying material
is rotated, the application *may* choose to make use of the TLS
renegotiation feature.  But it is not a requirement.

OpenVPN is different in regards to it's SSL/TLS usage is not bound to
TCP (SSL/TLS is by design TCP _only_).  OpenVPN splits the communication
over a single UDP/TCP socket into a control channel and a data channel.
The data channel uses _only_ symmetric encryption, while the TLS packets
is sent over the control channel.  *All* OpenVPN packets, regardless of
data or control channel, are encapsulated with some more information
about the client, reliability details, as well as which channel the
packet belongs - and a few other bits.  This also enables OpenVPN to
send SSL/TLS packets over a UDP socket.

A typical OpenVPN TLS connection goes more like this:

 1) Client connects to the server, using * UDP _or_ TCP*

 2) TLS handshake goes over the control channel

 3) Once the TLS handshake has completed successfully, encryption
keys are derived for the data channel.  This key is not strictly
tied to the TLS specification itself, but can be seen as an
independent key (this is extremely simplified and not 100% correct,
but this background is enough to explain the next steps).

The next things the control channel transports are the network
configuration, routing, user/password authentication, other
--push'ed options, OCC details, etc.

 4) packets sent on the TUN/TAP device gets picked up as "plain text",
gets encrypted and sent to the remote side over the UDP/TCP socket
as data channel packets, decrypted and put on the remote sides'
TUN/TAP device.  The encryption used here is the symmetric
encryption based on the keying material from step 3.

 5) other OpenVPN features (--ping, etc) is sent at regular intervals
as control channel packets to the remote side and processed
accordingly there, responses are sent back.  The data payload of
the control channel utilizes the SSL libraries TLS way of sending
encrypted data and decrypt it; similar to HTTPS.

 6) goto 4, unless a --reneg-* situation hits, the client or server
decides to close the connection or other signals are received

 7a) In case of --reneg-* situation, goto 2 and start a new TLS
 handshake, and prepare a switch from old keys to new keys.

 7b) In case of a request/signal to close the tunnel, close the UDP/TCP
 socket and exit the program.


The *main* difference here is that while HTTPS initiates a new TCP
connection, implying the need for a TLS handshake for each connection,
OpenVPN have a single socket open for the life time 

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> Hi,
>
> On Wed, Apr 05, 2017 at 07:00:54PM +0100, debbie10t wrote:
>> > Optional option does not mean that it is disabled by default. If you
>> > don't the randomness you would need to do:
>> >
>> > reneg-sec 3600 3600
>> >
>> > the optional argument also allows it to fine tune it to your needs.
>>
>> As the reason for --reneg-sec is to specify how long a key should exist,
>> I don't see any further need to make the "random window" be specifically
>> configurable .. The reneg-sec period will remain as specified (def 3600)
>> except for the first run, where --reneg-sec is started from a random
>> time between now and then.  There after returning to "normal" with full
>> randomisation of all connected clients --reneg-sec being spread over the
>> *entire* period of --reneg-sec nn and not some unnecessary window.
>
> Setups with 2FA will have to re-enter auth credentials on reneg.  Having
> OpenVPN all of a sudden default to "it could be asking 5 minutes after
> connection for the credentials again" is massive annoyance - and brings
> no real benefit anyway.
>
> It makes sense to jitter reneg-sec somewhat (like, 10%-ish), but changing
> behaviour too much is not bringing much benefit - you don't need to
> spread the reneg over the whole period anyway, as different clients
> connect and disconnect at different times anyway.  Just if all of them
> connect at the same time, the identically-timed renegs are a problem.

That's exactly what happens in the event of an OpenVPN restart on the
central server. Our router clients may all restart for updates at the same
time and our desktop clients are automatically started in the morning most
of them at the same time.

> 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.

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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 06/04/17 00:30, debbie10t wrote:
> 
> One final clarification:
> 
> As a user, I would prefer to see an early 2fa re-connect than one in
> the final few minutes, especially if I am already accustomed to a one
> hour cut off. Such that, I do 45 mins of work and get cut off is more
> annoying then doing 15 mins and get cut off.

This doesn't make much sense to me, to be honest.

At least all those 2FA approaches I've used (both hardware and software
tokens) usually have a life time of 30 seconds for each token.  So
unless the user types username and the new OTP code and password within
a reasonable time, the connection should be closed regardless.  Whenever
this renegotiation happens, it doesn't matter if 2FA is used or not - as
the 2FA code is most likely outdated already.

That said, doing a re-connect enforcing users to type in another 2FA is
also less than ideal - which can in a short term scope be avoided by
adding --auth-gen-token to the server config.  Which should preserve a
reasonably well security level on the session anyway.

And in regards to the --reneg-sec discussion ... whether it happens
after 3363 seconds or 3599 seconds doesn't really matter much for the
end-user.  Regardless of 2FA or not.


-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 05/04/17 23:57, debbie10t wrote:
> Hi,
> 
> On 05/04/17 22:39, David Sommerseth wrote:
>> On 05/04/17 23:13, debbie10t wrote:
>>> I don't believe there is any need to specify "max" because that would be
>>> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
>>
>> I think you, probably without being aware of it, are agreeing to what
>> the current proposal is:
>>
>>   --reneg-sec max
>> A renegotiation happens within 'max' seconds, but with a 10%-ish
>> randomness
>  >
>>   --reneg-sec min max
>> A renegotiation happens within 'min' and 'max' seconds, fully
>> controllable
>>
>> So using --reneg-sec 3600 3600, effectively removes the randomness.
> 
> I understand the proposed methods ..
> 
> Of the two above, I would be inclined toward option 2.
> eg: (for me) --reneg-sec 0 3600 is ideal.

We are not going to change the behaviour much of what is already
available today.  So if we end up at 10% ... the new default will be:

   --reneg-sec 3240 3600

If you you do  --reneg-sec 1800, that will effectively become:

   --reneg-sec 1620 1800

If you want to have a larger time window, then you do what you say
above.  Your "0 3600" will not become any default value.  But you may
choose to use those values if you want to.

The key point is that

   --reneg-sec 1800

will work; thus not breaking any configurations - this we will not
deviate away from.  This syntax just calculates the "min" value
automatically for you.  If you provide both "min" and "max" values,
that's what ends up being used.

Currently, I don't see the need to make it more complicated than this.
And I don't think Gert nor Arne does either.

What will need to be discussed though is if this randomness should only
happen on the first or on all renegotiations; and if that should be
configurable or not.  And we need a discussion around if we will allow
this to be pushable or not.


-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

One final clarification:

As a user, I would prefer to see an early 2fa re-connect than one in
the final few minutes, especially if I am already accustomed to a one
hour cut off. Such that, I do 45 mins of work and get cut off is more
annoying then doing 15 mins and get cut off.

Regards


--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 05/04/17 23:43, Илья Шипицин wrote:
> hello!
> 
> just curious how renegotiation is handled in "https" ?
> is it "an abbrevated ssl handshake" (RFC 2246) or ... ?

The HTTPS and OpenVPN protocol is not comparable in this regard at all.
AFAIR, OpenVPN does not make use of the TLS renegotiation possibility at
all.  So a renegotiation in OpenVPN actually results in a completely new
and fresh TLS session, not related to previous TLS sessions at all.


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc



> 2017-04-06 2:39 GMT+05:00 David Sommerseth
>  >:
> 
> On 05/04/17 23:13, debbie10t wrote:
> > I don't believe there is any need to specify "max" because that would be
> > --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
> 
> I think you, probably without being aware of it, are agreeing to what
> the current proposal is:
> 
>   --reneg-sec max
> A renegotiation happens within 'max' seconds, but with a 10%-ish
> randomness
> 
>   --reneg-sec min max
> A renegotiation happens within 'min' and 'max' seconds, fully
> controllable
> 
> So using --reneg-sec 3600 3600, effectively removes the randomness.
> 
> 
> --
> 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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 05/04/17 23:01, debbie10t wrote:
>
>
> On 05/04/17 22:57, debbie10t wrote:
>> Hi,
>>
>> On 05/04/17 22:39, David Sommerseth wrote:
>>> On 05/04/17 23:13, debbie10t wrote:
 I don't believe there is any need to specify "max" because that
 would be
 --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
>>>
>>> I think you, probably without being aware of it, are agreeing to what
>>> the current proposal is:
>>>
>>>   --reneg-sec max
>>> A renegotiation happens within 'max' seconds, but with a 10%-ish
>>> randomness
>>>
>>>   --reneg-sec min max
>>> A renegotiation happens within 'min' and 'max' seconds, fully
>>> controllable
>>>
>>> So using --reneg-sec 3600 3600, effectively removes the randomness.
>>
>> I understand the proposed methods ..
>>
>> Of the two above, I would be inclined toward option 2.
>> eg: (for me) --reneg-sec 0 3600 is ideal.
>>
>> Thanks :)
>
> With the proviso of "First-run only" ..

sorry to not shut up ! :)
(due to logic errors)

--reneg-sec reneg-sec "first-run random offset"

eg:
--reneg-sec 3600 0 is equal to --reneg-sec 3600
--reneg-sec 3600 3600  is equal to --reneg-sec 3600 *
* with a first time run of any random number between 0 and 3600.
(regardless of sign)
(the opposite of the actual proposal)

--reneg-sec 3600 360   would be equal to the 10% jitter proposal.

Sound ok ?
Regards





--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 05/04/17 22:57, debbie10t wrote:
> Hi,
>
> On 05/04/17 22:39, David Sommerseth wrote:
>> On 05/04/17 23:13, debbie10t wrote:
>>> I don't believe there is any need to specify "max" because that would be
>>> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
>>
>> I think you, probably without being aware of it, are agreeing to what
>> the current proposal is:
>>
>>   --reneg-sec max
>> A renegotiation happens within 'max' seconds, but with a 10%-ish
>> randomness
>>
>>   --reneg-sec min max
>> A renegotiation happens within 'min' and 'max' seconds, fully
>> controllable
>>
>> So using --reneg-sec 3600 3600, effectively removes the randomness.
>
> I understand the proposed methods ..
>
> Of the two above, I would be inclined toward option 2.
> eg: (for me) --reneg-sec 0 3600 is ideal.
>
> Thanks :)

With the proviso of "First-run only" ..

--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

Hi,

On 05/04/17 22:39, David Sommerseth wrote:
> On 05/04/17 23:13, debbie10t wrote:
>> I don't believe there is any need to specify "max" because that would be
>> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
>
> I think you, probably without being aware of it, are agreeing to what
> the current proposal is:
>
>   --reneg-sec max
> A renegotiation happens within 'max' seconds, but with a 10%-ish
> randomness
 >
>   --reneg-sec min max
> A renegotiation happens within 'min' and 'max' seconds, fully
> controllable
>
> So using --reneg-sec 3600 3600, effectively removes the randomness.

I understand the proposed methods ..

Of the two above, I would be inclined toward option 2.
eg: (for me) --reneg-sec 0 3600 is ideal.

Thanks :)

--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Илья Шипицин]

hello!

just curious how renegotiation is handled in "https" ?
is it "an abbrevated ssl handshake" (RFC 2246) or ... ?

2017-04-06 2:39 GMT+05:00 David Sommerseth <
open...@sf.lists.topphemmelig.net>:

> On 05/04/17 23:13, debbie10t wrote:
> > I don't believe there is any need to specify "max" because that would be
> > --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
>
> I think you, probably without being aware of it, are agreeing to what
> the current proposal is:
>
>   --reneg-sec max
> A renegotiation happens within 'max' seconds, but with a 10%-ish
> randomness
>
>   --reneg-sec min max
> A renegotiation happens within 'min' and 'max' seconds, fully
> controllable
>
> So using --reneg-sec 3600 3600, effectively removes the randomness.
>
>
> --
> kind regards,
>
> David Sommerseth
> OpenVPN Technologies, Inc
>
>
>
> 
> --
> 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
>
>
--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 05/04/17 23:13, debbie10t wrote:
> I don't believe there is any need to specify "max" because that would be 
> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

I think you, probably without being aware of it, are agreeing to what
the current proposal is:

  --reneg-sec max
A renegotiation happens within 'max' seconds, but with a 10%-ish
randomness

  --reneg-sec min max
A renegotiation happens within 'min' and 'max' seconds, fully
controllable

So using --reneg-sec 3600 3600, effectively removes the randomness.


-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 05/04/17 22:42, Gert Doering wrote:
> 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.

I agree to Arne's approach, using only min/max values instead of a
percentage value as well.


-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 05/04/17 21:42, Gert Doering wrote:
> Hi,
>
> On Wed, Apr 05, 2017 at 07:00:54PM +0100, debbie10t wrote:
>>> Optional option does not mean that it is disabled by default. If you
>>> don't the randomness you would need to do:
>>>
>>> reneg-sec 3600 3600
>>>
>>> the optional argument also allows it to fine tune it to your needs.
>>
>> As the reason for --reneg-sec is to specify how long a key should exist,
>> I don't see any further need to make the "random window" be specifically
>> configurable .. The reneg-sec period will remain as specified (def 3600)
>> except for the first run, where --reneg-sec is started from a random
>> time between now and then.  There after returning to "normal" with full
>> randomisation of all connected clients --reneg-sec being spread over the
>> *entire* period of --reneg-sec nn and not some unnecessary window.
>
> Setups with 2FA will have to re-enter auth credentials on reneg.  Having
> OpenVPN all of a sudden default to "it could be asking 5 minutes after
> connection for the credentials again" is massive annoyance - and brings
> no real benefit anyway.
>
> It makes sense to jitter reneg-sec somewhat (like, 10%-ish), but changing
> behaviour too much is not bringing much benefit - you don't need to
> spread the reneg over the whole period anyway, as different clients
> connect and disconnect at different times anyway.  Just if all of them
> connect at the same time, the identically-timed renegs are a problem.
>
>
> 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.

I don't believe there is any need to specify "max" because that would be 
--reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

I accept that "min" or "window" is viable (provided it is first-run)

But, overall, I think having to login twice in succession at a 
surprisingly short random time *just the once* and then followed by 
regular intervals is not such a huge concern, if it is suitably 
documented.  So I vote for my version.

Of course, it is up to you guys and I will leave it at that.

Thanks

--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Gert Doering]

Hi,

On Wed, Apr 05, 2017 at 07:00:54PM +0100, debbie10t wrote:
> > Optional option does not mean that it is disabled by default. If you
> > don't the randomness you would need to do:
> >
> > reneg-sec 3600 3600
> >
> > the optional argument also allows it to fine tune it to your needs.
> 
> As the reason for --reneg-sec is to specify how long a key should exist,
> I don't see any further need to make the "random window" be specifically
> configurable .. The reneg-sec period will remain as specified (def 3600)
> except for the first run, where --reneg-sec is started from a random 
> time between now and then.  There after returning to "normal" with full 
> randomisation of all connected clients --reneg-sec being spread over the 
> *entire* period of --reneg-sec nn and not some unnecessary window.

Setups with 2FA will have to re-enter auth credentials on reneg.  Having
OpenVPN all of a sudden default to "it could be asking 5 minutes after
connection for the credentials again" is massive annoyance - and brings
no real benefit anyway.

It makes sense to jitter reneg-sec somewhat (like, 10%-ish), but changing
behaviour too much is not bringing much benefit - you don't need to 
spread the reneg over the whole period anyway, as different clients 
connect and disconnect at different times anyway.  Just if all of them
connect at the same time, the identically-timed renegs are a problem.


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.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP 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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 05/04/17 18:13, Arne Schwabe wrote:
>
>>>
>>> Where RAND indicates that the first-run timer should run from a random
>>> integer from 1 upto the value of --reneg-sec.  RAND does not require a
>>> user to specify an amount.
>>
>> But then, why not just do it always and forget about the additional option?

I actually agree, why not simply enable RAND as above *always*

>>
>
> Optional option does not mean that it is disabled by default. If you
> don't the randomness you would need to do:
>
> reneg-sec 3600 3600
>
> the optional argument also allows it to fine tune it to your needs.

As the reason for --reneg-sec is to specify how long a key should exist,
I don't see any further need to make the "random window" be specifically
configurable .. The reneg-sec period will remain as specified (def 3600)
except for the first run, where --reneg-sec is started from a random 
time between now and then.  There after returning to "normal" with full 
randomisation of all connected clients --reneg-sec being spread over the 
*entire* period of --reneg-sec nn and not some unnecessary window.

Regards

--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Arne Schwabe]

>>
>> Where RAND indicates that the first-run timer should run from a random
>> integer from 1 upto the value of --reneg-sec.  RAND does not require a
>> user to specify an amount.
> 
> But then, why not just do it always and forget about the additional option?
> 

Optional option does not mean that it is disabled by default. If you
don't the randomness you would need to do:

reneg-sec 3600 3600

the optional argument also allows it to fine tune it to your needs.

Arne


--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

>
>
> On 05/04/17 17:13, debbie10t wrote:
>>
>>
>> On 05/04/17 16:58, David Sommerseth wrote:
>>> On 05/04/17 17:53, David Sommerseth wrote:
 On 05/04/17 16:42, debbie10t wrote:
>
>>
>
> A different approach could be like so:
>
> --reneg-sec 3600
> --reneg-sec-1sttime-rand 1|0 (The name here for detail)

>>
>>>
>>> Oh, and in regards to the first-time/non-first-time  if we decide
>>> for such flexibility, that can be a flag after the randomness.
>>>
>>> For example  --reneg-sec 3600 12 first-only
>>>
>>> I am far from convinced if that should be configurable or not.  But
>>> still, this approach is still far better than introducing new options.
>>>
>>
>> Ok - accept that new options is not preferred but ..
>>
>> I like the idea of "first-only" addition (which is more or less as I
>> proposed anyway) - And so, instead of having randomness in the reneg-sec
>> itself, it is only randomness in the first run, after that the expected
>> behaviour would be restored.  eg: --reneg-sec 3600
>>
>> To my mind (as a non programmer) this essentially boils down to
>> setting the first --reneg-sec timer to something between 1 and
>> 3600 (default). This affords a much larger window for the scattering
>> of clients and further behaviour is "as expected now".
>>
>> and it looks very non-instrusive to me ..
>>
>
> To clarify:  --reneg-sec 3600 RAND
>
> Where RAND indicates that the first-run timer should run from a random
> integer from 1 upto the value of --reneg-sec.  RAND does not require a
> user to specify an amount.

But then, why not just do it always and forget about the additional option?

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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 05/04/17 17:13, debbie10t wrote:
>
>
> On 05/04/17 16:58, David Sommerseth wrote:
>> On 05/04/17 17:53, David Sommerseth wrote:
>>> On 05/04/17 16:42, debbie10t wrote:

>

 A different approach could be like so:

 --reneg-sec 3600
 --reneg-sec-1sttime-rand 1|0 (The name here for detail)
>>>
>
>>
>> Oh, and in regards to the first-time/non-first-time  if we decide
>> for such flexibility, that can be a flag after the randomness.
>>
>> For example  --reneg-sec 3600 12 first-only
>>
>> I am far from convinced if that should be configurable or not.  But
>> still, this approach is still far better than introducing new options.
>>
>
> Ok - accept that new options is not preferred but ..
>
> I like the idea of "first-only" addition (which is more or less as I
> proposed anyway) - And so, instead of having randomness in the reneg-sec
> itself, it is only randomness in the first run, after that the expected
> behaviour would be restored.  eg: --reneg-sec 3600
>
> To my mind (as a non programmer) this essentially boils down to
> setting the first --reneg-sec timer to something between 1 and
> 3600 (default). This affords a much larger window for the scattering
> of clients and further behaviour is "as expected now".
>
> and it looks very non-instrusive to me ..
>

To clarify:  --reneg-sec 3600 RAND

Where RAND indicates that the first-run timer should run from a random
integer from 1 upto the value of --reneg-sec.  RAND does not require a
user to specify an amount.

Regards



--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Arne Schwabe]

would probably be a good idea to enable that.

> As I understand it client and server have 60 min. by default. Whatever is
> configured, the smaller value wins. That means, bad clients can set their
> reneg-sec to very low values and trash the server on the other end. From
> the server side this looks more or less like a DDOS.
>
> In our environment we have set reneg-sec=0 on all clients because we want
> the server to have control over it. That's fine because we have only
> trusted clients. Making it pushable could be a solution to overwrite bad
> settings in clients. A more radical solution was to just remove the option
> on the client side.
At its heart OpenVPN is still p2p instead of client of server, (Actually
client is p2p mode). So removing a client setting removes it also for p2p.

I would also say have a 5% random component by default (makes 3 minutes
for the 1h default) but let the user specify it as explicit range when
then second (optional) parameter is present.

Either

reneg-sec 3600 3500 for 3500s-3600s (absolute)
or
reneg-sec 3600 100 for 3500s-3600s (relative)

I think percent based for user inputs are always creating confusion.

Arne



--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 05/04/17 17:53, David Sommerseth wrote:
> On 05/04/17 16:42, debbie10t wrote:
>>
>>
>> On 05/04/17 05:34, Simon Matter wrote:
> Hi,
>
> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
>> Interesting to see that there is zero interest in this patch here.
>
> This is a misinterpretation.
>

 Hi Gert,

 Thanks for the explanation, I'll be patient then :)

 If it's preferred for the patch to keep it even simpler and compatible the
 current configs, it could be broken down to something like this in init.c:
>>>
>>> I've attached v2 now which works without any config change:
>>>
>>> --reneg-sec n
>>> Renegotiate data channel key after n seconds (default=3600).
>>>
>>> Note that the effective value used here is a per session pseudo-
>>> randomized 25% of n deducted from n.  With the default value  of
>>> 3600 this results in an effective per session value in the range
>>> of 2701 ... 3600 seconds.
>>>
>>
>>
>> A different approach could be like so:
>>
>> --reneg-sec 3600
>> --reneg-sec-1sttime-rand 1|0 (The name here for detail)
> 
> Too complicated ;-)
> 
> --reneg-sec  # 60 minutes, with X % in randomness
> --reneg-sec 1800 # 30 minutes, with X % in randomness
> (X is what we figure is reasonable by default; between 10-25%)
> 
> --reneg-sec 3600 30  # 60 minutes, 30% randomness
> --reneg-sec 1800 0   # 30 minutes, no randomness
> 
> This won't break any configurations and gives full flexibility without
> adding new options (which we really try to avoid).

Oh, and in regards to the first-time/non-first-time  if we decide
for such flexibility, that can be a flag after the randomness.

For example  --reneg-sec 3600 12 first-only

I am far from convinced if that should be configurable or not.  But
still, this approach is still far better than introducing new options.


-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 05/04/17 16:42, debbie10t wrote:
> 
> 
> On 05/04/17 05:34, Simon Matter wrote:
 Hi,

 On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
> Interesting to see that there is zero interest in this patch here.

 This is a misinterpretation.

>>>
>>> Hi Gert,
>>>
>>> Thanks for the explanation, I'll be patient then :)
>>>
>>> If it's preferred for the patch to keep it even simpler and compatible the
>>> current configs, it could be broken down to something like this in init.c:
>>
>> I've attached v2 now which works without any config change:
>>
>> --reneg-sec n
>> Renegotiate data channel key after n seconds (default=3600).
>>
>> Note that the effective value used here is a per session pseudo-
>> randomized 25% of n deducted from n.  With the default value  of
>> 3600 this results in an effective per session value in the range
>> of 2701 ... 3600 seconds.
>>
> 
> 
> A different approach could be like so:
> 
> --reneg-sec 3600
> --reneg-sec-1sttime-rand 1|0 (The name here for detail)

Too complicated ;-)

--reneg-sec  # 60 minutes, with X % in randomness
--reneg-sec 1800 # 30 minutes, with X % in randomness
(X is what we figure is reasonable by default; between 10-25%)

--reneg-sec 3600 30  # 60 minutes, 30% randomness
--reneg-sec 1800 0   # 30 minutes, no randomness

This won't break any configurations and gives full flexibility without
adding new options (which we really try to avoid).


-- 
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 05/04/17 05:34, Simon Matter wrote:
>>> Hi,
>>>
>>> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
 Interesting to see that there is zero interest in this patch here.
>>>
>>> This is a misinterpretation.
>>>
>>
>> Hi Gert,
>>
>> Thanks for the explanation, I'll be patient then :)
>>
>> If it's preferred for the patch to keep it even simpler and compatible the
>> current configs, it could be broken down to something like this in init.c:
>
> I've attached v2 now which works without any config change:
>
> --reneg-sec n
> Renegotiate data channel key after n seconds (default=3600).
>
> Note that the effective value used here is a per session pseudo-
> randomized 25% of n deducted from n.  With the default value  of
> 3600 this results in an effective per session value in the range
> of 2701 ... 3600 seconds.
>


A different approach could be like so:

--reneg-sec 3600
--reneg-sec-1sttime-rand 1|0 (The name here for detail)

where --reneg-sec is essentially left alone
but --reneg-sec-1sttime-rand does the very first renegotiation at some
random time upto the --reneg-sec parameter.  After that --reneg-sec is
only in play.

It could even be done as --rand-reneg 1|0 and that could be set
to randomize *all* --reneg-* parameters upto the limit of the --reneg-*
in question and then hand control back to the --reneg-* in use after 
--rand-reneg has executed one time. (Although, I expect only --reneg-sec
has such a specific issue)

my2c



--
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

On 05/04/17 14:36, Simon Matter wrote:
>> 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.
> 
> As I understand it client and server have 60 min. by default. Whatever is
> configured, the smaller value wins. That means, bad clients can set their
> reneg-sec to very low values and trash the server on the other end. From
> the server side this looks more or less like a DDOS.

That's possible today as well  so I don't fully follow why this is
interesting in regards to the randomness or push-ability of --reneg-sec.

This can be pulled much further.  If you have an OpenVPN server on TCP,
even that is susceptible to D/DoS attacks too, where even
--tls-{auth,crypt} won't protect you.  For UDP, --tls-{auth,crypt} does
provide a nice barrier - unless the attacker(s) have access to that.
There's not even a need to complete the full TLS negotiation.

The point is, if I ever wanted to D/DoS an OpenVPN server, I'd partially
implement the OpenVPN protocol in an attack tool to start and perhaps
complete the TLS handshake just to start over again.  This would be far
more efficient than to use OpenVPN itself.  This can be multi-thread,
kicking off thousands of connections in parallel, and then deploy that
on a variety of VMs around the world.  Have 64 such VMs initiating 1024
TCP connections each to any TCP based server in a loop - and the port
pool on the server is exhausted.

So I doubt any reasonable client would really knowingly set
 --reneg-sec 1 just for the bloody fun of it.  The tunnel would be close
to useless.  Unless you're a clueless, bored script kiddie with no
imagination (yes, I know, there's plenty of them too).

As a mitigation to such attacks, it is possible to deploy some firewall
rules (see the iptables recent module for example) to restrict how often
IP address may initiate connections to the server.

Bottom line is ... I don't see D/DoS being a real issue, especially not
in regards to --reneg-sec.

> In our environment we have set reneg-sec=0 on all clients because we want
> the server to have control over it. That's fine because we have only
> trusted clients. Making it pushable could be a solution to overwrite bad
> settings in clients.

Yes, I think this makes sense.  If the client don't want it - it is
possible to deploy a --pull-filter in the local client configuration.

> A more radical solution was to 

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> 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.

As I understand it client and server have 60 min. by default. Whatever is
configured, the smaller value wins. That means, bad clients can set their
reneg-sec to very low values and trash the server on the other end. From
the server side this looks more or less like a DDOS.

In our environment we have set reneg-sec=0 on all clients because we want
the server to have control over it. That's fine because we have only
trusted clients. Making it pushable could be a solution to overwrite bad
settings in clients. A more radical solution was to just remove the option
on the client side.

Regards,
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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[David Sommerseth]

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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Steffan Karger]

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.)

-Steffan



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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Gert Doering]

Hi,

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?

gert


-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP 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

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

>> Hi,
>>
>> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
>>> Interesting to see that there is zero interest in this patch here.
>>
>> This is a misinterpretation.
>>
>
> Hi Gert,
>
> Thanks for the explanation, I'll be patient then :)
>
> If it's preferred for the patch to keep it even simpler and compatible the
> current configs, it could be broken down to something like this in init.c:

I've attached v2 now which works without any config change:

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

Note that the effective value used here is a per session pseudo-
randomized 25% of n deducted from n.  With the default value  of
3600 this results in an effective per session value in the range
of 2701 ... 3600 seconds.


I prefer this version as it allows everybody to profit from it without
touching any config files.

Thanks,
Simon

openvpn-2.4.1-reneg-sec_randomize.patch
Description: Binary data
--
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