Dear Linda: Thank you for reviewing our I-D. Please see my comments inline.
> El 17 jun 2016, a las 22:50, Linda Dunbar <[email protected]> escribió: > > Rafa, > > Quickly reading through your draft, I have a few questions: > > - Do you mean that the (SDN) controller will be responsible for distributing > the needed information to the end nodes of the IPSec tunnel When you say "SDN > controller takes the role of the Internet Key Exchange (IKE) entity in the > IPsec architecture”? [Rafa] Correct. That is the general idea in this I-D. SDN controller can also send IKE credentials to the network resources if they implement IKE (besides IPsec stack of course) > > - Section 8.1: Page 11: Bullet 1: > You stated that the node sends the first packet to Controller for the > controller to determine if the traffic needs to go through IPSec tunnel. > > Shouldn't the controller get flow protection policy from clients (north bound > interface) and inform the needed end nodes on what traffic/flows need to go > through the IPSec tunnel? [Rafa] Actually, there are two options. The one shown in the I-D is reactive, that is, very similar as it would happen with the OpenFlow PacketIn message and then PacketOut. The other option, of course, it is to create the rules in the network resource even when traffic has not been observed yet (proactive). Both options are completely possible. We can clarify this in the next version. > > > - Section 8.1: Page 12: Bullet 3: > The controller can't really enforce the rule. but instead requesting the "End > Node" to encapsulate the IPSec tunnel around the flows that need to be > through the IPSec tunnel. correct? [Rafa] Not sure why you think the controller can’t enforce the rule. Basically the step 3 says the controller is filling a SAD entry without the need of running IKE between network resources. > > - Section 6, Page 7, Second paragraph after the Figure 2: > The Controller should send the IPSec tunnel request to the end points of the > desired IPSec tunnel. Also the controller should send query to the end point > to check if they have the needed resource to establish the desired IPSec > tunnel. [Rafa] What do you mean with “IPsec tunnel request”? By sending the information related with the IPsec tunnel (e.g. a SAD entry) to build it should be enough, I guess that is what you mean by that , right?. The controller can of course verify if the end points of the IPsec SA have the information to establish an IPsec tunnel according to the information that the controller keeps. If the state is not there or is going to be outdated it can enforce the information again. Alternatively, the end points could also inform when something is required to the controller (reactive) so the controller can act accordingly. > > - Section 8.2: > Second paragraph: When the two end points of the needed IPSec tunnel are in > two different ISPs (say ISP-A and ISP-B), your draft states that the ISP-A > controller has to negotiate with ISP-B controller on the Flow Security policy > rules. What information will be carried by those Policy Rules? Since I2NSF is > to specify the data models for those rules, it would be very helpful to > identify the information exchanged first. [Rafa] We can specify better what information in the following draft. But basically we have two models explained in the draft when 1) IKE is implemented in the network resource or when IKE is not implemented in the network resource. In 1) parameters to run an IKE SA between GW1 and GW2 must be negotiated (IKE credential, cryptographic suite, etc…) and the different SPD entries of the SPD that apply. An SPD entry has parameters such as Remote IP Address, Local IP Address, Next Layer Protocol, Name, Local and Remote Ports. In 2) apart from SPD entries you need to configure SAD entries. This information implies Security Parameter Index, Sequence Number, AH information (keys , key lifetime) , ESP information… etc. We can detail what information is required. > > Page 13: bullet 2: before the negotiation between the two controllers on the > SPD policies and IKE credentials, don't you think that they need to inquire > each other if the other party has the needed resource for the needed IPsec > tunnel? [Rafa] But for that, what kind of parameters do you send to ask the question? I can imagine you could ask : do you have an end point with this IP address, IKE support, AH or ESP support… etc…? Is that what you have in mind? In any case, if they do not have that support trying the negotiation between the two controllers would fail so that you would notice that the needed resource is not available as well, right? Best Regards. > > > > Thanks, Linda > > -----Original Message----- > From: Rafa Marin Lopez [mailto:[email protected]] > Sent: Friday, June 17, 2016 7:43 AM > To: Linda Dunbar > Cc: Rafa Marin Lopez; Sowmini Varadhan; [email protected]; Sowmini Varadhan; > NVO3; Liyizhou > Subject: Re: [I2nsf] 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? > > Dear all: > > Maybe this I-D might be interesting and related with this discussion > regarding IPsec/IKE management. We hope to have an updated version soon and a > proof-of-concept implementation of some of the scenarios. > > https://tools.ietf.org/html/draft-abad-sdnrg-sdn-ipsec-flow-protection-01 > > Best Regards. > > > > El 17 jun 2016, a las 10:43, Linda Dunbar <[email protected]> > > escribió: > > > > Sowmini, > > > > You said: > > “However, applying IPsec to specific flows (e.g., those defined by a src or > > dst port on which the service listens) is important.” > > > > What is the current operation procedure for Overlay network to inform the > > underlay network on which flows to go through IPSec channel? > > > > You said: > > “..But that also made me wonder about the interaction between IPsec/IKE and > > the proposed BGP FS (IPsec is frequently used between end-systems that do > > not want to run a BGP daemon). Since the config information that needs to > > be distributed are things like keys, algorithms etc to populate the > > sadb/spd, IKE looks more appropriate in most cases.” > > > > > > Does the underlay network controller get some information (or hint from the > > Overlay network controller) on how the keys are configured for the IPSec > > tunnel for the specific flows among the Overlay nodes? > > > > > > Thanks, > > Linda > > > > > > -----Original Message----- > > From: Sowmini Varadhan [mailto:[email protected]] > > Sent: Thursday, June 16, 2016 10:57 AM > > To: Linda Dunbar > > Cc: Liyizhou; NVO3; Sowmini Varadhan > > Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting IPSec > > connection from the Underlay for a specific time span? (was : Flow Security > > Policies exchanged over I2NSF service layer interface? > > > > On Wed, Jun 15, 2016 at 8:55 AM, Linda Dunbar <[email protected]> > > wrote: > > > > > > NVO3 Participants, > > > > > > > > > > > > I2NSF (Interface to Network Security function) has a work item in > > > defining the flow security policy between domains (which includes inquiry > > > of the capability from one domain to another and the actual flow policy > > > rules from one domain to another). > > > > > > Very often, the paths (or links) among nodes of a overlay network are > > > provided by other network operators (a.k.a. “underlay network”). The > > > flow policy rules are intended to filter out unwanted traffic from > > > underlay network so that various attack traffic won’t saturated the > > > access links to the overlay nodes. > > > > > > > > > > > > One interesting scenario brought up is Overlay nodes may need to request > > > some traffic to be traversing IPsec channel. To achieve this goal, it is > > > necessary for Overlay Network controller to inquire if the needed IPsec > > > resource are even available before send the request (may even involve AAA > > > process between controllers of each corresponding domain ). > > > > > > > > > > > > Want to have a survey if people see the use case of Overlay Network > > > needing portion of traffic to be through IPSec channel? > > > > Yes, this is a valid use case, and one that we are looking at as well. > > > > > IPSec is supposed to be between two end nodes. Here we assume that the > > > Overlay nodes don’t have the resource or capability for IPsec, but expect > > > IPsec between flow’s ingress and egress nodes (i.e. NVE). > > > Any opinion is appreciated. > > > > > > > > > > Are there any use cases of overlay network needing IPSec among their > > > nodes only for a specific time span? i.e. Time based IPSec connection? > > > > Time based IPsec connection is not a use-case we have encountered. > > People usually use IKE for periodic key-rollover, if that is the goal. > > > > However, applying IPsec to specific flows (e.g., those defined by a src or > > dst port on which the service listens) is important. > > > > But that also made me wonder about the interaction between IPsec/IKE and > > the proposed BGP FS (IPsec is frequently used between end-systems that do > > not want to run a BGP daemon). Since the config information that needs to > > be distributed are things like keys, algorithms etc to populate the > > sadb/spd, IKE looks more appropriate in most cases. > > > > Like [CJ], I too have to read the draft in greater detail to comment > > further. > > > > --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] > ------------------------------------------------------- > > > > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- 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
