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