Subject: [IPsec] your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

From: Linda Dunbar <[email-masked]>
Date: Thu, 7 Sep 2017 19:33:07 +0000

Yoav,

At yesterday's I2NSF Interim meeting, you described an example of Gap having thousands of locations and most of them are in a mall where public network is available. You said that typically the VPN gateway placed in the store has no knowledge of the global network topology, nor does it know where the controller is located.

Today, many vendors' remote CPEs support ONUG's SD-WAN "Zero-touch deployment" requirement, where the remote CPEs devices can be connected to its controller via barcode scan/email/etc.

Does it solve the problem?

Thanks,
Linda

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Sep 2017 16:18:56 -0400

Linda Dunbar <[email-masked]> wrote:
    > Today, many vendors’ remote CPEs support ONUG’s SD-WAN “Zero-touch
    > deployment” requirement, where the remote CPEs devices can be connected to
    > its controller via barcode scan/email/etc.

Dunno.
I googled for ONUG SD-WAN Zero-Touch, and got:

https://opennetworkingusergroup.com/wp-content/uploads/2015/05/ONUG-SD-WAN-WG-Whitepaper_Final1.pdf

but it was a 404.  I tried the google cache, but the documents were not
useful.  Perhaps you could give us an Openstand reference we can use.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 7 Sep 2017 20:42:15 +0000

For example, here is one vendor's implementation (I found on the web, if you equate the "Public Cloud Platform" to the public internet in a shopping mall).

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]]
Sent: Thursday, September 07, 2017 3:19 PM
To: Linda Dunbar <[email-masked]>
Cc: Yoav Nir <[email-masked]>; [email-masked]; IPsecME WG <[email-masked]>
Subject: Re: [IPsec] your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

Dunno.

but it was a 404.  I tried the google cache, but the documents were not useful.  Perhaps you could give us an Openstand reference we can use.

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Sep 2017 08:36:18 +0300

Hi, Linda

The reason I brought up the Gap was because they described their network in a Packet Pusher’s episode ([1]).

And the solution for them was some vendor’s SD-WAN solution. As far as I can tell, each vendor’s SD-WAN solution is proprietary and non-interoperable with other vendors’ SD-WAN solution.

That vendor (Viptela, since then merged with Cisco) uses BGP on a large scale to pass configuration information between CPE devices and data center devices, and an SD-WAN controller to manage it all.  Other vendors use other technology to learn protected domains, and as I mentioned, there was an attempt to standardize something in IPsecME a few years ago, but that failed.

The draft we were discussing has no way to transfer domain information from the CPEs to the controller or to other CPEs, so I assume that it does not fit this use case.  At least not in its current form.

Yoav

[1] http://packetpushers.net/podcast/podcasts/show-274-packet-pushers-live-viptela-three-real-world-sd-wan-deployments-sponsored/ <http://packetpushers.net/podcast/podcasts/show-274-packet-pushers-live-viptela-three-real-world-sd-wan-deployments-sponsored/>

> On 7 Sep 2017, at 22:33, Linda Dunbar <[email-masked]> wrote:
> 
> Yoav,
> 
> At yesterday’s I2NSF Interim meeting, you described an example of Gap having thousands of locations and most of them are in a mall where public network is available. You said that typically the VPN gateway placed in the store has no knowledge of the global network topology, nor does it know where the controller is located.
> 
> Today, many vendors’ remote CPEs support ONUG’s SD-WAN “Zero-touch deployment” requirement, where the remote CPEs devices can be connected to its controller via barcode scan/email/etc.
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 8 Sep 2017 16:07:26 +0000

Yoav,

Not having interoperable solution for SD-WAN is a huge issue for enterprises. That is one of the main reasons that SD-WAN deployment has been slow since its inception in 2012.
In ONUG (Open Network User Group) where majority of participants are enterprises, it was overwhelmingly voted the need for interoperable SD-WAN solutions. As the result, the ONUG started a SD-WAN Exchange WG. However, ONUG is not a standard organization. Their main goal is to identify use cases, requirements, etc.

