> On 3 Aug 2021, at 04:22, Theo de Raadt <dera...@openbsd.org> wrote: > > Joerg Sonnenberger <jo...@bec.de> 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 -0000 1.43 >>> +++ sbin/iked/types.h 2 Aug 2021 21:41:55 -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 1073741824 /* 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.
