Hi Tero: > El 4 jun 2019, a las 11:40, Tero Kivinen <[email protected]> escribió: > > 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.
[Authors] Then you propose to keep initial-contact, don’t you? > >> 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. [Authors] So let’s keep the initial-contact node? > >> 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 >> >> <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. [Agree] Agree. From your answer we understand that we should have a notification for that anyway. We think that “expire" notification should be enough. Best Regards and thank you for your answers. > > 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] <mailto:[email protected]> ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] -------------------------------------------------------
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