Well, SD-WAN has other issues, like SD-WAN solution builds point-to-point overlay paths between two end-points (or branch offices) as alternative paths. However, most enterprises need multi-point interconnection among multiple locations, as done by MPLS L2/L3-VPN. Using SD-WAN overlay paths to achieve any to any mesh interconnection among all branches not only requires all branches CPEs to be upgraded, but also require CPEs to manage routing among other CPEs located at other locations, which dramatically increase the complexity of the CPEs. Almost like going back to the complexity of frame relay where each CPE needs maintain mesh routing for all destinations.

Linda

From: Yoav Nir [mailto:[email-masked]]
Sent: Friday, September 08, 2017 12:36 AM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; IPsecME WG <[email-masked]>
Subject: Re: your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

Hi, Linda

Yoav

[1] http://packetpushers.net/podcast/podcasts/show-274-packet-pushers-live-viptela-three-real-world-sd-wan-deployments-sponsored/

On 7 Sep 2017, at 22:33, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Yoav,

Thanks,
Linda

---

From: "Mike Sullenberger (mls)" <[email-masked]>
Date: Thu, 14 Sep 2017 00:30:13 +0000

Linda,

If you want to securely encrypt traffic between endpoints then you are going to need to build point-point encrypted tunnels between these endpoints, this is the main reason that SD-WAN implementations use either a full-mesh or dynamic-mesh of point-point tunnels.  If you rely on a multi-point connection model then you end up using a group key encryption model which is less secure (many customers will not accept using group keys).

Mike.

