Subject: Re: [I2nsf] [IPsec] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface?

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 8 Jul 2016 23:57:53 +0200

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-masked]> 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-masked]
> 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-masked]
-------------------------------------------------------

---

From: Sowmini Varadhan <[email-masked]>
Date: Mon, 11 Jul 2016 07:13:17 -0400

On (07/08/16 23:57), Rafa Marin Lopez wrote:
> 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.

    :
>    policies and SAs to handle is high.  With the grow of SDN-based

nit s/grow/growth

>    1)  The network resource (or Network Security Function, NSF)
>        implements the Internet Key Exchange (IKE) protocol and the IPsec
>        databases: the Security Policy Database (SPD), the Security
>        Association Database (SAD) and the Peer Authorization Database
>        (PAD).  The controller is in charge of provisioning the NSF with
>        the required information about IKE, the SPD and the PAD.
> 
>    2)  The NSF only implements the IPsec databases (no IKE
>        implementation).  The controller will provide the required
>        parameters to create valid entries in the PAD, the SPD and the
>        SAD in the NSF.  Therefore, the NSF will have only support for
>        IPsec while automated key management functionality is moved to
>        the controller.

I found the above description a bit confusing - in both cases,
the sad, spd, pad have to be in the NSF, whereas the real distinction
between the 2 cases is based on whether IKE is implemented in the
NSF or in the controller. It might help to make that clearer.

  :
> 5.  Case 1: IKE/IPsec in the NSF
  :
>    Disadvantages: IKE implementations need to renegotiate IPsec SAs upon
>    SPD entries changes without restarting IKE daemon.

but you would need to deal with this even if IKE was implemented
in the controller, right?

> 
> 
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                 |   IPsec Management/Orchestration Application| Client or
>                 |                I2NSF Client                 | App Gateway
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                         |      Client Facing Interface
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     Vendor      |             Application Support             |
>     Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
>     Interface   | IKE Credential and SPD Policies Distribution| Controller
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                         |          NSF Facing Interface
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                 |                 I2NSF Agent                 |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network
>                 |   IKE    |      IPsec(SPD,SAD,PAD)          | Security
>                 +-------------------------------------------- + Function (NSF)
>                 |         Data Protection and Forwarding      |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 

One question about the block diagram above (and also applies to
Case 2)- will the "Security Controller" and NSF both use the same
src IP address for the purposes of IKE negotiation?

> 5.1.  Requirements
        :
>    o  A southbound protocol MUST support sending these SPD and PAD
>       entries, and IKE credentials to the NSF.

I think the intentended northbound direction here is from the controller
to the NSF, might help to make that clear.

>    o  It requires an (northbound) application interface in the security
>       controller allowing the management of IPsec SAs.
> 
>    o  In scenarios where multiple controllers are implicated, SDN-based
>       flow protection service may require a mechanism to discover which
>       security controller is managing a specific NSF.
>

Multiple controllers are an area of complexity that will
likely need a discovery mechanism (for both case 1 and case 2)
as the draft points out.  Also, esp if IKE is implemented in the
controller there needs to be a secure channel between the controller
and the NSF itself.

Another area that might need some discussion is the case of
NSF migration- there may be some performance considerations 
when IKE is implemented outside the NSF, and there is NSF migration.

--Sowmini

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 12 Jul 2016 12:45:16 +0200

Hi Sowmini:

> El 11 jul 2016, a las 13:13, Sowmini Varadhan <[email-masked]> escribió:
> 

[Rafa] Thank you. Please see my comments inline.

>>   policies and SAs to handle is high.  With the grow of SDN-based

[Rafa] Fixed.

> NSF or in the controller. It might help to make that clearer.

[Rafa] I think this needs clarification and we understand the confusion.

However, the distinction we have made in the I-D is still valid. The reason is the following: 

In case 2) the NSF only implements SAD, PAD and SPD, that is correct, … BUT in general the controller DOES NOT implement IKE in case 2) either. Yes, the controller needs to provide information for SPD, SA in the NSF but the controller DOES NOT perform an IKE negotiation for that (e.g. look Fig. 

In fact, as you can see in Fig. 2, IKE is not written in the box. That is intentional to denote that IKE protocol is not implemented and run in the controller. However the controller needs to distribute information about SPD, SAD and PAD. So the controller is doing key management operations but it does not mean IKE.
 
Having said that, it is true there is only one corner case where IKE is implemented in the controller, which is depicted in Fig. 8.  But this case may need further discussion. Personally, I would opt for the scenario in Fig. 7.

Also we still have to decide if IKE might be used as east/west interface with the controller (most probably it won’t be used as east/west)

> in the controller, right?

The only case would be Fig.8, which as I mentioned is a corner case. In any case, the IKE implementation should be a little special in the controller 

> src IP address for the purposes of IKE negotiation?

In general, there won

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 12 Jul 2016 13:09:20 +0200

Hi Sowmini (again) 

I sent an (uncomplete) e-mail by mistake. Please consider this one and see the complete answer inline.

> El 12 jul 2016, a las 12:45, Rafa Marin Lopez <[email-masked]> escribió:
> 
> Hi Sowmini:
> 
[Rafa] Thank you. 

[Rafa] Fixed.

In case 2) the NSF only implements SAD, PAD and SPD, that is correct, … BUT in general the controller DOES NOT implement IKE in case 2) either. Yes, the controller needs to provide information for SPD, SAD, PAD in the NSF but the controller DOES NOT perform an IKE negotiation for that (e.g. look Fig. 4) 

