Hi Linda: > El 20 jun 2016, a las 15:41, Linda Dunbar <[email protected]> escribió: > > Rafa, > > I see that your draft has identified multiple cases of SDN controlled IPSec > tunnel. > > As I2NSF focus on specifying the data models for the Flow Security Policies, > the controller "Proactively" setting up the IPSec polices/keys to network > elements are within the I2NSF scope.
I see. > > The "reactive option, that is, very similar as it would happen with the > OpenFlow PacketIn message and then PacketOut" is not in the I2NSF scope. > However, the specifying the data model for the policy to the controller on > which flows to be protected by IPSec tunnel should be in the I2NSF scope. Please be aware that some reactive (upon an event) behavior may be required even when the controller sets up the IPsec policies/keys proactively. For example, the PF_KEY interface (RFC 2367) in the kernel has an “event” "The SADB_EXPIRE message is sent from the kernel to key management applications when the "soft lifetime" or "hard lifetime" of a Security Association has expired. Key management applications should use receipt of a soft lifetime SADB_EXPIRE message as a hint to negotiate a replacement SA so the replacement SA will be ready and in the kernel before it is needed.” This is a kind of asynchronous event, which is important because it allows the controller to react and update the SAs. Is this kind of event in the I2NSF scope? In any case we are going to modify the I-D to show all these aspects. Some comments inline: > > > Other comments are inserted below > > > -----Original Message----- > From: Rafa Marin Lopez [mailto:[email protected]] > Sent: Sunday, June 19, 2016 1:06 PM > To: Linda Dunbar > Cc: Rafa Marin Lopez; [email protected]; [email protected]; Sowmini Varadhan; > Sowmini Varadhan > Subject: Re: [IPsec] [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? > > <snip> > > > > - 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. > > [Linda] so the I2NSF should only focus on specifying the protocols and data > models for the “Protective” methods. Maybe part of your draft can be further > developed in I2NSF WG. > > > > > > > - 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. > > [Linda] Are you assuming that data packets actually traversing the > “Controller”? If yes, the I2NSF focus on the flow policy north bound to the > controller. [Rafa] It is not traverse but it is to check the first data packet in a flow to see there is need for security or not. But certainly that belongs to southbound interface. > > > > > > > - 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?. > > [Linda] Yes. > > > 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. > > [Linda] above is what I call “query”. Need to flush out the detailed data > model for your IPSec case in I2NSF WG. > > > > > > - 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. > > [Linda] that will be useful. Can you write this detailed information exchange > for I2NSF? [Rafa] We think so yes. Best Regards. > > > > > > 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? > > > [Linda] correct. > > Thanks, Linda > > > > > 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] > ------------------------------------------------------- > > > > > > _______________________________________________ > 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
