Re: [I2nsf] Éric Vyncke's No Objection on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with COMMENT)

Dear Éric:

Thank you very much for your insight and comments. They are very valuable. Please see our comments inline.

> El 5 nov 2020, a las 9:28, Éric Vyncke via Datatracker <noreply@ietf.org> escribió:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document.
> 
> Please find below one blocking DISCUSS point, some non-blocking COMMENT points,
> and some nits.
> 
> I support Erik Kline's DISCUSS points as well as Ben Kaduk's DISCUSS point
> about vendor-specific.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> == COMMENTS ==
> 
> -- Section 5 --
> Isn't there also the 'load sharing by IPSEC-only NSF' a use case ? Where simple
> ECMP could split traffic to several IPSec-only NSFs configured with the same
> parameters (SADB, SPD, ...) (anti-reply being probably impossible to offer
> though)

[Authors] This is a very interesting question. During the development of this I-D there was no discussion about this use case. The I-D focused on defining an interface to allow configure case 1 (with IKE) and case 2 (with IKE-less). 

In any case, we would like to correctly understand what you are mentioning here. If our understanding is correct the idea is to have, for example, two NSFs (NSF A and NSF B) which have the same IPsec SA configured in both. That would mean the same SPI, traffic selectors, and same symmetric keys, and the same IP addresses that represent the tunnel endpoints, is this correct? 

The traffic may go through NSF -A or NSF-B (we are assuming that NSF-A and NSF-B use tunnel endpoints) due to ECMP to reach NSF-C, which is the NSF in the other network. We were wondering if you had in mind that NSF-A and NSF-B act as a single “virtual” NSF, thus representing with the same tunnel endpoint in the IPsec SA so that NSF-C believes that tunnel endpoint is common to NSF-A and NSF-B (actually NSF-C does not distinguish between NSF-A or NSF-B). We assume this since you mention that IPsec SAs and policies are exactly the same  in NSF-A and NSF-B. So in the end, the NSF-C has only two IPsec SAs: one for the inbound traffic and another for the outbound traffic. In such a case, we agree with you that anti-replay must be deactivated since the sequence numbers in the NSF-A and NSF-B are not synchronized and NSF-C may see this as replay and drop the packets. 

Option 1:

                             -> NSF-A ------|
Network 1       ----+                       +------------IPsec tunnel-----------NSF-C---- Network 2
                             -> NSF-B-------|

Another alternative that you may have considered is that, actually, there are two tunnels , one between NSF-A and NSF-C and another one between NSF-B and NSF-C, and therefore they are different IPsec SAs (different SPIs, symmetric keys, endpoint tunnel). Something like:

Option 2:

                     -> NSF-A ------|--------------------------------------------|
Network 1       ----+                                                           NSF-C---- Network 2
                     -> NSF-B-------|--------------------------------------------|

Either way, if something similar to these options is what you had in mind, we believe that it is possible to configure it in case 2 (IKE-less). For option 1, the programming in the I2NSF controller for this use case should consider NSF-A and NSF-B as a cluster of NSFs (a “virtual” NSF made up of two “physical” NSFs) and configure same IPsec SAs and policies in both NSF-A and B. Also, it should also react to a notification coming from NSF-A or NSF-B as a notification coming from the virtual NSF, e.g., a rekey coming from the virtual NSF. For option 2, it is simpler because the controller only needs to keep two different IPsec SAs.

In our opinion, it is undoubtedly an interesting use case but since it was not analyzed during I2NSF discussion we would not dare to include it without further discussion. Having said this, we believe we could write a personal I-D explaining this use case. In our opinion, our current I-D has the pieces required to carry out this scenario.

> 
> -- Section 6 --
> It seems that this section sometimes uses the term 'model' instead of 'module’.

[Authors] It is true that we use both. In RFC 7950 abstract, it seems to refer to model to the “data model” while module is referring to “YANG module”. In fact, RFC 7950 mentions:

“ YANG data models are defined in modules.  A module contains a collection of related definitions.

In any case, we will revise the text so that we use model when we are referring to data model. 

> 
> -- Section 6.1 --
> I would have preferred to use 'local-prefix' rather than 'local-subnet' as the
> latter is old looking IPv4 subnet.

[Authors] Ok, no problem . We will change this.

> 
> The "state" part does not seem to contain the current state of the IKE finite
> state machine, is it on purpose ?

[Authors] Yes, it is. With case 1 (IKE in the NSF) the design is thought as the I2NSF controller sends the configuration and leaves IKE to do its operation, simplifying the I2NSF controller operation. We did not feel from the discussions in the I2NSF WG the need of adding the data about IKE state machine. 

> 
> -- Section 8.2 --
> As IKEv2 provides "perfect forward secrecy" should this section mandating the
> use of a secure channel between SDN and the NSF also with "perfect forward
> secrecy" and same reasoning for the encryption algorithms of course.

[Authors] Yes, you’re correct. We could add the following text in section 8.2

“The security association between the I2NSF Controller and the NSFs MUST provide, at least, the same degree of protection as the one achieved by the IPsec SAs configured in the NSFs. In particular, the security association between the I2NSF Controller and the NSFs MUST provide forward secrecy if this property is to be achieved in the IPsec SAs that the I2NSF Controller configures in the NSFs. Similarly, the encryption algorithms used in the security association between I2NSF Controller and the NSF MUST have, at least, the same strength as the algorithms used to establish the IPsec SAs.”

Is this reasonable?

Best Regards.

> 
> 
> 
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> 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: rafa@um.es
-------------------------------------------------------