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).
> 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.
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.
> 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.
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)
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).
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.
--Sowmini
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
