Subject: Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

From: Tero Kivinen <[email-masked]>
Date: Sun, 2 Jun 2019 02:13:56 +0300

Paul Wouters writes:
> > [Authors] We have observed some implementations (e.g. libreswan)
> > has this variable initial-contact as well in the ipsec.conf. That is
> > why we decide to 
> > keep it. Is it not useful then?
> 
> We added it because sending or not sending it might change te behaviour
> of the other endpoint. libreswan as implementation ignores the payload
> completely, because it has all the known information/state needed.
> Although based on the above new finding of multiple IPsec SA's, this
> might change.
> 
> I guess my point was more to the fact that instructing the NSF to send
> an INITIAL_CONTACT seems to mixup instructions from the SC. If the SC
> says "bring tunnel X to GW Y up", and then later says "bring tunnel Z
> up to GW Y and send INITIAL_CONTACT", it is implicitly sending a message
> to the NSF to bring tunnel X to gateway Y down. Now the NSF and SC might
> be out of sync if the SC wasn't expecting this result.

The reason implementations need a flag for telling whether or not to
send INITIAL_CONTACT notification is that there is no way for
implementation to know whether it is replicated. I.e., if you have
both your laptop and mobile phone making VPN connections to SGW, and
both of them use same identity (for example [email-masked]), you want
to disable sending INITIAL_CONTACT notifications as other wise when
you have your laptop connection up and running and you start your
phone, that will kill the IPsec SA for the laptop, as the phone would
send INITIAL_CONTACT notification. When you disable it by the
configuration then this will not happen.

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. 

> > [Authors] This is an interesting question. We must state that, for security reasons, any NSF should have a default DISCARD policy. A NSF restarting should
> > not allow any traffic unless SC says so. In other words, Since the NSF needs information coming from the SC, if that information is not in place yet the
> > safest option is DISCARD action.
> 
> Sure. I think adding some text that says a connection in the "configured
> but not up" state is expceted to drop or hold onto the packets, that
> would make it clear.

Of course the device still needs to configure the IPsec policy so that
device can connect to the security conntroller, and also perhaps add
other holes to the policy that are needed to make that connection
possible (arp, ND, perhaps ntp, etc). 

> >       Use "Configuration of IPsec Security Association (SA). Section 4.4.2.1 in RFC 4301"
> >       To ensure it is clear this is not about an IKE SA. Same on the next line for
> >       "for a particular SA"
> >
> >         leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should
> >       prevent transmission of additional packets on the SA, or whether rollover is permitted."; }
> >
> >       What is the source of this? I thought sequence numbers were never allowed to overflow?
> > 
> > 
> > [Authors] According to RFC 4301 - 4.4.2.1.  Data Items in the SAD:
> > 
> > Sequence Counter Overflow: a flag indicating whether overflow of
> >       the sequence number counter should generate an auditable event and
> >       prevent transmission of additional packets on the SA, or whether
> >       rollover is permitted.  The audit log entry for this event SHOULD
> >       include the SPI value, current date/time, Local Address, Remote
> >       Address, and the selectors from the relevant SAD entry.
> 
> 
> Hmm, I have never heard of this so I should look into it, but I guess it
> means you should have the option for it, but please default it to not
> allow rollover, and it would need to forbid rollover for AEAD's.
> 
> Tero, do you know anything more about this feature? I don't think we
> could ever negotiate it via IKE anyway?

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:

   The AES CCM IV field MUST be eight octets.  The IV MUST be chosen by
   the encryptor in a manner that ensures that the same IV value is used
   only once for a given key.  The encryptor can generate the IV in any
   manner that ensures uniqueness.  Common approaches to IV generation
   include incrementing a counter for each packet and linear feedback
   shift registers (LFSRs).

Anyways, as replay preventation is optional for the receiver, there is
an option for ESP RFC4303 to disable it, and that case it does not
matter whether the sequence number field overflows or not. Because of
this the IPsec architecture document do allow option for wrapping
sequence numbers. Of course if sequence number ever wraps, we do loose
the anti-replay service, but there might be use cases where that does
not matter.

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. 

