[IPsec] AD-VPN Protocol Selection

"Harms, Patrick" <Patrick.Harms@vwfs.com> Mon, 03 February 2014 14:05 UTC

Return-Path: <prvs=1045d51f8=patrick.harms@vwfs.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C847D1A021C for <ipsec@ietfa.amsl.com>; Mon, 3 Feb 2014 06:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3JakVKpyw0P for <ipsec@ietfa.amsl.com>; Mon, 3 Feb 2014 06:05:31 -0800 (PST)
Received: from mx1.vwfsag.de (mx1.vwfsag.de [193.25.183.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3451A05C5 for <ipsec@ietf.org>; Mon, 3 Feb 2014 04:35:36 -0800 (PST)
Received: from unknown (HELO sr-web-vsmgw2.fs01.vwf.vwfs-ad) ([10.41.77.140]) by sr-web-mgw2.fs01.vwf.vwfs-ad with ESMTP; 03 Feb 2014 13:35:34 +0100
Received: from sr-web-vsmgw2.fs01.vwf.vwfs-ad (localhost [127.0.0.1]) by sr-web-vsmgw2.fs01.vwf.vwfs-ad (VWFS) with ESMTP id EDAB286075 for <ipsec@ietf.org>; Mon, 3 Feb 2014 13:35:33 +0100 (CET)
Received: from FSDEBSSXC003.fs01.vwf.vwfs-ad (fsdebssxc003.fs01.vwf.vwfs-ad [10.43.13.229]) by sr-web-vsmgw2.fs01.vwf.vwfs-ad (VWFS) with ESMTP id E0D9686067 for <ipsec@ietf.org>; Mon, 3 Feb 2014 13:35:33 +0100 (CET)
Received: from FSDEBSSXD111.fs01.vwf.vwfs-ad ([169.254.5.32]) by FSDEBSSXC003.fs01.vwf.vwfs-ad ([10.43.13.229]) with mapi id 14.03.0158.001; Mon, 3 Feb 2014 13:35:33 +0100
From: "Harms, Patrick" <Patrick.Harms@vwfs.com>
To: "'ipsec@ietf.org'" <ipsec@ietf.org>
Thread-Topic: AD-VPN Protocol Selection
Thread-Index: Ac8g29viSNWMxCSdS+mwPoqNzCPObQ==
Date: Mon, 03 Feb 2014 12:35:33 +0000
Message-ID: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.43.0.124]
Content-Type: multipart/alternative; boundary="_000_87BCDFB0B867FB4A85DB44EE8946E2458407E6F6FSDEBSSXD111fs0_"
MIME-Version: 1.0
Subject: [IPsec] AD-VPN Protocol Selection
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 14:05:35 -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.