Re: iked(8): Increase the default Child SA data lifetime limit
On 2021/08/03 17:02, Vitaliy Makkoveev wrote: > > - a 50% lower limit feels too low to me > > > > Why? The 95% limit is too close to lifetime expiration and as it was > exposed we don't have enough time to perform rekeying. I also had this > problem while tested iked(8) over WIFI connection and this is one of > real-world usage cases. Rekeying with 9-18 minutes spare out of a 180 minute lifetime seems pretty good to me. Rekeying with 72-90 minutes left of a 180 minute lifetime seems way too early. For bytes, if 10% of the byte lifetime isn't long enough to complete a rekey, that really suggests to me the lifetime is set too low, not that the jitter amount is too low.
Re: iked(8): Increase the default Child SA data lifetime limit
On Mon, Aug 02, 2021 at 09:09:03PM -0600, Theo de Raadt wrote: > > I suspect the first step is to make the rekey decision be based upon the > strength of the ciphers. > Do you mean the special default limits for each cipher?
Re: iked(8): Increase the default Child SA data lifetime limit
On Tue, Aug 03, 2021 at 12:17:38PM +0100, Stuart Henderson wrote: > On 2021/08/03 01:12, Vitaliy Makkoveev wrote: > > iked(8) uses 3 hours and 512 megabytes of processed data as default > > lifetime hard limits for Child SA. Also it sets 85-95% of these values as > > soft limit. iked(8) should perform rekeying before we reach hard limit > > otherwise this SA will be killed and the tunnel stopped. With default > > values the window is only 25-52 megabytes and we easily consume them > > before rekeying and the tunnel stops. > > > > Hrvoje Popovski complained about such stops when he has tested ipsec(4) > > related diffs. I also tried iked(8) with my macos and found that simple > > "ping -f ..." makes rekeying impossible. > > > > The hard limit could be modified in iked.conf(5) by setting "lifetime > > xxx bytes yyy", but the 5% difference between hard and soft limits forces > > to set bytes limit big enough, about 4G and more, which could be bad for > > security reason. > > > > I propose to increase the default hard limit at least up to 1G. Also I > > propose to decrease the soft limit down to 50-60% of hard limit. This > > keeps the rekeying frequency but increases the update window to 410-512 > > megabytes. Also this allow to keep bytes in "lifetime" setting small > > enough. > > I have a couple of comments; > > - this isn't a problem I've run into with real-world usage or when > running tcpbench over (moderately fast) internet connections - I'm not > saying it doesn't happen, but it seems relatively uncommon, with > connections at LAN speeds of course it's much more likely > > - a 50% lower limit feels too low to me > Why? The 95% limit is too close to lifetime expiration and as it was exposed we don't have enough time to perform rekeying. I also had this problem while tested iked(8) over WIFI connection and this is one of real-world usage cases. > - your jitter change affects lifetime both in seconds and in bytes, > I think changing the jitter for the seconds lifetime is a mistake > > - the jitter change could result in some really short rekey intervals > if somebody has manually specified lifetimes which are the same as or less > than the current default > The original code permits you to set "lifetime 1 bytes 1" in iked.conf(5) so you could have SA with hard lifetime 1 second and 1 byte and soft lifetime with 0 seconds (disabled) and 0 bytes (disabled) limit. You could successfully connect but rekeying will never happened. Is this iked(8) problem or the wrong iked(8) setup problem? Who should solve it (for example, print error message and don't startup)? > - looking at other IKEv2 implementations: if bytes lifetime is supported > at all (several implementations don't have it, only time-based lifetime), > the default settings rarely seem to use it > > - 512MB is not really a lot of data > As I said, 410-512Mb limit was chosen because the "lifetime 3h bytes 4G" pretty works with original iked(8) 95% jitter. At least for me and Hrvoje. 95% jitter with 4G limit provides us 205Mb for rekeying.
Re: iked(8): Increase the default Child SA data lifetime limit
On Tue, Aug 03, 2021 at 01:40:51PM +0200, Tobias Heider wrote: > On Tue, Aug 03, 2021 at 12:17:38PM +0100, Stuart Henderson wrote: > > On 2021/08/03 01:12, Vitaliy Makkoveev wrote: > > > iked(8) uses 3 hours and 512 megabytes of processed data as default > > > lifetime hard limits for Child SA. Also it sets 85-95% of these values as > > > soft limit. iked(8) should perform rekeying before we reach hard limit > > > otherwise this SA will be killed and the tunnel stopped. With default > > > values the window is only 25-52 megabytes and we easily consume them > > > before rekeying and the tunnel stops. > > > > > > Hrvoje Popovski complained about such stops when he has tested ipsec(4) > > > related diffs. I also tried iked(8) with my macos and found that simple > > > "ping -f ..." makes rekeying impossible. > > > > > > The hard limit could be modified in iked.conf(5) by setting "lifetime > > > xxx bytes yyy", but the 5% difference between hard and soft limits forces > > > to set bytes limit big enough, about 4G and more, which could be bad for > > > security reason. > > > > > > I propose to increase the default hard limit at least up to 1G. Also I > > > propose to decrease the soft limit down to 50-60% of hard limit. This > > > keeps the rekeying frequency but increases the update window to 410-512 > > > megabytes. Also this allow to keep bytes in "lifetime" setting small > > > enough. > > > > I have a couple of comments; > > > > - this isn't a problem I've run into with real-world usage or when > > running tcpbench over (moderately fast) internet connections - I'm not > > saying it doesn't happen, but it seems relatively uncommon, with > > connections at LAN speeds of course it's much more likely > > > > - a 50% lower limit feels too low to me > > > > - your jitter change affects lifetime both in seconds and in bytes, > > I think changing the jitter for the seconds lifetime is a mistake > > > > - the jitter change could result in some really short rekey intervals > > if somebody has manually specified lifetimes which are the same as or less > > than the current default > > > > - looking at other IKEv2 implementations: if bytes lifetime is supported > > at all (several implementations don't have it, only time-based lifetime), > > the default settings rarely seem to use it > > > > - 512MB is not really a lot of data > > > > My first though now I know about this problem is just to increase the > > default byte limit and leave the jitter range as-is. I don't know enough > > about the security requirements of IKEv2 to know what demands it places > > on rekeying, but given the above (especially that other implementations > > mostly don't use byte limits at all), the figure I'd pull out of the air > > would be more like 4GB. > > > > I agree with Stuart here. In my experience raising the limit to 4 GB is enough > to solve the problem and the current jitter works well enough. > > In a next step we can think about relaxing the limits even further for "safe" > algorithms like Theo proposed, but this would need a bit more work. > > FWIW here's a diff I sent to bluhm a few weeks ago. We didn't commit it yet > because the low limit helped us find and reproduce a PMTU bug (that should > be gone now). > As I said, I tested the iked(8) tunnels with "lifetime 3h bytes 4G" in my iked.conf(5) and the problem disappeared. With this case 95% jitter provides ~205 megabytes window for rekeying and this is pretty enough. Hrvoje also tested his setup with "lifetime 3h bytes 4G" and didn't hit the problem. So I decided the 410 megabytes window is pretty enough as default. Raising the bytes default limit to 4G is ok by me, but you forget to modify iked.conf(5) man page: lifetime time [bytes bytes] The optional lifetime parameter defines the Child SA expiration timeout by the time SA was in use and by the number of bytes that were processed using the SA. Default values are 3 hours and 512... > Index: types.h > === > RCS file: /cvs/src/sbin/iked/types.h,v > retrieving revision 1.43 > diff -u -p -r1.43 types.h > --- types.h 13 May 2021 15:20:48 - 1.43 > +++ types.h 3 Aug 2021 11:35:26 - > @@ -67,7 +67,7 @@ > #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ > #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ > > -#define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */ > +#define IKED_LIFETIME_BYTES 4294967296 /* 4 GB */ > #define IKED_LIFETIME_SECONDS10800 /* 3 hours */ > > #define IKED_E 0x1000 /* Decrypted flag */
Re: iked(8): Increase the default Child SA data lifetime limit
Am Tue, Aug 03, 2021 at 01:40:51PM +0200 schrieb Tobias Heider: > On Tue, Aug 03, 2021 at 12:17:38PM +0100, Stuart Henderson wrote: > > On 2021/08/03 01:12, Vitaliy Makkoveev wrote: > > > iked(8) uses 3 hours and 512 megabytes of processed data as default > > > lifetime hard limits for Child SA. Also it sets 85-95% of these values as > > > soft limit. iked(8) should perform rekeying before we reach hard limit > > > otherwise this SA will be killed and the tunnel stopped. With default > > > values the window is only 25-52 megabytes and we easily consume them > > > before rekeying and the tunnel stops. > > > > > > Hrvoje Popovski complained about such stops when he has tested ipsec(4) > > > related diffs. I also tried iked(8) with my macos and found that simple > > > "ping -f ..." makes rekeying impossible. > > > > > > The hard limit could be modified in iked.conf(5) by setting "lifetime > > > xxx bytes yyy", but the 5% difference between hard and soft limits forces > > > to set bytes limit big enough, about 4G and more, which could be bad for > > > security reason. > > > > > > I propose to increase the default hard limit at least up to 1G. Also I > > > propose to decrease the soft limit down to 50-60% of hard limit. This > > > keeps the rekeying frequency but increases the update window to 410-512 > > > megabytes. Also this allow to keep bytes in "lifetime" setting small > > > enough. > > > > I have a couple of comments; > > > > - this isn't a problem I've run into with real-world usage or when > > running tcpbench over (moderately fast) internet connections - I'm not > > saying it doesn't happen, but it seems relatively uncommon, with > > connections at LAN speeds of course it's much more likely > > > > - a 50% lower limit feels too low to me > > > > - your jitter change affects lifetime both in seconds and in bytes, > > I think changing the jitter for the seconds lifetime is a mistake > > > > - the jitter change could result in some really short rekey intervals > > if somebody has manually specified lifetimes which are the same as or less > > than the current default > > > > - looking at other IKEv2 implementations: if bytes lifetime is supported > > at all (several implementations don't have it, only time-based lifetime), > > the default settings rarely seem to use it > > > > - 512MB is not really a lot of data > > > > My first though now I know about this problem is just to increase the > > default byte limit and leave the jitter range as-is. I don't know enough > > about the security requirements of IKEv2 to know what demands it places > > on rekeying, but given the above (especially that other implementations > > mostly don't use byte limits at all), the figure I'd pull out of the air > > would be more like 4GB. > > > > I agree with Stuart here. In my experience raising the limit to 4 GB is enough > to solve the problem and the current jitter works well enough. > > In a next step we can think about relaxing the limits even further for "safe" > algorithms like Theo proposed, but this would need a bit more work. > > FWIW here's a diff I sent to bluhm a few weeks ago. We didn't commit it yet > because the low limit helped us find and reproduce a PMTU bug (that should > be gone now). ok patrick@ > Index: types.h > === > RCS file: /cvs/src/sbin/iked/types.h,v > retrieving revision 1.43 > diff -u -p -r1.43 types.h > --- types.h 13 May 2021 15:20:48 - 1.43 > +++ types.h 3 Aug 2021 11:35:26 - > @@ -67,7 +67,7 @@ > #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ > #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ > > -#define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */ > +#define IKED_LIFETIME_BYTES 4294967296 /* 4 GB */ > #define IKED_LIFETIME_SECONDS10800 /* 3 hours */ > > #define IKED_E 0x1000 /* Decrypted flag */ >
Re: iked(8): Increase the default Child SA data lifetime limit
On Tue, Aug 03, 2021 at 12:17:38PM +0100, Stuart Henderson wrote: > On 2021/08/03 01:12, Vitaliy Makkoveev wrote: > > iked(8) uses 3 hours and 512 megabytes of processed data as default > > lifetime hard limits for Child SA. Also it sets 85-95% of these values as > > soft limit. iked(8) should perform rekeying before we reach hard limit > > otherwise this SA will be killed and the tunnel stopped. With default > > values the window is only 25-52 megabytes and we easily consume them > > before rekeying and the tunnel stops. > > > > Hrvoje Popovski complained about such stops when he has tested ipsec(4) > > related diffs. I also tried iked(8) with my macos and found that simple > > "ping -f ..." makes rekeying impossible. > > > > The hard limit could be modified in iked.conf(5) by setting "lifetime > > xxx bytes yyy", but the 5% difference between hard and soft limits forces > > to set bytes limit big enough, about 4G and more, which could be bad for > > security reason. > > > > I propose to increase the default hard limit at least up to 1G. Also I > > propose to decrease the soft limit down to 50-60% of hard limit. This > > keeps the rekeying frequency but increases the update window to 410-512 > > megabytes. Also this allow to keep bytes in "lifetime" setting small > > enough. > > I have a couple of comments; > > - this isn't a problem I've run into with real-world usage or when > running tcpbench over (moderately fast) internet connections - I'm not > saying it doesn't happen, but it seems relatively uncommon, with > connections at LAN speeds of course it's much more likely > > - a 50% lower limit feels too low to me > > - your jitter change affects lifetime both in seconds and in bytes, > I think changing the jitter for the seconds lifetime is a mistake > > - the jitter change could result in some really short rekey intervals > if somebody has manually specified lifetimes which are the same as or less > than the current default > > - looking at other IKEv2 implementations: if bytes lifetime is supported > at all (several implementations don't have it, only time-based lifetime), > the default settings rarely seem to use it > > - 512MB is not really a lot of data > > My first though now I know about this problem is just to increase the > default byte limit and leave the jitter range as-is. I don't know enough > about the security requirements of IKEv2 to know what demands it places > on rekeying, but given the above (especially that other implementations > mostly don't use byte limits at all), the figure I'd pull out of the air > would be more like 4GB. > I agree with Stuart here. In my experience raising the limit to 4 GB is enough to solve the problem and the current jitter works well enough. In a next step we can think about relaxing the limits even further for "safe" algorithms like Theo proposed, but this would need a bit more work. FWIW here's a diff I sent to bluhm a few weeks ago. We didn't commit it yet because the low limit helped us find and reproduce a PMTU bug (that should be gone now). Index: types.h === RCS file: /cvs/src/sbin/iked/types.h,v retrieving revision 1.43 diff -u -p -r1.43 types.h --- types.h 13 May 2021 15:20:48 - 1.43 +++ types.h 3 Aug 2021 11:35:26 - @@ -67,7 +67,7 @@ #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ -#define IKED_LIFETIME_BYTES536870912 /* 512 Mb */ +#define IKED_LIFETIME_BYTES4294967296 /* 4 GB */ #define IKED_LIFETIME_SECONDS 10800 /* 3 hours */ #define IKED_E 0x1000 /* Decrypted flag */
Re: iked(8): Increase the default Child SA data lifetime limit
On 2021/08/03 01:12, Vitaliy Makkoveev wrote: > iked(8) uses 3 hours and 512 megabytes of processed data as default > lifetime hard limits for Child SA. Also it sets 85-95% of these values as > soft limit. iked(8) should perform rekeying before we reach hard limit > otherwise this SA will be killed and the tunnel stopped. With default > values the window is only 25-52 megabytes and we easily consume them > before rekeying and the tunnel stops. > > Hrvoje Popovski complained about such stops when he has tested ipsec(4) > related diffs. I also tried iked(8) with my macos and found that simple > "ping -f ..." makes rekeying impossible. > > The hard limit could be modified in iked.conf(5) by setting "lifetime > xxx bytes yyy", but the 5% difference between hard and soft limits forces > to set bytes limit big enough, about 4G and more, which could be bad for > security reason. > > I propose to increase the default hard limit at least up to 1G. Also I > propose to decrease the soft limit down to 50-60% of hard limit. This > keeps the rekeying frequency but increases the update window to 410-512 > megabytes. Also this allow to keep bytes in "lifetime" setting small > enough. I have a couple of comments; - this isn't a problem I've run into with real-world usage or when running tcpbench over (moderately fast) internet connections - I'm not saying it doesn't happen, but it seems relatively uncommon, with connections at LAN speeds of course it's much more likely - a 50% lower limit feels too low to me - your jitter change affects lifetime both in seconds and in bytes, I think changing the jitter for the seconds lifetime is a mistake - the jitter change could result in some really short rekey intervals if somebody has manually specified lifetimes which are the same as or less than the current default - looking at other IKEv2 implementations: if bytes lifetime is supported at all (several implementations don't have it, only time-based lifetime), the default settings rarely seem to use it - 512MB is not really a lot of data My first though now I know about this problem is just to increase the default byte limit and leave the jitter range as-is. I don't know enough about the security requirements of IKEv2 to know what demands it places on rekeying, but given the above (especially that other implementations mostly don't use byte limits at all), the figure I'd pull out of the air would be more like 4GB. > Index: sbin/iked/iked.conf.5 > === > RCS file: /cvs/src/sbin/iked/iked.conf.5,v > retrieving revision 1.85 > diff -u -p -r1.85 iked.conf.5 > --- sbin/iked/iked.conf.5 11 Apr 2021 23:27:06 - 1.85 > +++ sbin/iked/iked.conf.5 2 Aug 2021 21:41:55 - > @@ -586,8 +586,8 @@ parameter defines the Child SA expiratio > SA was in use and by the number of > .Ar bytes > that were processed using the SA. > -Default values are 3 hours and 512 megabytes which means that SA will be > -rekeyed before reaching the time limit or 512 megabytes of data > +Default values are 3 hours and 1024 megabytes which means that SA will be > +rekeyed before reaching the time limit or 1024 megabytes of data > will pass through. > Zero values disable rekeying. hm, this doesn't mention jitter. I think it should. Perhaps something like this. Default values are X hours and Y megabytes. Rekeying is initiated at between A% and B% of the limit; if unsuccessful the SA will not be allowed to continue beyond the hard limit. > -#define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */ > +#define IKED_LIFETIME_BYTES 1073741824 /* 512 Mb */ Comment is now wrong. I think I would write this as N * 1024 * 1024 and remove the comment, but if not then the comment needs to match. > #define IKED_LIFETIME_SECONDS10800 /* 3 hours */ > > #define IKED_E 0x1000 /* Decrypted flag */ >
Re: iked(8): Increase the default Child SA data lifetime limit
Vitaliy Makkoveev wrote: > > ssh_packet_need_rekeying() appears to have some nice decisions. The > > idea is to rekey based upon time, primarily. > > It does the same: the two limits and rekying starts when you exceeded > any of them. But in the ssh case we have no massive traffic load, so we > reach time limit first. The ipsec case is opposite. First off, this is not ipsec. This is a iked decision. And thus the iked case is only the opposite of ssh because iked has ludicrously small data limits. I doubt this choice was made purposefully. Correct me if I am wrong about ssh: debug1: rekey in after 134217728 blocks Imagine AES is being used such that blocksize is 16. So ssh will rekey at 2GB data, also note this is a non-datagram model, it is a session that stops such that no traffic is lost. And this 2G is generally the data rekey decision for a flow by _a single user_. But IPSEC is not moving a single user's data! And as a result of this, datagrams get lost. Seems a poor tradeoff to lose packets when turning on crypto. So 2GB is a ludicrous position to take, very much like "the cipher being used is unsafe". Please explain how AES is suddenly this poor. If there are unsafe cipher choices, then those specific unsafe ones should make tighter datasize choices, but the modern ciphers we have are much better so their choices should be huge. I suspect the first step is to make the rekey decision be based upon the strength of the ciphers.
Re: iked(8): Increase the default Child SA data lifetime limit
> On 3 Aug 2021, at 04:22, Theo de Raadt wrote: > > Joerg Sonnenberger wrote: > >> On Tue, Aug 03, 2021 at 01:12:54AM +0300, Vitaliy Makkoveev wrote: >>> Index: sbin/iked/types.h >>> === >>> RCS file: /cvs/src/sbin/iked/types.h,v >>> retrieving revision 1.43 >>> diff -u -p -r1.43 types.h >>> --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 >>> +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - >>> @@ -67,7 +67,7 @@ >>> #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ >>> #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ >>> >>> -#define IKED_LIFETIME_BYTES536870912 /* 512 Mb */ >>> +#define IKED_LIFETIME_BYTES1073741824 /* 512 Mb */ >>> #define IKED_LIFETIME_SECONDS 10800 /* 3 hours */ >>> >>> #define IKED_E 0x1000 /* Decrypted flag */ >>> >> >> Comment and value don't match? Also, isn't 512MB quite low with modern >> crypto algorithms? > > I think the low values are exceedingly cynical, and should be increased > substantially. Which value looks more appropriate here? 1G, 10G? I guess it depends on bandwidth which is different. My main idea is to have the window for rekeying about the half of hard limit. 1G was chosen to keep the original rekeying frequency. Also Hrvoje reported the problem disappeared with unpatched kernel and 4G bytes limit. 95% of 4G is about 205M, so I guess 1G for hard and 410-512M for soft limit is enough as default value. Which could be overridden in iked.conf(5). > > ssh_packet_need_rekeying() appears to have some nice decisions. The > idea is to rekey based upon time, primarily. It does the same: the two limits and rekying starts when you exceeded any of them. But in the ssh case we have no massive traffic load, so we reach time limit first. The ipsec case is opposite.
Re: iked(8): Increase the default Child SA data lifetime limit
Joerg Sonnenberger wrote: > On Tue, Aug 03, 2021 at 01:12:54AM +0300, Vitaliy Makkoveev wrote: > > Index: sbin/iked/types.h > > === > > RCS file: /cvs/src/sbin/iked/types.h,v > > retrieving revision 1.43 > > diff -u -p -r1.43 types.h > > --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 > > +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - > > @@ -67,7 +67,7 @@ > > #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ > > #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ > > > > -#define IKED_LIFETIME_BYTES536870912 /* 512 Mb */ > > +#define IKED_LIFETIME_BYTES1073741824 /* 512 Mb */ > > #define IKED_LIFETIME_SECONDS 10800 /* 3 hours */ > > > > #define IKED_E 0x1000 /* Decrypted flag */ > > > > Comment and value don't match? Also, isn't 512MB quite low with modern > crypto algorithms? I think the low values are exceedingly cynical, and should be increased substantially. ssh_packet_need_rekeying() appears to have some nice decisions. The idea is to rekey based upon time, primarily.
Re: iked(8): Increase the default Child SA data lifetime limit
On Tue, Aug 03, 2021 at 01:12:54AM +0300, Vitaliy Makkoveev wrote: > Index: sbin/iked/types.h > === > RCS file: /cvs/src/sbin/iked/types.h,v > retrieving revision 1.43 > diff -u -p -r1.43 types.h > --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 > +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - > @@ -67,7 +67,7 @@ > #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ > #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ > > -#define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */ > +#define IKED_LIFETIME_BYTES 1073741824 /* 512 Mb */ > #define IKED_LIFETIME_SECONDS10800 /* 3 hours */ > > #define IKED_E 0x1000 /* Decrypted flag */ > Comment and value don't match? Also, isn't 512MB quite low with modern crypto algorithms? Joerg
iked(8): Increase the default Child SA data lifetime limit
iked(8) uses 3 hours and 512 megabytes of processed data as default lifetime hard limits for Child SA. Also it sets 85-95% of these values as soft limit. iked(8) should perform rekeying before we reach hard limit otherwise this SA will be killed and the tunnel stopped. With default values the window is only 25-52 megabytes and we easily consume them before rekeying and the tunnel stops. Hrvoje Popovski complained about such stops when he has tested ipsec(4) related diffs. I also tried iked(8) with my macos and found that simple "ping -f ..." makes rekeying impossible. The hard limit could be modified in iked.conf(5) by setting "lifetime xxx bytes yyy", but the 5% difference between hard and soft limits forces to set bytes limit big enough, about 4G and more, which could be bad for security reason. I propose to increase the default hard limit at least up to 1G. Also I propose to decrease the soft limit down to 50-60% of hard limit. This keeps the rekeying frequency but increases the update window to 410-512 megabytes. Also this allow to keep bytes in "lifetime" setting small enough. Index: sbin/iked/iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.85 diff -u -p -r1.85 iked.conf.5 --- sbin/iked/iked.conf.5 11 Apr 2021 23:27:06 - 1.85 +++ sbin/iked/iked.conf.5 2 Aug 2021 21:41:55 - @@ -586,8 +586,8 @@ parameter defines the Child SA expiratio SA was in use and by the number of .Ar bytes that were processed using the SA. -Default values are 3 hours and 512 megabytes which means that SA will be -rekeyed before reaching the time limit or 512 megabytes of data +Default values are 3 hours and 1024 megabytes which means that SA will be +rekeyed before reaching the time limit or 1024 megabytes of data will pass through. Zero values disable rekeying. .Pp Index: sbin/iked/pfkey.c === RCS file: /cvs/src/sbin/iked/pfkey.c,v retrieving revision 1.77 diff -u -p -r1.77 pfkey.c --- sbin/iked/pfkey.c 2 Mar 2021 03:31:25 - 1.77 +++ sbin/iked/pfkey.c 2 Aug 2021 21:41:55 - @@ -603,8 +603,8 @@ pfkey_sa(int sd, uint8_t satype, uint8_t sa_ltime_soft.sadb_lifetime_exttype = SADB_EXT_LIFETIME_SOFT; sa_ltime_soft.sadb_lifetime_len = sizeof(sa_ltime_soft) / 8; - /* set randomly to 85-95% */ - jitter = 850 + arc4random_uniform(100); + /* set randomly to 50-60% */ + jitter = 500 + arc4random_uniform(100); sa_ltime_soft.sadb_lifetime_bytes = (sa_ltime_hard.sadb_lifetime_bytes * jitter) / 1000; sa_ltime_soft.sadb_lifetime_addtime = Index: sbin/iked/types.h === RCS file: /cvs/src/sbin/iked/types.h,v retrieving revision 1.43 diff -u -p -r1.43 types.h --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - @@ -67,7 +67,7 @@ #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ -#define IKED_LIFETIME_BYTES536870912 /* 512 Mb */ +#define IKED_LIFETIME_BYTES1073741824 /* 512 Mb */ #define IKED_LIFETIME_SECONDS 10800 /* 3 hours */ #define IKED_E 0x1000 /* Decrypted flag */
