Hi Sowmini: Also sorry for the delay, Gabi and I have been preparing the revised I-D.
https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-00 We hope it clarifies some of your questions. In any case, please see inline my comments. > El 30 jun 2016, a las 18:26, Sowmini Varadhan <[email protected]> > escribió: > > > > Hi, sorry for the delay in response, needed some time to go over > the draft carefully. Here are some comments. > >> 1. Introduction > : >> .. In this sense, it will provision the required >> parameters to create valid entries in the Security Association >> Database (SAD), which we assumed to be in the data plane. > > That definition was a bit unusual (at least from a network-stack perspective) > and threw me off. The SAD is security assoction database, thus it is not > "data plane" as such, but rather, a database configured by the > control-plane that is looked up by the network stack's dataplane. > (In the same way, the SPD is also just a security policy database, > so the decision to call one "control plane", while the other as "data plane" > is also quite confusing). [Rafa] To avoid any confusion we have removed the part of “data plane” and "control plane”. We have just explained two cases: Case 1: IKE/IPsec in the NSF Case 2: IPsec (no IKE) in the NSF > >> Therefore, >> the data plane will have only support for IPsec while SPD and IKE >> functionality is moved to the control plane. In both cases, to carry >> out this provisioning, an interface/protocol will be required between >> the SDN controller and the data plane to send: the policies to be > > Again, perhaps my notion of "data plane" does not match the intention, > but the SDN controller has to interface with the control > plane (i.e, the IKE implementation in the network resource) in case 1. [Rafa] As mentioned, we think that removing the concept of “data plane” and “control plane” and focusing on the cases make things clearer. > > Seems to me like case-1 vs case-2 is basically a split-IKE > model (where IKE is split between the network-resource and the controller) > and a model where the network resource implements IPsec only, with > IKE exclusively managed by the controller. [Rafa] Not really. IPsec stack is always in the NSF. As you may know, according to RFC 4301, there are three IPsec databases that needs to be handled: SPD, SAD and PAD. Additionally IKE is just the default automated key management protocol. But IPsec architecture allows other key management protocols. SDN-based key management is a possibility as we show in our I-D. > >> 5. Case 1: IKE/IPsec in the network resource > : >> Advantages: It is simple since network resources typically have and >> IKE/IPsec implementations. >> >> Disadvantages: 1) IKE implementations needs to renegotiate IPsec SAs >> upon SPD entries changes without restarting IKE daemon. 2) Data plane >> more complex. > > How does the data-plane become any more complex than a non-SDN env > where there would be no controller? The only change introduced > by the controller is that the IKE/IPsec SAs and policies are now > orchestrated via the controller. [Rafa] In this case, we were referring to the fact that the gateway does not need to deploy an IKE implementation. This has been stated in the next version of the I-D. > > I do agree that this results in a split-IKE model, which may > need to be thought through. > > >> 6. Case 2: IKE and SPD in the SDN Controller > : >> Advantages: 1) There is clear separation of data plane (IPsec >> protection per flow) and control plane (IKE and SPD policies). >> Hence, it allows less complex data planes. 2) IKE does not need to be >> run in gateway-to-gateway scenario with a single controller (see >> Section 8.1). > > Moving IKE into the controller will result in a fairly complex > controller implementation, making the control plane extremely complex > (we need to now worry about interop, compat with config options > supported by existing IKE impelementations etc) [Rafa] We understand that the current text may lead to some confusion. Actually, IKE may not be implemented in the controller at all. Do we really need to implement IKE in the controller when we have only one controller and the gateways have only the IPsec stack? We don’t think so. The controller just needs to perform key management and distribute key material and information to fill the SPD SAD and PAD. And PAD may not even be required when IKE is not in the NSF. We hope this has been clarified in the new version of the I-D. > > Section 8.1 underlines this somewhat- essentially the controller is now > doing everything that a standard IKE implementation would do. Trying > to get this to work with a stock TCP/IP stack implmentation would be > quite complex (whereas stock TCP/IP stack implementations already > deal correctly with stock IPsec/IKE implementations). [Rafa] I guess you were referring to section 8.2 because in section 8.1 there is no need to have an IKE implementation in the controller. As mentioned, the controller would do just key management, which we believe is not a very demanding task after all (not more than other tasks that the security controller has to do). Even in section 8.2, IKE is considered as potential east/west interface. But, of course, that needs to be discussed. > > There may also be other complications, if the IKE-enabled-controller > has to negotiate IKE on behalf of some other entity (network resource) > with a peer that thinks it is negotiating iwth the network-resource > itself. I dont know if the current IKE specs would have some issues > with that. [Rafa] This what you describe is more related with OLD section 8.3 (OLD Figure 10) and I agree. In fact, we already had this discussion internally with the old version of the I-D. This definitely needs further analysis. In fact, I personally prefer option in Figure 9 for section 8.3 We would like to really thank your comments. We think the new version of the I-D provides a clearer view of our design, more evolved where some of your questions raised here may find an answer. In any case, please let us know what you think now. Best Regards. > > --Sowmini > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafael 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
