Re: [IPsec] My view of the requirements from AD-VPN

Yoav Nir <ynir.ietf@gmail.com> Fri, 21 March 2014 23:25 UTC

Return-Path: <ynir.ietf@gmail.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 EC0FD1A06DF for <ipsec@ietfa.amsl.com>; Fri, 21 Mar 2014 16:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 KzIQMTicHJY8 for <ipsec@ietfa.amsl.com>; Fri, 21 Mar 2014 16:25:30 -0700 (PDT)
Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D0F931A0444 for <ipsec@ietf.org>; Fri, 21 Mar 2014 16:25:29 -0700 (PDT)
Received: by mail-ee0-f48.google.com with SMTP id b57so2315750eek.35 for <ipsec@ietf.org>; Fri, 21 Mar 2014 16:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TLNUZh7Z/Y01oRM0VGexTNCCJytjlufRxLjtbR4Y3ew=; b=pfcRrW7I19XbVv/FTxBJynDnAdiHgHtQy/UrS9AwgQsR9/cz2RJM1vXu5WDwOEQepC WoWjHUP8lntzB2sXlqnqorK4znCe+jjWfkyYDELJY0Zdr8c4JzNe1IIR7FNjA4dhP+58 hrShuK4cnLoAPVQr5jCYitMstmps1A8YxAbEZqKkdluyA20SQjlk+kLcPn1O9CfOzW5m 4em2rT54o0OWp5GqX55UYU0DA3GbV0ut8EkIxxDOam5KhbDJuExVhJ80mhnQ6fiCW1Z8 +7GxTlhvA7VzhNhSlx/6POm7ri1SdmAmY5FqPD3myyAbvJx41rWY+rdGUCcunFixPqvM j4JQ==
X-Received: by 10.14.126.73 with SMTP id a49mr50692093eei.46.1395444319841; Fri, 21 Mar 2014 16:25:19 -0700 (PDT)
Received: from [192.168.1.100] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id x45sm14846521eeu.23.2014.03.21.16.25.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 16:25:18 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <532C74D6.8000208@gmail.com>
Date: Sat, 22 Mar 2014 01:25:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CD37189-69B4-4BE8-ACD4-D6CC8E6C4146@gmail.com>
References: <CFEEA351-5C27-44DE-9B3E-5FFF35C87732@gmail.com> <532C74D6.8000208@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/iHrQmuXir-9MIcFN6LSGZL6LByU
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] My view of the requirements from AD-VPN
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: Fri, 21 Mar 2014 23:25:32 -0000

On Mar 21, 2014, at 7:20 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Hi Yoav,
> 
> I like your attempt at reducing the requirement set to the minimum.
> 
> Parts of the text I think do not distinguish well between IPsec hosts (such as remote access clients) and (simple) hosts, that are non-IPsec hosts protected behind a gateway. Presumably simple hosts will be unaffected by this protocol.
> 
> And in the spirit of minimizing the set of requirements: isn't your #3 solution components just an optimization? I think in many cases a protocol that includes #1 and #2 but not #3 could be sufficient for scale. And then #3 could be added as an extension. Or we can decide that we do not need a fully general #3, and we're good enough with simple shortcuts between two spokes of the same hub.
> 

Without #3 we are left with the easy configuration - a few hubs meshed together, and all other nodes know about 1 hub each. This has some issues:
 - The hubs have very large peak loads.
 - A failure of a hub is catastrophic - the VPN goes away.
 - Increased latency because traffic goes through multiple hops.

Both of these points together make the hubs insanely expensive. They need to have hardware (both in the gateways themselves and in the network links) that will carry the peak load without introducing even more latency, and they need to have enough redundancy to practically never go down. Both of these are solved problems, but they’re problems you need to throw a lot of money at to solve. 

So without #3, I am not sure the effort is worthwhile. As for a lightweight #3, that only shortcuts the spokes of a single hub, it’s better than nothing, but I can use the example of my company (medium sized by any measure) that still manages to have two hubs. I’d rather that VoIP calls between two remote access clients connected to the different hubs (think me and Bob) not have to go through both hubs.

Yoav