[http://www.cisco.com/content/dam/m/en_us/signaturetool/images/banners/Events/cisco_live_las_vegas/email-signature-clus-17-lv-indigo.jpg]<http://www.ciscolive.com/>

Mike Sullenberger    CCIE-2902
[email-masked]<mailto:[email-masked]>
Tel: +1 408 527 8702
Cisco.com

DISTINGUISHED ENGINEER. ENGINEERING
Product Development
Cisco Systems, Inc.

[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.

From: IPsec [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, September 08, 2017 9:07 AM
To: Yoav Nir <[email-masked]>
Cc: [email-masked]; IPsecME WG <[email-masked]>
Subject: Re: [IPsec] your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

Yoav,

Linda

From: Yoav Nir [mailto:[email-masked]]
Sent: Friday, September 08, 2017 12:36 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; IPsecME WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

Hi, Linda

Yoav

Yoav,

Thanks,
Linda

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Sep 2017 14:25:00 -0400 (EDT)

On Thu, 14 Sep 2017, Mike Sullenberger (mls) wrote:

> If you want to securely encrypt traffic between endpoints then you are going to need to build point-point encrypted tunnels
> between these endpoints, this is the main reason that SD-WAN implementations use either a full-mesh or dynamic-mesh of
> point-point tunnels.  If you rely on a multi-point connection model then you end up using a group key encryption model which
> is less secure (many customers will not accept using group keys).

See also Opportunistic IPsec, which is a way of creating a mesh with
IPsec using some kind of central (X.509) or decentral (DNSSEC)
authentication. See:

https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec
https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec_using_LetsEncrypt

http://events.linuxfoundation.org/sites/events/files/slides/LinuxSecuritySummit-2016-OE-16x9.pdf

https://docs.openshift.com/container-platform/3.5/admin_guide/ipsec.html

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.4/html/cluster_administration/admin-guide-ipsec

Paul

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Sep 2017 11:01:28 -0400

> IPsec using some kind of central (X.509) or decentral (DNSSEC)

And it's important to note that the reverse map that is used doesn't have to
be the public (DNS) one!

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Paul Wouters <[email-masked]>
Date: Fri, 15 Sep 2017 11:13:55 -0400 (EDT)

> And it's important to note that the reverse map that is used doesn't have to

Right. But also we support the forward DNS. That is libreswan can also
use the IDr for a forward DNS lookup, which can also be an internal-only
zone. I believe in that case we also then do another lookup of the IDr
in the forward to ensure it includes an A/AAAA record to the IP we are
connecting to.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Sep 2017 20:37:15 -0400

> in the forward to ensure it includes an A/AAAA record to the IP we are

What's happening to your document about this?

---

From: Paul Wouters <[email-masked]>
Date: Fri, 15 Sep 2017 23:30:26 -0400 (EDT)

> What's happening to your document about this?

Once it gains a little more experience and we see some interest for
interop, I'll start a document. I do see an increase in IPsec mesh
networking.

Paul

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 18 Sep 2017 22:16:04 +0000

Paul,

If we need to use IPsec tunnels to connect a group of CPE devices, (as shown in the figure I sent earlier), do you still need DNS? Or the Key management will be managed by the "Zero Touch Deployment Service" in the figure below?

Thanks, Linda

-----Original Message-----
From: Paul Wouters [mailto:[email-masked]]
Sent: Thursday, September 14, 2017 1:25 PM
To: Mike Sullenberger (mls) <[email-masked]>
Cc: Linda Dunbar <[email-masked]>; [email-masked]; IPsecME WG <[email-masked]>; Yoav Nir <[email-masked]>
Subject: Re: [IPsec] your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

On Thu, 14 Sep 2017, Mike Sullenberger (mls) wrote:

> If you want to securely encrypt traffic between endpoints then you are
> going to need to build point-point encrypted tunnels between these
> endpoints, this is the main reason that SD-WAN implementations use
> either a full-mesh or dynamic-mesh of point-point tunnels.  If you rely on a multi-point connection model then you end up using a group key encryption model which is less secure (many customers will not accept using group keys).

See also Opportunistic IPsec, which is a way of creating a mesh with IPsec using some kind of central (X.509) or decentral (DNSSEC) authentication. See:

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Sep 2017 18:31:59 -0400 (EDT)

On Mon, 18 Sep 2017, Linda Dunbar wrote:

> If we need to use IPsec tunnels to connect a group of CPE devices, (as shown in the figure I sent earlier), do you still need DNS? Or the Key
> management will be managed by the "Zero Touch Deployment Service" in the figure below?

You can use any protocol you want to validate the public key
needed. It can come from DNSSEC, a supplied X.509 CA cert, or you can
specify/implement another secure method. IKE allows for the pubkey to
be transmited and received. External processes can then determine the
authenticity of the pubkey (along with the ID presented)

The idea remains the same, you connect to a remote hostname or IP,
are given an ID and you use that ID to somehow/somewhere lookup what
pubkey belongs to that ID. Possibly also match that ID to the IP as
additional assurance. Then once the pubkey is trusted out-of-band,
you use it in-band to authenticate.

It could be querying a blockchain, confirming a bitcoin payment, a
centralised DNS zone,  the LetsEncrypt CA, a hardcoded list of pubkeys,
etc.

If you have the ID of entities you connect to (eg a hostname) then
things are easier to lookup then if you only know and IP address, and are
then given an ID. Because then you need to somehow verify the ID-IP set.
Otherwise, one node in a network can take over another node's IP
address, and present its own (valid!) credentials.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 19 Sep 2017 06:44:15 +0300

Hi, Paul

> On 19 Sep 2017, at 1:31, Paul Wouters <[email-masked]> wrote:
> 

This is what you do if all you have is a DNS.

However, if you have this SDN controller/SDWAN controller/Zero-Touch deployment thingie, why do you need public keys at all. You can just have the controller provision the CPEs with identities and pair-wise shared secrets plus addresses and domains of peers. Then you don’t need any PKI, lookups DNSSEC and the like.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Sep 2017 16:56:14 -0400

> This is what you do if all you have is a DNS.

DNS is a really well established distributed database with well established
and secure implementations which caches really well.  It has decades of
proven interoperation.

    > However, if you have this SDN controller/SDWAN controller/Zero-Touch
    > deployment thingie, why do you need public keys at all. You can just
    > have the controller provision the CPEs with identities and pair-wise
    > shared secrets plus addresses and domains of peers. Then you don’t need
    > any PKI, lookups DNSSEC and the like.

yes, the highly available SDN controller can configure all the information,
remembering to update all the nodes regularly with new information.  Or the
SDN controller could simply do exactly the same thing using DNS zone
transfers using private DNS zones. (whether forward or reverse,etc.)
No PKI. DNSSEC if you like, TSIG authenticated zone transfers otherwise, and
numerous competing services that can provide DDoS resistance so that the SDN
controller doesn't have to be so available.

I don't really see the difference except new people can get paid to
re-discover the last 30 years of mistakes in DNS implementations.