Subject: [IPsec] IPsec and SDN

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

Hi.

This may be of interest to this working group.

The I2NSF working group is meeting this afternoon at 13:30

On the agenda ([1]) there’s a 10-minute slot for controlling IPsec endpoints using SDN ([2]).

I think this draft has two issues:
Their IKE-less case (case #2) has session keys generated on the controller and forwarded to the IPsec endpoints. IMO this introduces new ways for the keys to leak.
The information flow in the draft is all from the controller to the endpoints. The controller is assumed to a-priori know the entire topology of all endpoints. IMO this is not realistic for VPNs where often the addresses are allocated by third party ISPs.

I think any SDN or SDN-like solution for populating the SPD and PAD would need to have information flowing from the endpoints to the controller about the protected domain of that endpoint. Before that you can’t generate the SPDs.

OTOH this group failed in creating something like that in the AD-VPN work item. Several companies are now offering their own “SD-WAN” solution that is partly about automatic configuration of IPsec tunnels.

So in case you’re interested, you can come to the I2NSF meeting and hear their presentation.

Yoav

[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt <https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt>
[2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 <https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Jul 2017 10:34:22 +0200

ACE on Monday also mentioned this "SPDs without IKE" option. I expressed my concern that they believe IKE is only about sharing SPDs and keys and warned them against things like devices without batteries restarting and getting the same values and end up re-using the same counter for AEAD algorithms.

Sent from my iPhone

> On Jul 18, 2017, at 10:29, Yoav Nir <[email-masked]> wrote:
> 
> Hi.
> 
> [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt
> [2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Jul 2017 10:45:04 +0200

We’re going to have a screaming match tomorrow at TLS about forward secrecy.

You don’t have forward secrecy if the session keys were generated by a third party. You’re replacing IKE with a three-party system.

But I am more worried about the second issue. I’m not sure SDN is the right model for configuring IPsec.

Yoav

> On 18 Jul 2017, at 10:34, Paul Wouters <[email-masked]> wrote:
> 
> On Jul 18, 2017, at 10:29, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi.
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 18 Jul 2017 13:10:45 +0200

For key management you might want to refer them to the old but still 
useful RFC 4107 <https://www.rfc-editor.org/rfc/rfc4107.txt>.

Thanks,

     Yaron

On 18/07/17 10:45, Yoav Nir wrote:
> You don’t have forward secrecy if the session keys were generated by a 
> third party. You’re replacing IKE with a three-party system.
>
>> On 18 Jul 2017, at 10:34, Paul Wouters <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> ACE on Monday also mentioned this "SPDs without IKE" option. I 
>> expressed my concern that they believe IKE is only about sharing SPDs 
>> and keys and warned them against things like devices without 
>> batteries restarting and getting the same values and end up re-using 
>> the same counter for AEAD algorithms.
>>
>> Sent from my iPhone
>>
>>>  1. Their IKE-less case (case #2) has session keys generated on the
>>>     controller and forwarded to the IPsec endpoints. IMO this
>>>     introduces new ways for the keys to leak.
>>>  2. The information flow in the draft is all from the controller to
>>>     the endpoints. The controller is assumed to a-priori know the
>>>     entire topology of all endpoints. IMO this is not realistic for
>>>     VPNs where often the addresses are allocated by third party ISPs.
>>>
>>>
>>> I think any SDN or SDN-like solution for populating the SPD and PAD 
>>> would need to have information flowing from the endpoints to the 
>>> controller about the protected domain of that endpoint. Before that 
>>> you can’t generate the SPDs.
>>>
>>> OTOH this group failed in creating something like that in the AD-VPN 
>>> work item. Several companies are now offering their own “SD-WAN” 
>>> solution that is partly about automatic configuration of IPsec tunnels.
>>>
>>> [2] 
>>> https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03
>>>

---

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

Hi Yoav:

Thank you for these comments and pointing out our work. We will have the opportunity to discuss in the meeting.

Nevertheless, since we are not sure if we will have time enough to discuss, let me send some initial comments inline. 

> El 18 jul 2017, a las 10:29, Yoav Nir <[email-masked]> escribió:
> 
> Hi.
> 

[Rafa] Regarding this, the SDN controller is considered to be a trust party. In fact, the assumption is there is already a security association (think about NETCONF+SSL/SSH) with the NSF. 

> The information flow in the draft is all from the controller to the endpoints. The controller is assumed to a-priori know the entire topology of all endpoints. IMO this is not realistic for VPNs wh…

[Rafa] Basically in a SDN model , the SDN controller needs to have a knowledge of the topology , specifically of those devices it configures. In fact, there is a secure registration process of the NSF with the controller previous to any management process. That is a basic in SDN landscape.

> I think any SDN or SDN-like solution for populating the SPD and PAD would need to have information flowing from the endpoints to the controller about the protected domain of that endpoint. Before t…

[Rafa] I think you are missing the fact the administrator will send a general flow protection policy to the SDN controller using the northbound interface of the SDN controller. Based on that information the SDN will create the SPD and PAD entries. Thus, I do not see any problem on creating the SPDs based on that information coming from the administrator.

> OTOH this group failed in creating something like that in the AD-VPN work item. Several companies are now offering their own “SD-WAN” solution that is partly about automatic configuration of IPsec…

[Rafa] That’s why we should think to standardize this.

Best Regards.
> [2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 <https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03>

-------------------------------------------------------
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 13:46:02 +0200

Hi Paul:

What are the same values you have in mind? and why is that the device has to end up re-using the same counter?

Best regards.

> El 18 jul 2017, a las 10:34, Paul Wouters <[email-masked]> escribió:
>

---

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

Hi

> On 18 Jul 2017, at 13:35, Rafa Marin-Lopez <[email-masked]> wrote:
> 
> Hi Yoav:
> 
>> El 18 jul 2017, a las 10:29, Yoav Nir <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> Hi.
>> 

The old joke is that three people can keep a secret as long as two of them are dead. Any three-party system is more fragile than a two party system. Key transport also increases the attack surface. Yes, you can make the claim that any vulnerability that would leak or compromise the session key would just as easily be able to compromise long-term keys (as in case 1), but the system does end up more fragile.

> [Rafa] Basically in a SDN model , the SDN controller needs to have a knowledge of the topology , specifically of those devices it configures. In fact, there is a secure registration process of the…

Then perhaps an SDN model is not appropriate for VPNs. Imagine a corporation with many branches, like Starbucks or the Gap. They open a new store in some shopping center. Depending on how the network there is organized, the new store gets its network configuration either from the shopping center of from a local ISP. The automated way of doing things (which is used in the SD-WAN products) is for the VPN gateway in the store to send its routing information to the center (using a routing protocol or some other protocol), which allows the center to build a so-called big picture. This big picture can be the basis of the SPD entries pushed by the center to the branch VPN gateway.

> [Rafa] I think you are missing the fact the administrator will send a general flow protection policy to the SDN controller using the northbound interface of the SDN controller. Based on that inform…

Right. And the administrator doesn’t have that information. In the Gap example, the center is in San Francisco. The routing information exists in the router that is in the new location (say, Prague). If the technology assumes that the administrator knows everything, we need to make it happen by having the manager of the new store look at the routing table on the VPN gateway and sending a screenshot to the administrator. That is not automated.

It’s fine to have the administrator tell the controller whether branches should talk directly to each other or only directly to the datacenter, but it doesn’t scale to have and maintain all the relevant subnets at the center. That works within the datacenter where the administrator actually controls things.

> [Rafa] That’s why we should think to standardize this.

I agree, but I’m not sure this is the right solution.

Yoav