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" :)
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
When using IKEv2, we do not negotiate anti-replay service, it is always assumed to be local matter on the receiver, thus there is no need for two peers to agreee on that. On the other hand if anybody would want to disable anti-replay, and use non-extended sequence numbers, and allow sequence numbers to wrap, then the IKEv2 does not offer that option, because it does not allow settign that flag in the SAD.
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. Paul _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
