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

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 18 Jul 2017 17:10:17 +0300

Hi,

I'm very much concerned with the IKE-less option presented in the draft.

First, the Network Controller becomes a very attractive target for attacks
in this case, since an attacker, if attack is successful, will gain all the keys
for the whole system. 

Then, it is not clear for me how the keys are distributed in this case from
the Network Controller to the End Entities. I presume that they are not
sent in clear, so the End Entities must already have capabilities to run some
security protocol (TLS, IPsec), and thus they must be already provisioned 
out of band with some security credentials (keys, certificates).
So I don't understand what you gain in case you don't run IKEv2
on End Entities.

In general, central distribution of session keys looks much less secure,
than running IKEv2 on them. You loose PFS property, you loose
the property that no one but the peers know the session keys etc.
It is more fragile too. You must perform periodical rekey (update keys) 
and this must be done synchronously. All the rekey problems that were 
solved by IKE will arise again.

Regards,
Valery Smyslov.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Jul 2017 10:32:19 -0400 (EDT)

> I'm very much concerned with the IKE-less option presented in the draft.

+1

> the property that no one but the peers know the session keys etc.

It worries me too that we throw away the concept of end to end
security. Endpoints needing to trust someone else that their keys
are not leaked/malicious/compromised is generally not a good idea.

> solved by IKE will arise again.

Indeed! For example, if the ESP algorithm is an AEAD, and the endpoint
reboots, and the central unit re-issues the same key, the endpoint will
re-start the GCM counter at 1, thereby compromising the security and in
effect leaking the private key.

IKE is a lot more then just a channel to shove private keys and
src/dst policies to endpoints. I would much rather see a minimal-IKEv2
implementation then this "non-IKE" style solution.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Jul 2017 18:06:07 +0300

Valery Smyslov writes:
> First, the Network Controller becomes a very attractive target for
> attacks in this case, since an attacker, if attack is successful,
> will gain all the keys for the whole system.

And it is big difference if you get the traffic keys, or if you get
just the authentication keys used to authenticate the peers when
creating traffic keys.

I.e. any TLA would love to get their hands on all the traffic keys in
one location, and then be able to decrypt any traffic going inside any
of the IPsec tunnels.

If controller only has the PSKs or similar to do the authentication
between peers, then that means that the TLA needs to do active attack
for each connection they want to break.

Beause of this I think it is always best not to move the transport
keys outside the boxes that needs them, i.e., keep them only on the
nodes doing actual encryption / decryption.

Also knowing that the controller most likely keeps all kind of logs
and takes backup of the configurations it is keeping, this also makes
the backups suitable targets for attacks, as they allow decryption
previously stored flows of traffic, and this can be done years later
when one of those backups accidently finds its way to wrong hands. 

> Then, it is not clear for me how the keys are distributed in this
> case from the Network Controller to the End Entities. I presume that
> they are not sent in clear, so the End Entities must already have
> capabilities to run some security protocol (TLS, IPsec), and thus
> they must be already provisioned out of band with some security
> credentials (keys, certificates). So I don't understand what you
> gain in case you don't run IKEv2 on End Entities.

This I think is important question, i.e., what is the gain for not
running IKEv2 between the nodes?

> solved by IKE will arise again.

And of course you do not know when to do rekey, as you do not know how
many bytes each peers have been transmitting to be able to do rekey
before there has been too much data encrypted with one key.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Jul 2017 17:14:16 +0200

I mostly agree, but one point…

> On 18 Jul 2017, at 17:06, Tero Kivinen <[email-masked]> wrote:

<snip/>

> running IKEv2 between the nodes?

Simpler gateway, less code, no PK operations, no need for random number generator.

The counter-argument is that without all these you can’t setup a TLS session to run netconf over.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 18 Jul 2017 17:34:29 +0200

> The counter-argument is that without all these you can’t setup a TLS session to run netconf over.
No random number generator? I don't think this is true even for a pure 
ESP endpoint.

Thanks,
     Yaron

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Jul 2017 17:48:29 +0200

With AES-GCM, AES-CCM, ChaCha20-Poly1305 you don’t need a PRNG at all.

With AES-CBC you need an unpredictable IV, but you could generate them by encrypting a counter with one AES key (that could be provided by the controller)

But you still need the TLS session.

> On 18 Jul 2017, at 17:34, Yaron Sheffer <[email-masked]> wrote:
> 
> No random number generator? I don't think this is true even for a pure ESP endpoint.
> 
> Thanks,
>    Yaron

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 18 Jul 2017 17:56:39 +0200

Hi Tero, Valery:

Please see inline.
> El 18 jul 2017, a las 17:06, Tero Kivinen <[email-masked]> escribió:
> 
> Valery Smyslov writes:

[Rafa] Overall, the SDN paradigm states the controller is a trusted entity. The controller can generate session keys based on PNRG and sends those keys and forget about them. No need to store any keys, just generate them and distribute them.

Having said this, in SDN paradigm, (and forgetting for a moment about IPsec) , the SDN controller is ALWAYS a very attractive target. Reason: if a SDN controller is attacked the attacker has the control over the network (it can make the entire network no operative). Example: in the SDN paradigm, for example, the “router” does not have routing protocol, just routing/switching table. The SDN controller fills tables. If the SDN is attacked the “router” does not know how to react anymore. 

Another conversation is if we like or dislike the SDN paradigm , in general (regardless IPsec).

> when one of those backups accidently finds its way to wrong hands. 

[Rafa] In reality, the controller can forget immediately the credentials that has been generated. 
As a security measure , the controller does not need to store any keys it has distributed.

> running IKEv2 between the nodes?

[Rafa] As Yoav mentioned, simpler devices. 
> before there has been too much data encrypted with one key.

[Rafa] Basically, the SDN controller will know when to do the rekey. Please, see the YANG model in our draft. There is notification “expire”

 notifications:
       +---n spd-expire
       |  +--ro index?   uint64
       +---n sadb_acquire
       |  +--ro state    uint32
       +---n sadb_expire
          +--ro state    uint32

Basically when the kernel sends an “expire” the NETCONF server will capture it and sends the notification to the SDN controller. The acquire is the same (our proof-of-concept does that)

Best Regards.

> -- 
> [email-masked]
> 
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa 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-masked]
-------------------------------------------------------

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 18 Jul 2017 18:09:39 +0200

Hi Yoav:

> El 18 jul 2017, a las 17:14, Yoav Nir <[email-masked]> escribió:
> 

[Rafa] The argument is the NSF will need this TLS/SSH session with the controller regardless IPsec management. It will need it for routing management, IDS, firewall, management etc… Since that TLS/SSH is already there (regardless IPsec management) we can leverage this. Also the implementation of the NETCONF server is required no matter if we have IPsec management. Therefore if you have case 1 vs case 2 , case 1 still needs the NETCONF server in addition to IKE implementation, case 2 does not. Therefore, as you mention makes the NSF simpler, no doubt.

> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Tue, 18 Jul 2017 18:11:15 +0200

Hi Valery, all,

 > than running IKEv2 on them.
That's arguable, yes. But being less secure does not mean being useless. 
Coming to my previous comment, we don't use RSA with 8192 bit keys for 
everything. Although it is more secure, there are scenarios were a 
lighter approach is enough. If running IKE is too much for your devices, 
the IKE-less option might work for you if your security contraints are 
fewer. This SDN-based approach does not need to solve everyone's 
problems for every possible scenario. Neither does Kerberos, IPsec 
itself nor any other security protocol.

 > You loose PFS property,
I don't see why. Actually, keys on the controller are generated by a 
secure RNG so every key you generate is completely unrelated to the 
previous one. That's indeed an advantage, rather than the opposite.

 > you loose
Right.

 > 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.

 > All the rekey problems that were
Prior IKE we had a phone call / email / SSH based rekeying. I don't 
think having an automated central entity using a secure control protocol 
such as NETCONF over SSH/TLS is exactly the same.

Regards,
Alejandro

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 18 Jul 2017 18:32:32 +0200

Hi Paul: 

> reboots, and the central unit re-issues the same key,