In fact, as you can see in Fig. 2, IKE is not written in the box. That is intentional to denote that IKE protocol is not implemented and run in the controller. However the controller needs to distribute information about SPD, SAD and PAD. So the controller is doing key management operations but it does not mean running IKE.

What do you think?

Having said that, it is true there is a corner case where IKE is implemented in the controller, which is depicted in Fig. 8.  But this case may need further discussion. Personally, I would opt for the scenario in Fig. 7.

Also we still have to decide if IKE might be used as east/west interface with the controller (most probably it won’t be used as east/west interface at all)

>> in the controller, right?

[Rafa] The only case would be Fig. 8, which as I mentioned is a corner case. In any case, if the IKE implementation is deployed in Fig. 8, a change in the Flow Security Policies provided by the admin would provoke starting an IKE negotiation with the end-user (let us assume the end user has also changed its SPD).  

>> src IP address for the purposes of IKE negotiation?

[Rafa] In general, there won’t be IKE negotiation except in Fig. 8. So focusing in Fig. 8, I think they may use same IP address. Also that possibility may be considered if IKE is used as west/east interface.

In the block diagram above this is the case (1) we have: NSF1 (IKE/IPsec) <——> NSF2(IKE/IPsec) . Therefore they do not use the same IP address. 

In case 2) : NSF1 (IPsec) <—> NSF2 (IPsec) … no IKE is performed neither in the NSFs nor in the controller. The controller just provides information for the SPD, SAD and PAD. It implies that controller generate key material but it does not mean to run IKE at all.

>> to the NSF, might help to make that clear.

[Rafa] Agree.

>> controller there needs to be a secure channel between the controller

[Rafa] I think that secure channel is always required in both cases: sensitive information needs to be exchanged.

>> when IKE is implemented outside the NSF, and there is NSF migration.

[Rafa] This is an interesting scenario we can explore. In the migration … you consider the case where the NSF is migrated under another controller, no?

Best Regards and thanks.

---

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 14 Jul 2016 09:24:19 -0400

> What do you think?

The distinction between "case 1" and "case 2" seems to be about whether
IKE is done in the NSF, or not. In all cases the sad/spd etc has
to be in the NSF. Might help to make that clear (and then elaborate
on the various permutations of the "or not" bit).

> [Rafa] In general, there won’t be IKE negotiation except in Fig. 8. So
> focusing in Fig. 8, I think they may use same IP address. Also that
> possibility may be considered if IKE is used as west/east interface.

Reason that I asked this question is that if IKE is done outside
the NSF, then the entity doing IKE may be constrained to use the
same src addr as the NSF (I havent checked into all the requirements
around IKE here) and this may be something that needs some care.

> [Rafa] This is an interesting scenario we can explore. In the
> migration … you consider the case where the NSF is migrated under
> another controller, no?

correct.

--Sowmini

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 14 Jul 2016 18:26:27 +0200

Hi Sowmini:

> El 14 jul 2016, a las 15:24, Sowmini Varadhan <[email-masked]> escribió:
> 
> IKE is done in the NSF, or not.

[Rafa] Correct.

> In all cases the sad/spd etc has
> to be in the NSF.

[Rafa] Correct.

> Might help to make that clear (and then elaborate

[Rafa] Thanks for the suggestion.

> around IKE here) and this may be something that needs some care.

[Rafa] Ah, ok. It seems reasonable to think that the end user will require to see the IKE packet coming from the same IP address (same IKE responder). In a typical scenario involving a controller I do not see a real problem here. The controller could build a UDP packet with the IKE message from the information sent by the NSF and pass that to the NSF so it can forward it to the end user. In any case, I agree with you that this is one of the most complicated scenarios and needs some care.

>> migration … you consider the case where the NSF is migrated under

[Rafa] Understood. We can definitely discuss about this scenario (even a simpler case when the NSF is migrated under another network (so change of IP address) even under the same controller. 

Thank you for the comments. We will try to reflect them in the next revision of the I-D.

> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec