Hi Linda: > El 23 jun 2016, a las 23:13, Linda Dunbar <[email protected]> escribió: > > Rafa, > > > > > 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” > > [Linda]I see. Those "events" definitely need to be addressed by the data > model between controller and end points. It is helpful to describe the > information model.
[Rafa] Good to know. > > > "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. > [Linda] Thanks. Are you going to take the relevant portion in the I-D for > I2NSF WG? Or are you going to keep in the SDNrg? [Rafa] We will bring these modifications to I2NSF WG. Best Regards > > > > 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-protecti >>> on >>> -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] > ------------------------------------------------------- > > > > > _______________________________________________ > 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
