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 -0000 1.85 > +++ sbin/iked/iked.conf.5 2 Aug 2021 21:41:55 -0000 > @@ -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_SECONDS 10800 /* 3 hours */ > > #define IKED_E 0x1000 /* Decrypted flag */ >