[Rafa] Just a clarification, the central unit (Security Controller) will never re-issue the same key (it is pseudo-randomly generated by the controller)

Moreover the controller will know when to do the rekey and the end point the requires it. We have those notifications (expires) in our YANG model for this reason.

> the endpoint will

---

From: Gabriel Lopez <[email-masked]>
Date: Tue, 18 Jul 2017 18:35:06 +0200

Hi Yoav,

> El 18 jul 2017, a las 17:48, Yoav Nir <[email-masked]> escribió:
> 

As you know IPsec is independent of the key management protocol. What the draft proposes is a way to allow the Controller (in case 2) to provide the required information for IPsec and to allow the Controller to receive the IPsec kernel notification regarding SA required, SA expiration, etc, etc.., exactly as IKE does. These notification, as Rafa says, are modelled by the YANG file and allow the Controller to have the whole view of what is is happening in the NSFs. It allows the Controller to refresh keys, SA information, etc, etc,

Regards, Gabi.

>> No random number generator? I don't think this is true even for a pure ESP endpoint.

-----------------------------------------------------------
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-masked] <mailto:[email-masked]>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 19 Jul 2017 09:19:40 +0300

Hi Rafa,

Hi Tero, Valery:

Please see inline.

Valery Smyslov writes:

I'm very much concerned with the IKE-less option presented in the
draft.

[Valery] No, there situations are completely different. If attackers hijacks SDN and makes the entire

network no operative, this is an active attack and it is easy to detect and take some measures.

On the other hand, if an attacker hijacks SDN, learns all the keys and then just passively

eavesdrops all the traffic in the network – you’ll never know that you were really hijacked.

That’s much more dangerous.

And another consideration. Did you see the ongoing discussion in the TLS WG

about the draft draft-green-tls-static-dh-in-tls13 that basically suggests to hand over the

TLS keys to some third party for later inspection of encrypted traffic? Your proposal

looks like more “superior” approach, since SDN can collaborate with inspection

devices handing them over the keys. And the large proportion of security people

in the TLS WG seem to find this idea inappropriate for IETF standards in general.

Regards,

Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 19 Jul 2017 09:46:30 +0300

Hi Alejandro,

> itself nor any other security protocol.

OK, but then you should clearly state your requirement.
Otherwise it is possible to drive situation to absurdum.
For example, for a sake of device simplicity, you may
get rid of IPsec at all and send all the traffic that needs protection
to SDN via existing TLS connection/ The SDN then will route
it to appropriate peer. It would work and will make devices
even more dumber (to be clear - I don't propose this,
it is just an example of corner case solution that in theory would work).

> previous one. That's indeed an advantage, rather than the opposite.

It depends. If you use PRNG instead of true RNG, then you'll have no PFS.

> 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? 

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?

Regards,
Valery.

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Wed, 19 Jul 2017 09:38:53 +0200

Hi Valery,
> it is just an example of corner case solution that in theory would work).

I see your point and agree the document may need to state it if not 
completely clear implicitly.
It's a trade-off between simplicity (use as few protocols/functionality 
as possible), performance (use as few memory/disk/CPU resources as 
possible, this includes not using SSH/TLS other than for the control 
channel), and security (be as secure as possible, but not overkilling 
for the requirements of the scenario).
> It depends. If you use PRNG instead of true RNG, then you'll have no PFS.

I think it is a fair assumption that an SDN controller, which is far 
from being a constrained device, will have a true RNG.

> 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.

> NATs are also controlled by SDN, but does SDN pre-install NAT mappings?

That's a good question. I would say so, yes.
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)?
These are exactly the sort of situations that need to be figured out.

Regards,
Alejandro

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 Jul 2017 11:17:01 +0300

Rafa Marin-Lopez writes:
> [Rafa] In reality, the controller can forget immediately the
> credentials that has been generated. As a security measure , the
> controller does not need to store any keys it has distributed.

No it cannot. The keys needs to be installed in multiple nodes, which
means that when it generates them it needs to store them until it is
sure that every single device needing them has them.

