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 -0000 1.43 +++ types.h 3 Aug 2021 11:35:26 -0000 @@ -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_SECONDS 10800 /* 3 hours */ #define IKED_E 0x1000 /* Decrypted flag */
