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?.
Moreover the Security Controller is the one providing this identity to the NSFs
so I think this case would not be possible, would it?.
>
>> 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.
leaf iv {
nacm:default-deny-all;
type yang:hex-string;
description
"ESP encryption IV value";
}
>
>> 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.
[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?
We have also observed several types of overflow: xfrm_replay_overflow_bmp (not
sure about the purpose of this, any clarification?), xfrm_replay_overflow_esn,
xfrm_replay_overflow
if that is the case, we should include that notification in the model for
IKE-less case so that the Security Controller is aware of this situation.
However, wouldn't it be enough to use the number of packets lifetime instead of
having this new threshold (in xfrm we have seen replay_maxdiff and
replay_maxage as such as threshold).
Best Regards.
>
> Paul
>
> _______________________________________________
> I2nsf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2nsf
-------------------------------------------------------
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