Also if any single device restarts, it will need new keys, and those
keys again needs to be destributed to all other entities sharing SA
keys with the node. Also even if if could remove the keys quite
quickly after generating them, in practice I do not think that is
going to happen, as operators want to be able to see what is the
configuration that was sent to node, which then requires controller to
keep configuration available. 

> [Rafa] As Yoav mentioned, simpler devices. 

I do not really belive that. You need security protocol to be able to
transmit the configuration to the nodes, and that security protocol
will require similar resource than what IKEv2 needs. To be able to do
the actual ESP traffic for links will require much more resources than
running IKE to setting up the SA. Yes, you can leave few kilobytes of
code out from the flash, as you do not need to implement IKEv2.

Also you loose all kind of features too, like ability to spport
roaming clients (i.e., laptop, or phone etc connecting to network
through VPN, or actually connecting IPsec to any other node that is
not directly controlled by the controller).

Note, that the controller cannot run IKEv2 in behalf of any of nodes
it is controlling, as that is forbidden by the IPsec (IKE and Child SA
are tied together so that if one goes down, the other MUST go down
too). See section 2.4 of RFC7296 end of 4th paragraph (line 14 of page
28). 

Also if you are limiting yourself to the endpoint-to-endpoint
transport mode (section 1.1.2 of RFC7296) with policy given by the
controller, you do not need full IKEv2 implementation, you can
implement minimal IKEv2 (RFC7815), with exception that you also need
to implement the responder side also.

Using the frequently generated PSKs distributed from the controller,
and minimal IKEv2, will give you much better security than when you
transport traffic keys from controller.

Btw, on Friday there will be presentation in ipsecme where they
implemented minimal IKEv2 with GDOI modifications (i.e., IKEv2 +
multicast key distribution) in device which having 256 kB of flash,
and 32 kB of ram, and that implementation included the full network
support also, not only IKEv2...

> [Rafa] Basically, the SDN controller will know when to do the rekey. Please,
> see the YANG model in our draft. There is notification “expire”

Ah, sorry, I have not read the draft yet, as I have been too busy with
other things, but if there is two way communication between the node
and controller, than that works fine.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 19 Jul 2017 14:54:51 +0300

Hi Alejandro,

> 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. 

> 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? 

> 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?

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?

Regards,
Valery. 

> These are exactly the sort of situations that need to be figured out.

I believe there are many of them.

Regards,
Valery.

---

From: Gabriel Lopez <[email-masked]>
Date: Wed, 19 Jul 2017 16:21:09 +0200

Hi Valery,

> El 19 jul 2017, a las 13:54, Valery Smyslov <[email-masked]> escribió:
> 
> Hi Alejandro,
> 

[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.
> 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)).

> 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.

> 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.

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Wed, 19 Jul 2017 16:42:41 +0200

Hi Valery, Gabi:

A couple of comments inline.

> El 19 jul 2017, a las 16:21, Gabriel Lopez <[email-masked]> escribió:
> 
> Hi Valery,
> 
>> El 19 jul 2017, a las 13:54, Valery Smyslov <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> Hi Alejandro,
>> 
> [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>)).
> 
>> 

[Rafa] As additional comment to Gabi’s e-mail related with NAT, in our draft we have this text when IKE is not in the device (NSF):

"Another example is the
   NAT traversal support.  In general, the SDN paradigm assumes the SDN
   controller has a view of the network it controls.  This view is built
   either requesting information to the NSFs under its control or
   because these NSFs inform the SDN controller.  Based on this
   information, the SDN/security controller can guess if there is a NAT
   configured between two hosts, apply the required policies to both
   NSFs besides activating the usage of UDP encapsulation of ESP packets
   [RFC3948].

   In those scenarios, the Controller could directly request the NSF for
   specific data such as networking configuration, NAT support, etc.
   Protocols such as NETCONF or SNMP can be used here.  For example, RFC
   7317 [RFC7317] provides a YANG data model for system management or
   [I-D.sivakumar-yang-nat] a data model for NAT management.

> [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)

[Rafa] Regarding the quick recover, it is typical a keep alive mechanism between the device and the SDN controller. So that the SDN controller can react quickly when a device restart or crash.

