Hi Yoav, Valery, > El 20 jul 2017, a las 10:12, Yoav Nir <[email protected]> escribió: > >> >> On 20 Jul 2017, at 9:56, Valery Smyslov <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Gabriel, >> >> I think that at this point the discussion is not very productive. >> I admit that I’m not very familiar with SDNs, so I have to >> blindly trust you when you state that the SDN Controller >> knows everything and is able to control everything, >> so it is like God. Probably this is true. > > That the controller (or its administrator) knows everything is part of the > model of SDN. SDN comes from datacenters and in datacenters the > administrators control everything and the protocol is used to configure a > whole bunch of routers and switches.
> > I2NSF is extending this to security boxes such as firewalls, IDS, etc. The > context is still the data center. The firewalls are at the edge of the > datacenter and the intruder detection is either co-located with the firewall > or inside. Right. > > VPN is different. While one or more box is within the datacenter, the vast > majority of boxes are out of the datacenter and located all over the > Internet. Their routing is usually not under the control of the > administrator, so we’d like to control just the IPsec configuration. The idea of the draft is not to propose a solution to manage every posible IPsec scenario, we understand that there are scenarios where it could be more difficult to deploy a SDN solution. The idea is to provide a tool that could be used when the security requirements could be met. In the case of out of the datacenter scenarios I see your point, but in the other side you can find thinks such as SD-WAN trying to provide solutions for that. In the case of inside the datacenter there are some cases where it could be useful. For example, suppose a cloud environment running hundred or thousands of VMs requiring IPsec for internal communications. Thanks again for the feedback. Best regards, Gabi. > >> >> I just want to reiterate, that while security architecture >> with central key distribution is definitely feasible and >> it is feasible to make it secure, my strong opinion is that >> it is still a large step backward from End-to-End security >> model and it is much more fragile. And I agree with Tero that >> “EE simplicity” argument in most cases doesn’t look >> reasonable to buy. Probably you can add justifications >> to this argument, e.g. by providing estimates how much >> resources you are going to save on EE if you get rid of IKE >> (but leave IPsec, TLS and so on). >> >> Regards, >> Valery. >> >> From: Gabriel Lopez [mailto:[email protected] <mailto:[email protected]>] >> Sent: Wednesday, July 19, 2017 5:21 PM >> To: Valery Smyslov >> Cc: Alejandro Pérez Méndez; [email protected] <mailto:[email protected]>; IPsecME >> WG; Rafa Marin Lopez >> Subject: Re: [I2nsf] [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection >> >> Hi Valery, >> >>> El 19 jul 2017, a las 13:54, Valery Smyslov <[email protected] >>> <mailto:[email protected]>> escribió: >>> >>> Hi Alejandro, >>> >>> >>>>>> It is more fragile too. You must perform periodical rekey (update keys) >>>>>> and this must be done synchronously. >>>>> You have to do it by pairs, does not seem that difficult. And, as IKE >>>>> does, you create the new ones and, once created, delete the old ones. I >>>>> don't see the synchrony problem that important. >>>> In ideal world - yes. In real world - I'm not so sure. >>>> Imagine you have an SA expired and the SDN installs a new SA >>>> on the peers, but one of SDN-peer TLS connection failed because off >>>> the temporary network problem, so you have a new SA partially installed. >>>> What is the peer that didn't receive a new SA supposed to do? >>>> Continue to use an old one despite the fact that it is expired? >>>> Block all traffic? Something else? >>> In fact, I think the SDN-based approach performs even better than IKE in >>> this regards. >>> Imagine what happens if the corresponding IKE rekey process fails for >>> the very same temporary network problem. In the best case, CHILD SAs are >>> deleted after a hard expiration, and they will need to be re-created >>> when triggered by the SPD again. This is roughly identical to the SDN >>> approach. But, typically, when an IKE rekey fails, the initiator will >>> likely close the entire IKE_SA thinking the other peer is down, which >>> would result into having to recreate the IKE_SA (including the DH >>> exchange), and all the associated CHILD_SAs afterwards. >>> >>> Exactly, that's what IKE will do. But this is reasonable, because if IKE >>> messages cannot go between peers, it is most probably that >>> IPsec won't go either (especially in case of UDP encapsulation). >>> With SDN the situation is a bit different. The network problem >>> takes place on SDN-EE path, while EE-EE path works well, >>> but the peers cannot communicate, because SDN fails to provide >>> the keys in time. Note, that rekey may take place quite often, depending >>> on the algorithms involved. >> >> [Gabi] This kind of strong requirements on the controller availability and >> workload is assumed in the SDN paradigm. Let’s think in a L2 OpenFlow >> controller for example, where the L2-switch has to forward a copy of the >> incoming frame before to forward it. >> >> >> >>> How NAT traversal is to be done in IKE-less case? I understand, that >>> NATs are also controlled by SDN, but does SDN pre-install NAT mappings? >> >> That's a good question. I would say so, yes. >> >> So, SDN needs to synchronously configure one more entity (NAT) >> for IPsec to start working? >> >> [Gabi] If NAT is required the controller should know that, the IPsec >> configuration required to cross the NAT should be applied by the Security >> Controller . The configuration of the NAT entity may be configured >> independently (manually or not, note that there are Yang models for NAT >> (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07 >> <https://tools.ietf.org/html/draft-sivakumar-yang-nat-07>)). >> >> >> >> >> But, would that generate problems if the NAT box is not included in your >> SDN (e.g. it belongs to the mall centre or similar)? >> >> In this case you first need to use UDP encapsulation and second need to send >> NAT keepalive messages periodically. Usually it is IKE who sends >> these messages (I admit that you can also sends them from the kernel). >> IKE also determines if there is a NAT in between and which peer is >> behind the NAT. In case the NAT is out of SDN control, who will do this job? >> >> [Gabi] the Controller should know that there is NAT in the scenario. >> >> >> What is supposed to be done if packet with invalid AH/ESP SPI is received? >> >> >> >> >> Clearly, the packet itself is dropped, but later IKEv2 extensions (namely >> RFC6290, Quick Crash Detection) allows to send IKE notification >> to the peer with a security token to help peers quickly recover from the >> crash. >> What is supposed to be done in IKE-less case? Or do you think that >> with SDN such things like non-synchronized IPsec states never happen? >> >> [Gabi] If it is an audiatable event by the kernel, the peer can notify the >> controller about that (some examples of notifications are already included >> in the yang model) >> >> Thanks for the comments, this discussion is really interesting …. >> >> Regards, Gabi. >>> >>> Regards, >>> Valery. >>> >>> >>> These are exactly the sort of situations that need to be figured out. >>> >>> I believe there are many of them. >>> >>> Regards, >>> Valery. >>> >>> _______________________________________________ >>> I2nsf mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/i2nsf >>> <https://www.ietf.org/mailman/listinfo/i2nsf> >> >> >> >> ----------------------------------------------------------- >> Gabriel López Millán >> Departamento de Ingeniería de la Información y las Comunicaciones >> University of Murcia >> Spain >> Tel: +34 868888504 >> Fax: +34 868884151 >> email: [email protected] <mailto:[email protected]> >> >> >> >> >> _______________________________________________ >> I2nsf mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/i2nsf >> <https://www.ietf.org/mailman/listinfo/i2nsf> > > _______________________________________________ > I2nsf mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/i2nsf > <https://www.ietf.org/mailman/listinfo/i2nsf> ----------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: [email protected] <mailto:[email protected]>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