> >         leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; }
> >
> >       Why cap at 1024? That could be too low for 100gbps connections.
> > 
> > 
> > [Authors] The truth is that RFC 4301 mentions:
> > 
> > Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
> >       used to determine whether an inbound AH or ESP packet is a replay.
> > 
> > So we can replace this with uint64. On the other hand, we have observed with uint16 should be enough in real cases. We can remove the restriction (1024) .
> > what do you think?
> 
> Yes, I think the uint16 is more than enough, as long as you don't mention any cap like 1024.

Actually the RFC4303 says in appendix A2:

             Also, the algorithm described
   below assumes that the window is no greater than 2^31 packets in
   width.)  

so making it uint32, would work for any implementation using algorithm
described in the RFC4303...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Sun, 2 Jun 2019 11:09:24 -0400 (EDT)

> addresses etc does not matter, only the authenticated identities

Sure, but "don't do 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

> offer that option, because it does not allow settign that flag in the

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

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Mon, 3 Jun 2019 12:32:57 +0200

Hi Paul, Tero

>> 
>> “For security reasons, a NSF MUST NOT allow any traffic unless the Security Controller mandates so. In other words, since the NSF needs IPsec information coming from the SC, if that information is not in place yet the safest option is DISCARD (drop) packets."
> 
> I assume there are two types of deployment, "cleartext but encrypt when
> possible" and "encryption mandatory". So I feel the MUST NOT is a bit
> too strong. Perhaps limit it to say "if encryption is mandatory for
> all traffic of an NSF, its default policy MUST be to drop packets to
> prevent cleartext packet leaks".
> 
> But then you also do not need per-tunnel "drop" policies, so the SC does
> not have to instruct the NSF for anything.

[Authors] Indeed the NSF should have this policy without contacting with the SC. The NSF should know beforehand (before SC can say anything to the NSF) that the whole deployment policy will be "cleartext but encrypt when possible” or “encryption mandatory”. We should be able to use our interface to include a default policy "cleartext but encrypt when possible” or "“encryption mandatory” in the NSF’s startup config. In this case, this startup config is not set by the Security Controller but by some other entity during the NSF “bootstrapping" (before it is deployed in the network). This initial startup config would include what Tero mentioned about different policies that allow this NSF to contact the SC once the NSF has been deployed. 

Moreover, we should allow to change between "cleartext but encrypt when possible” and “encryption mandatory” if the administrator requires so. This change could be performed by the SC. Perhaps we could add the following text:

“For security reasons, if encryption is mandatory for all traffic of a NSF, its default policy MUST be to drop (DISCARD) packets to prevent cleartext packet leaks. This default policy MUST be in the startup configuration datastore in the NSF before the NSF contacts with the Security Controller. Moreover, the startup configuration datastore MUST be pre-configured with the required ALLOW policies that allow to communicate the NSF with the Security Controller once the NSF is deployed. This pre-configuration step is not carried out by the Security Controller but by some other entity before the NSF deployment. In this manner, when the NSF reboots, it will always apply first the configuration in the startup configuration before contacting the Security Controller."

> 
>>> 
> 
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> 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-masked]
-------------------------------------------------------

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Mon, 3 Jun 2019 14:15:11 +0200

Hi Tero, Paul:

> El 2 jun 2019, a las 17:09, Paul Wouters <[email-masked]> escribió:
> 

[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?.

> 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"; 
}

> 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.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Jun 2019 12:40:41 +0300

Rafa Marin-Lopez writes:
> [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. 

> 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.

> [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-masked]

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Fri, 7 Jun 2019 10:52:56 +0200

Hi Tero:

> El 4 jun 2019, a las 11:40, Tero Kivinen <[email-masked]> escribió:
> 
> Rafa Marin-Lopez writes:
>> Hi Tero, Paul:
>> 

[Authors] Then you propose to keep initial-contact, don’t you?

> load balancing nodes, or both to the in sgw in use and the hot swap

[Authors] So let’s keep the initial-contact node?
>> 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?
> 

[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.
> [email-masked] <mailto:[email-masked]>