[I2nsf] Let's try to draw closure for sdn-ipsec-flow-protection ( RE: Reviewing sdn-ipsec-flow-protection

[Linda Dunbar <[e-mail]>]

Gabriel and Rafa,

What you suggested in this email are all valid options:

·        NSF could provide them by itself during the NSF’s registration process into the controller.

·        the controller receives the capabilities for a set of NSFs from an external entity.

·        IPsec-based NSFs can consider the usage of the capabilities model to inform the security controller about IPsec capabilities.

Can you update the draft before IETF104 (March 11)? So we can start the WG LC during IETF104.
During IETF103, authors of draft-carrel-ipsecme-controller-ike stated that 3rd case (Controller-IKE) should be added to the document. SDWAN depends on the Controller based IKE to scale.
Since draft-carrel-ipsecme-controller-ike has detailed description for Controll-IKE, you only need to simply add a brief description as presented by David and refer to their draft for details.
Something like:

Case 3: Controller-IKE
Controller-IKE is DH based key exchange done through the controller with following characteristics:

¾    All peers send their DH public value to the controller

¾    Controller sends the list of all public values to all peers

¾    All peers calculate a unique pairwise secret for each other peer

¾    No peer-to-peer messages.

Re-keys mechanism is further described in draft-carrel-ipsecme-controller-ike

-----
Because of SDWAN getting more importance for enterprises to reach cloud DCs, scaling IPsec becomes very critical.
Recently, there are multiple initiatives in Routing Area for SD-WAN, all of them need IPsec:
draft-sajassi-bess-secure-evpn
draft-rosen-bess-secure-l3vpn
draft-ietf-rtgwg-net2cloud-problem-statement
draft-ietf-rtgwg-net2cloud-gap-analysis
It will be better if we can smooth out the IPsec scaling solution, and telling routing area not to re-invent the wheel.


Please let us know if you need help in editing the draft to bring it to WGLC.

Linda & Yoav


From: I2nsf [mailto:[e-mail]] On Behalf Of Gabriel Lopez
Sent: Thursday, January 24, 2019 8:24 AM
To: Rafa Marin Lopez <[e-mail]>
Cc: [e-mail]; Fernando Pereñíguez García <[e-mail]>; Gabriel Lopez <[e-mail]>; Yoav Nir <[e-mail]>
Subject: Re: [I2nsf] Reviewing sdn-ipsec-flow-protection

Hi all.


El 14 nov 2018, a las 10:30, Rafa Marin-Lopez <[e-mail]<mailto:[e-mail]>> escribió:

Hi Yoav:


El 8 nov 2018, a las 17:11, Yoav Nir <[e-mail]<mailto:[e-mail]>> escribió:

Hi, all





  *   The interaction between Controller and NSF

     *   There’s no way for the controller to retrieve NSF capabilities. What if the NSF does not implement rc5?  It’s fine if we say that the Controller knows in advance what the capabilities of each NSF are, but it should be stated.

Agree. Nevertheless, I would say that the most correct way is when the controller asks the NSF about capabilities after NSF and controller connect.


Regarding this question, we wonder how the controller knows about the capabilities provided by each IPsec NSF. As Rafa pointed out, one way is that the NSF could provide them by itself during the NSF’s registration process into the controller. Another way is that the controller receives the capabilities for a set of NSFs from an external entity. Following the I2NSF Reference Model in RFC 8329, it is assumed this role is assigned to the “Developer’s Management System”.

In our concrete example where a NSF provides IPsec-based security functions, our understanding of that IPsec capabilities refer the set of features a IPsec NSF node is able to support. A (non-exhaustive) list is:
-           IKE support
-           IKEless support
-           For IKE case: authentication and encryption algorithms, dh_groups, authentication method, NAT traversal support, etc.
-           For IKEless case: authentication, integrity and encryption algorithms, AH support, etc.

We would like to draw attention to IPsec-based NSFs and suggest authors of these drafts to consider the usage of the capabilities model to inform the security controller about IPsec capabilities.

Thanks in advance and best regards, Gabi.




_______________________________________________
I2nsf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/i2nsf

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: [phone]
Fax: [phone]
email: [e-mail]<mailto:[e-mail]>