Best Regards.

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Wed, 19 Jul 2017 17:23:09 +0200

Hi Tero:

Thanks for this discussion. Really interesting and productive in my opinion. My comments inline
> El 19 jul 2017, a las 10:17, Tero Kivinen <[email-masked]> escribió:
> 
> Rafa Marin-Lopez writes:
[Rafa] But that is clear, isn’t it?. If the controller generates them then there is a short period of time where the key is there. No doubt about it.

My point is that the SDN controller does not need to store them once they are distributed.

> keep configuration available. 

[Rafa] One thing is to keep certain configuration about the SA and another to store the keys in the controller. A good security practice is to not store the keys. 

Moreover the YANG model in the device may dictate that the variable with the key has only writing permissions and it cannot be read posteriorly. 

But, of course, if a centralized entity is taking control of everything and that entity decides to not play nicely (storing keys for example), we have a problem. That happens in SDN world regardless IPsec. If we do not want to go to a centralized paradigm, it is fine. Get rid of SDN for management and let stay in the distributed way. 

But I think this is something general. If you do not trust in the “trusted” entity then we have a problem. No doubt. In fact, the area of securing the SDN controller itself is a vast area of contribution and an important topic nowadays.

> will require similar resource than what IKEv2 needs.

[Rafa] The device needs to handle a single SA (TLS or SSH) with the controller. As that will be happen regardless the management of IPsec for tackling other aspects such as routing, IDS, firewalls, etc. 

On the other hand, the number of IPsec SAs that device has to handle can be many. 

> To be able to do

[Rafa] This is the reason we also have case 1 (ikev2 in the nsf). I think it is important to note that we do not propose case 1 vs case 2. 
We have two cases and depending on the deployment one may choose case 1 or case 2. 

In other words, we are not against on having IKEv2 in the NSF at all. On the contrary it has clear advantages. We are just stating that there is also another possibility (case 2) with advantages too.

> too). See section 2.4 of RFC7296 end of 4th paragraph (line 14 of page

[Rafa] In the case you mention, if an IKE SA is in the controller (this case would be part of Road Warrior, which is TBD though), the controller will know the IKE SA is down. As a consequence the Controller will remove the child SAs. 

Thus, if the IKE SA goes down the other goes down, correct?

In any case, in my opinion, case 1 in our I-D could be better for Road Warrior. No problem with that.

> transport traffic keys from controller.

[Rafa] Yes, that is one option. My comment here in the past was you would 
still need other features coming from the controller since minimal ikev2 does not provide you all of them.

As I see it, minimal ikev2 in the device is still case 1 somehow. But we can introduce a note about minimal IKEv2 in our I-D as well, of course.

> support also, not only IKEv2…

[Rafa] Good to know. 
> and controller, than that works fine.

[Rafa] Yes, there is two way communication between the node and the controller.

Thanks.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 20 Jul 2017 10:56:35 +0300

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.

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-masked]] 
Sent: Wednesday, July 19, 2017 5:21 PM
To: Valery Smyslov
Cc: Alejandro Pérez Méndez; [email-masked]; IPsecME WG; Rafa Marin Lopez
Subject: Re: [I2nsf] [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

Hi Valery,

Hi Alejandro,

 

Regards, Gabi.

Regards,
Valery. 

Regards,
Valery.

 

email: [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 Jul 2017 10:12:50 +0200

> On 20 Jul 2017, at 9:56, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Gabriel,
> 

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.

> From: Gabriel Lopez [mailto:[email-masked] <mailto:[email-masked]>]
> Cc: Alejandro Pérez Méndez; [email-masked] <mailto:[email-masked]>; IPsecME WG; Rafa Marin Lopez

---

From: Gabriel Lopez <[email-masked]>
Date: Fri, 21 Jul 2017 15:18:48 +0200

Hi Yoav, Valery,

> El 20 jul 2017, a las 10:12, Yoav Nir <[email-masked]> escribió:
> 
>> 
>> On 20 Jul 2017, at 9:56, Valery Smyslov <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Gabriel,
>>  

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 cont…

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.