Subject: [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection and SD-WAN

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jul 2016 18:33:10 +0200

Hi

In addition to what we said at the meeting, I’d like to mention that what the draft is proposing seems to be a subset of what SD-WAN vendors are doing. I apologize in advance for using the terms NSF and SD-WAN gateway interchangeably.

For those not familiar, Wikipedia has a so-so article about it: https://en.wikipedia.org/wiki/SD-WAN

In an SD-WAN setup, the security function is configured by the SD-WAN controller to have one or more virtual links for particular target networks.  As an example, the NSF might have three ways of getting to subnet 192.0.2.0/24
:
Using an MPLS link. This is the most expensive way
Using the Internet through an LTE modem. This is moderately expensive as well.
Using the Internet through a DSL link. This is the cheapest way. If at all possible, you would want to use this.

An SD-WAN gateway uses some measurement technique to evaluate some properties of each one of these physical links: RTT, jitter, packet loss.

The SD-WAN gateway receives policy from the controller. Such a policy may require that VoIP traffic go over the cheapest link where RTT is no more than 50ms and jitter is no more than 50ms. Video traffic might be more stringent on jitter but less stringent on RTT. Web transactions are fine with any RTT and jitter as long as packet loss is small. There’s more to it and you can find more with a Google search and at the vendors’ websites. One part is dynamic discovery of peers for large environments.

Most of SDN started in academia and migrated to the “real world”. In this particular case it seems that private industry is somewhat ahead. I don’t think we’d want to standardize a partial solution here. It’s probably better for us to try to get all of the functions that people expect under the buzzword “SD-WAN”.

I’m not sure either whether this is work for this working group or whether it justifies its own working group. I’m also not sure how we can attract the SD-WAN vendors to the IETF to participate. But I think we should be “thinking big” on this.

Yoav

---

From: David Carrel <[email-masked]>
Date: Fri, 22 Jul 2016 12:02:27 +0200

I am quite interested in the notion of integrating IKE (or IKE-like)
security and functionality into the SD-WAN controller messaging.  My
company does this now, though not in a standard way.  All IPSEC key
management comes from the SD-WAN controller.  It is tricky to do this
right, but it can be done and will continue to be done.  It can be highly
scalable.  I'd like to see us work on doing this in a standard way and I'm
happy to help out.

Several concerns were raised in the meeting, and unfortunately there wasn't
time for all comments then.  While I think the concerns raised are good
concerns, I also believe they are demonstrably addressable.  Yes, this
needs to be done carefully!!

Additionally to Yoav's point, yes there is additional information that
SD-WAN controllers need to send.  Some of this will be proprietary.  Yet
much of it will become standard over time.  I don't think we can enumerate
all of this now or even soon.  It seems there are efforts underway to do
this.  But we can start with a flexible way to add this incrementally over
time.

Dave

On Thu, Jul 21, 2016 at 6:33 PM, Yoav Nir <[email-masked]> wrote:

> Hi
>
> In addition to what we said at the meeting, I’d like to mention that what
> the draft is proposing seems to be a subset of what SD-WAN vendors are
> doing. I apologize in advance for using the terms NSF and SD-WAN gateway
> interchangeably.
>
> In an SD-WAN setup, the security function is configured by the SD-WAN
> controller to have one or more virtual links for particular target
> networks.  As an example, the NSF might have three ways of getting to
> subnet 192.0.2.0/24
> :
>
>    1. Using an MPLS link. This is the most expensive way
>    2. Using the Internet through an LTE modem. This is moderately
>    expensive as well.
>    3. Using the Internet through a DSL link. This is the cheapest way. If
>    at all possible, you would want to use this.
>
>
> An SD-WAN gateway uses some measurement technique to evaluate some
> properties of each one of these physical links: RTT, jitter, packet loss.
>
> The SD-WAN gateway receives policy from the controller. Such a policy may
> require that VoIP traffic go over the cheapest link where RTT is no more
> than 50ms and jitter is no more than 50ms. Video traffic might be more
> stringent on jitter but less stringent on RTT. Web transactions are fine
> with any RTT and jitter as long as packet loss is small. There’s more to it
> and you can find more with a Google search and at the vendors’ websites.
> One part is dynamic discovery of peers for large environments.
>
> Most of SDN started in academia and migrated to the “real world”. In this
> particular case it seems that private industry is somewhat ahead. I don’t
> think we’d want to standardize a partial solution here. It’s probably
> better for us to try to get all of the functions that people expect under
> the buzzword “SD-WAN”.
>
> I’m not sure either whether this is work for this working group or whether
> it justifies its own working group. I’m also not sure how we can attract
> the SD-WAN vendors to the IETF to participate. But I think we should be
> “thinking big” on this.
>
> Yoav
>
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Jul 2016 18:26:48 +0300

Hi, Dave.

On 22 Jul 2016, at 1:02 PM, David Carrel <[email-masked]> wrote:

> I am quite interested in the notion of integrating IKE (or IKE-like) security and functionality into the SD-WAN controller messaging.  My company does this now, though not in a standard way.  All IPSEC key management comes from the SD-WAN controller.  It is tricky to do this right, but it can be done and will continue to be done.  It can be highly scalable.  I'd like to see us work on doing this in a standard way and I'm happy to help out.
> 
> Several concerns were raised in the meeting, and unfortunately there wasn't time for all comments then.  While I think the concerns raised are good concerns, I also believe they are demonstrably addressable.  Yes, this needs to be done carefully!!
> 
> Additionally to Yoav's point, yes there is additional information that SD-WAN controllers need to send.  Some of this will be proprietary.  Yet much of it will become standard over time.  I don't think we can enumerate all of this now or even soon.  It seems there are efforts underway to do this.  But we can start with a flexible way to add this incrementally over time.

So I will be glad to start a conversation on this list about what the IETF can do about defining IPsec from a controller. 

I think the first question is “who’s tunnel is it anyway”. The use cases in section 9 of draft-abad (except 9.3) see the IPsec tunnel as a service provided by the ISP. With the two architectures they propose (key exchange protocol on the controller vs key exchange protocol on the NSF) either the keys or credentials are provided by the ISP. This is one way to do this, but the more common case (at least for me) is that the organization (or “Enterprise”) that provides the VPN, while the ISP is the entirely replaceable “middle”. Many enterprises (medical, financial, others) cannot let the ISP see their cleartext, so both the controller function and the NSF function should (IMO) be owned by the enterprise.

Another question raised at the meeting is about whether the controller provides configuration and credentials (SPD+PAD) and lets the NSF negotiate keys, or whether the controller provides the actual keys. I like the former better for some of the reasons mentioned at the meeting, but also for forward secrecy. If the controller never gets access to traffic keys, it cannot leak them. It’s usually better to not transmit secret keys over the network.

A third question that is worth considering is route-based vs policy-based (or domain-based) IPsec. Generally there are two modes of configuring IPsec. One is where the NSFs are pre-configured with each other’s protected domain, so they know what flows to encrypt and what flows not to encrypt. The other mode sets up a tunnel and allows a routing protocol running over said tunnel decide what does and what does not go through the tunnel.  The draft mentions only domain-based VPN, which is a fine decision to make, but if this group would like to work on controlling IPsec, it should at least acknowledge that both modes exist, and pick one explicitly.

Regards,

Yoav

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 28 Jul 2016 12:12:20 +0200

Hi Yoav:

> El 27 jul 2016, a las 17:26, Yoav Nir <[email-masked]> escribió:
> 
> Hi, Dave.
> 

[Rafa] That would be great.

> I think the first question is “who’s tunnel is it anyway”. The use cases in section 9 of draft-abad (except 9.3) see the IPsec tunnel as a service provided by the ISP. With the two architectures th…

[Rafa] That is fine. Section 9 are just possible uses cases (examples) that can be extended or modified. In the end, the idea of the I-D is to show that there is controller providing IPsec information to the NSF.

> Another question raised at the meeting is about whether the controller provides configuration and credentials (SPD+PAD) and lets the NSF negotiate keys, or whether the controller provides the actua…

[Rafa] Two comments here. 1) I see the controller as a trusted entity, otherwise it should not be trusted to any operation (not only IPsec-related). Thus, providing keying material should not be a problem. Even in case the NSFs negotiate keys, IKE credentials may be provided by the controller. Moreover, with the right permissions, the controller could access to the SAD state and observe keys there. 2) Distributing key material will be performed over a secure channel between the controller and the NSF, so no secret keys in clear are transmitted over the network.

