Rafa Marin-Lopez writes: > Hi Tero, Paul: > > El 2 jun 2019, a las 17:09, Paul Wouters <[email protected]> escribió: > > On Sun, 2 Jun 2019, Tero Kivinen wrote: > > I.e., if you have separate connections that share same authenticated > identity then you need to disable INITIAL_CONTACT notifications. Also > note that INITIAL_CONTACT is between identities, IP addresses, inner > addresses etc does not matter, only the authenticated identities > matter. > > Sure, but "don't do that" :) > > [Authors] Taking into account that road-warrior case is not considered in the > I-D (only host-to-host and gw-to-gw) and Paul’s comment I think we can safely > remove the leaf initial-contact, correct?.
The same setting is also used in case there is replicated setups, i.e., every case where you might have two nodes sharing identity and authentication information. Load balancing, hotswap setups, replicated servers etc quite often also want to make sure they set this setting on. Those cases might be in scope for i2nsf too. > Moreover the Security Controller is the one providing this identity to the > NSFs so I think this case would not be possible, would it?. It depends. Security controller might provide same identity to both load balancing nodes, or both to the in sgw in use and the hot swap replicated version. > Note, that AEAD counter is not in the sequence number field, it is in > the IV field, and every AEAD cipher RFC has text which requires that > IV field is generated in a way that ensures uniqueness. From RFC4309: > > For now, but there are drafts going around that want to re-use the > fields to save a few bytes :P > > [Authors] Our model allows the Security Controller to set the IV in > the SAD in the IKE-less case. IV is per packet information, SC cannot really provide it. It can provide initial value for it, but the updating of it must be done in node. > Well, the IKEv2 endpoint that cares about this can just re-key or > re-auth in time before reaching those counters. So yes, it does not > need to be negotiated but it is the IKEv2 daemon handling this. So for > the IKE-less case, I guess it should be there, although this is similar > to the IKE-less case handling maxbytes, maxlife, maxidle counters. I > think it is expected that the NSF sends the kernel message (pfkey, > acquire) to the SC. So it could be avoided in the IKEless case than too. > > [Authors] We have a doubt here: if the IKEv2 endpoint that cares about this > performs the re-key or re-auth, it needs to know when this event happens. I > guess IKEv2 implementation would be expecting a notification from the kernel > like xfrm_replay_notify(struct xfrm_state *x, int event) when a > xfrm_replay_overflow happens (see for example : > ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.10.14/net/xfrm/xfrm_replay.c > ) > > is this correct? IKEv2 will register suitable triggers to kernel, and kernel will then use suitable method to notify IKEv2 when those timers, counters etc are expiring. Not sure what those xfrm things do, as those are not part of standard, but are internal implementation details for one specific implementation. Usually IKEv2 will set packet counter triggers that will expire way before the actual overflow happens, so it has time to rekey before the hard expiration happens. -- [email protected] _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
