Hi Sowmini: > El 11 jul 2016, a las 13:13, Sowmini Varadhan <sowmini.varad...@oracle.com> > escribió: > > 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:
[Rafa] Thank you. Please see my comments inline. > >> 1. Introduction > : >> policies and SAs to handle is high. With the grow of SDN-based > > nit s/grow/growth [Rafa] Fixed. > >> 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. [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) > > : >> 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? 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 > >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 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? In general, there won > > >> 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 > > ------------------------------------------------------- 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: r...@um.es ------------------------------------------------------- _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
