Re: [I2nsf] [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

> On 20 Jul 2017, at 9:56, Valery Smyslov <svanru@gmail.com> 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.

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.

> 
> 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:gabilm@um.es <mailto:gabilm@um.es>]
> Sent: Wednesday, July 19, 2017 5:21 PM
> To: Valery Smyslov
> Cc: Alejandro Pérez Méndez; i2nsf@ietf.org <mailto:i2nsf@ietf.org>; 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 <svanru@gmail.com <mailto:svanru@gmail.com>> 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
>> I2nsf@ietf.org <mailto:I2nsf@ietf.org>
>> 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: gabilm@um.es <mailto:gabilm@um.es>
> 
> 
> 
> 
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org <mailto:I2nsf@ietf.org>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>

Re: [I2nsf] [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

Attachment: signature.asc