Btw, with my comments I am not trying to move forward case 1 or case 2, I am just trying to highlight that both models will have advantages and disadvantages and it would be worthy studying both.

> A third question that is worth considering is route-based vs policy-based (or domain-based) IPsec. Generally there are two modes of configuring IPsec. One is where the NSFs are pre-configured with…

[Rafa] Agree. In any case, the I-D is flexible in this sense, so we should definitely add this to the I-D. In fact, we paid more attention to the structures/databases in IPsec that the controller needs to handle in the NSF. As I see it, in the I-D we reflected a configuration step “Flow Protection Policies (1)” done by the administrator with the northbound interface. The controller can decide to do route-based or policy-based IPsec and, in the end, apply what it is required in the NFSs involved. 

What do you think?

Best Regards.

> Yoav

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

---

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 28 Jul 2016 08:43:11 -0400

> [Rafa] Agree. In any case, the I-D is flexible in this sense, so we should definitely add this to the I-D. In fact, we paid more attention to the structures/databases in IPsec that the controller n…

While it would certainly be good to evaluate route-based vs policy-based
flow-selectors for the tunnel, it seems a bit inappropriate to do this using
a routing protocol, because IPsec flow selectors can easily be richer than
just end-point addresses. As rfc 5406 points out, the routing protocol
itself may be a candidate for IPsec.

--Sowmini