Subject: [IPsec] AD-VPN Protocol Selection

From: "Harms, Patrick" <[email-masked]>
Date: Mon, 3 Feb 2014 12:35:33 +0000

Dear all,

My name is Patrick and I am working as a system architect. One of my current jobs is to build a vpn architecture that keeps the manual configuration efforts as low as possible and as simple as possible. I have tested and played around with a range of vpn solutions and would like to share my personal opinion to this mailing list.

My preference is on draft-detienne-dmvpn-00. Because of dmvpn is:

- is allowing to add 'spokes' without configuration changes on the 'hub' devices (8.1 dmvpn draft)
For me, this is an important point. Changing the configuration on the hub routers, everytime a spoke is added to the network, would make the rollout process to complex and is a possible source of failures.

- scales with multiple 'hubs' linearly
Also an important point. For me, it is essential to scale out the platform when the amount of spokes is increasing. So I am able to start with a size of the platform that fits my needs, but I am able to raise the amount of spokes without changing the whole design.

- uses routing protocols for redundancy and path manipulations (8.3 dmvpn draft)
Using routing protocols or the interaction with routing protocols gives me the possibility for a tighter integration in existing networks. I am also able to use existing technologies for redundancy and path manipulations.

Based on the theories (advpn draft and dmvpn) and real world experience (dmvpn), I would favor dmvpn, because the handling and operating sounds less complex. (eg. lower amount of steps in tunnel initiation, single logical interface for tunnel termination etc.)

Additional points out of my perspective, dmvpn:

- has an installed basis
- is scalable up to 15.000 spokes (tested by my own)
- interoperates with the existing infrastructure due to use of dynamic routing protocols (tested by my own)
- interoperates with load balancers of multiple vendors (tested by my own) (linearly hub scale out szenario)

Maybe these points are fulfilled by the advpn draft as well, but I have no personal experience.

Glossary:
dmvpn - http://tools.ietf.org/html/draft-detienne-dmvpn-01
advpn   - http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03

Best Regards,
Patrick

Volkswagen Financial Services AG
Sitz/Registered seat: Braunschweig
Registergericht/Registration court: Amtsgericht Braunschweig
HRB Nr./Commercial Register No.: 3790
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Hans Dieter Pötsch
Vorstand/Board of Management: Frank Witter (Vorsitzender/Chairman), Dr. Mario Daberkow, Frank Fiedler, Christiane Hesse, Dr. Michael Reinhart, Lars-Henner Santelmann

Wichtiger Hinweis: Die vorgenannten Angaben werden jeder E-Mail automatisch hinzugefügt und lassen keine Rückschlüsse auf den Rechtscharakter der E-Mail zu.
Important note: The above information is automatically added to this e-mail. This addition does not constitute a representation that the content of this e-mail is legally relevant and/or is intended to be legally binding upon Volkswagen Financial Services AG.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Feb 2014 10:02:30 -0500

> For me, this is an important point. Changing the configuration on the hub
    > routers, everytime a spoke is added to the network, would make the rollout
    > process to complex and is a possible source of failures.

I don't see how you can add a spoke in any system without requiring some
changes to at least one hub and/or the database/LDAP/etc. which keeps track
of all the spokes.

    > Based on the theories (advpn draft and dmvpn) and real world experience
    > (dmvpn), I would favor dmvpn, because the handling and operating sounds less
    > complex. (eg. lower amount of steps in tunnel initiation, single logical
    > interface for tunnel termination etc.)

Do you care about mobile (handheld) devices?

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Yoav Nir <[email-masked]>
Date: Mon, 3 Feb 2014 15:35:25 +0000

> changes to at least one hub and/or the database/LDAP/etc. which keeps track

 1. You set up a CA
 2. You accept connections from anyone presenting a certificate from that CA
 3. You trust everything they tell you in routing protocols.

As long as only well-behaved spokes get issued certificates, and they never get compromised, everything is fine.

> Do you care about mobile (handheld) devices?

Hey, those are higher-specced than the dual-pentium III at 800MHz with 512 MB or RAM that we were selling as a high-end gateway when I started working at Check Point :-)

Yoav

---

From: "Harms, Patrick" <[email-masked]>
Date: Tue, 4 Feb 2014 08:30:30 +0000

>>> For me, this is an important point. Changing the configuration on the
>>> hub routers, everytime a spoke is added to the network, would make
>>> the rollout process to complex and is a possible source of failures.
>>
>> I don't see how you can add a spoke in any system without requiring
>> some changes to at least one hub and/or the database/LDAP/etc. which
>> keeps track of all the spokes.
>
> 1. You set up a CA
> 2. You accept connections from anyone presenting a certificate from that CA  3. You trust everything they tell you in routing protocols.

Yes, that is one of my ideas. Set up a CA with an auto-enrollment process for the certificates (eg SCEP).
Of course, it is very important to have a solid process to handle with certificates, rollouts, stolen devices, operations etc.

>>> Based on the theories (advpn draft and dmvpn) and real world
>>> experience (dmvpn), I would favor dmvpn, because the handling and
>>> operating sounds less complex. (eg. lower amount of steps in tunnel
>>> initiation, single logical interface for tunnel termination etc.)
>>

I am on the lucky side, and do not have to care about handheld devices.

Patrick

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Feb 2014 10:39:11 -0500

>>> Do you care about mobile (handheld) devices?

Yoav> Hey, those are higher-specced than the dual-pentium III at 800MHz with
Yoav> 512 MB or RAM that we were selling as a high-end gateway when I
Yoav> started working at Check Point :-)

Yoav, your statement is nonsense.
It tells me that you have done no mobile development at all.
I have.  I've done IPsec on them too.

It's not about the amount of ram that they, or the speed of the device.
It about the access to the kernel.

Tell me, if I had you a corporate laptop computer (any specs you like), for
you which you can not install any device drivers or do anything as root or
"administrator", can you install your VPN software?   

Now, if I give you just enough root so that you can have a PF_KEY socket, can
you make something work?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 4 Feb 2014 17:40:14 +0000

> It about the access to the kernel.

Access to the kernel is at the discretion of the OS vendor. Both Microsoft and Apple are increasingly limiting the access that application developers have on so-called "desktop" operating systems.

> "administrator", can you install your VPN software?

I could not. Could you do it on Windows Phone 8 (that does not have its own native IPsec)?

> Now, if I give you just enough root so that you can have a PF_KEY socket, can

I could maybe make IPsec work, but not likely a GRE tunnel. However, Apple can do it on iOS, Microsoft can do it on Windows Phone, and a bunch of vendors can do it on Android. Big vendors like Cisco could probably get their client software to be blessed by the OS vendor. Tough?  Yes, but it's getting harder to develop for the likes of Mavericks and Windows 8.1 as well.

I'm not sure where you see a fundamental difference between desktop operating systems and mobile ones. They're all as locked down as the vendor wants them to be, and getting more locked down.

Yoav

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 5 Feb 2014 23:29:15 +0000

> On 03 Feb 2014, at 16:02, "Michael Richardson" <[email-masked]> wrote:
> 
> 

Not sure you have read the requirements but it is one of them.

The difficulty if the exercise is to be able to support both static and dynamic policies with a single protocol.

> Do you care about mobile (handheld) devices?

Somehow you must be mistaken in believing it can't be done.

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