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

[Linda Dunbar <[e-mail]>]

Rafa,

Thanks. What you suggested is good to me.
If there is no objection from the WG, we can call WGLC after IETF104.

Linda
From: Rafa Marin-Lopez [mailto:[e-mail]]
Sent: Friday, March 01, 2019 4:49 AM
To: Linda Dunbar <[e-mail]>
Cc: Rafa Marin-Lopez <[e-mail]>; Gabriel Lopez <[e-mail]>; [e-mail]; Fernando Pereñíguez García <[e-mail]>; Yoav Nir <[e-mail]>
Subject: Re: [I2nsf] Let's try to draw closure for sdn-ipsec-flow-protection ( RE: Reviewing sdn-ipsec-flow-protection

Hi Linda, Yoav:

Thank you for e-mail, some comments inline.

El 27 feb 2019, a las 21:35, Linda Dunbar <[e-mail]<mailto:[e-mail]>> escribió:

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.

We will include these options.

Can you update the draft before IETF104 (March 11)? So we can start the WG LC during IETF104.

Yes, we are working with that, applying all the comments we received from Paul, Yoav and you. We will upload a new version in March 11.


During IETF103, authors of draft-carrel-ipsecme-controller-ike stated that 3rd case (Controller-IKE) should be added to the document.

We thought it was still an open debate. In fact, I mentioned in the last meeting that between case 1 and case 3, I would prefer case 1 (IKE case) since as I said ( minute 1:05:03) I do not see any advantage provided by Controller-IKE. Any feature included in Controller-IKE is already in case 1. Therefore, the question about what are the advantages of Controller-IKE vs case 1 has not been answered yet, in my humble opinion.

Also it is still debatable that case 2 (now IKE-less case) does not scale.  The reason is the following: regardless we are talking about IPsec management or not, if we look to SDN world, the scalability is, in general, an issue. But there are also literature providing solutions for scalability. In fact, IKE-less case operates similarly to Openflow-based SDN networks and there are  solutions for that.

SDWAN depends on the Controller based IKE to scale.

I think that SDWAN needs a solution that allows to scale but it does not mean it has to be Controller-IKE, no?


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

Just a clarification, there is no case 1 or 2 now. We have IKE case or IKE-less case. Having said that, our idea to accomplish this request is to add text in the comparison about IKE case and IKE-less case. In fact, we have now :

“On the contrary, the overload of creating fresh IPsec SAs is shifted to
   the Security Controller since IKEv2 is not in the NSF. As a
   consequence, this may result in a more complex implementation in the
   controller side.”

We can add the following:

“This overload may create some scalability issues when the number of NSFs is high. In general, literature around SDN-based network management using a centralized SDN controller is aware about scalability issues and solutions have been already provided (e.g. hierarchical SDN controllers; having multiple replicated SDN controllers...). In the context of IPsec management, one straight way to reduce the overhead and the potential scalability issue in the Security Controller is to apply "IKE case”, described in this document, since the IPsec SAs are managed between NSFs without the involvement of the Security Controller at all, except by the initial IKE configuration provided by the Security Controller. Other solutions, such as Controller-IKE <draft-carrel-ipsecme-controller-ike>, have proposed that NSFs provide their DH public keys to the Security Controller, so that the Security Controller distributes all public keys to all peers. All peers can calculate a unique pairwise secret for each other peer and there is no inter-NSF messages. A re-key mechanism is further described in <draft-carrel-ipsecme-controller-ike>.”

Does it sound reasonable?


-----
Because of SDWAN getting more importance for enterprises to reach cloud DCs, scaling IPsec becomes very critical.

Yes, scaling is critical of any SDN solution, regardless whether is IPsec or not. For example, how openflow-based networks solve scalability issues.


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.

Thank you very much for these references.



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

Sure. We are doing the work now and we will be ready for March 11.

Best Regards.



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]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Fernando Pereñíguez García <[e-mail]<mailto:[e-mail]>>; Gabriel Lopez <[e-mail]<mailto:[e-mail]>>; Yoav Nir <[e-mail]<mailto:[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]<tel:+34%20868888504>
Fax: [phone]<tel:+34%20868884151>
email: [e-mail]<mailto:[e-mail]>



<Controller IKE case 2.pdf>_______________________________________________
I2nsf mailing list
[e-mail]<mailto:[e-mail]>
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: [phone] Fax: [phone] e-mail: [e-mail]<mailto:[e-mail]>
-------------------------------------------------------