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.
Hi, I took a look at this doc, some comments:
> 1. Introduction
:
> 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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
