Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements?

Paul Wouters <paul@nohats.ca> Mon, 18 May 2020 18:52 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779753A0D8E for <ipsec@ietfa.amsl.com>; Mon, 18 May 2020 11:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 Tgr68jzZpQbW for <ipsec@ietfa.amsl.com>; Mon, 18 May 2020 11:52:20 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD253A0D89 for <ipsec@ietf.org>; Mon, 18 May 2020 11:52:19 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49Qp6911T3zDkG; Mon, 18 May 2020 20:52:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1589827937; bh=b1fME2jAkRZri40Zjab3FZVD925I1m36VzSJXoL4UG8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lHso8D1gQejmUpyn974Yh0xFm3o4n/+e1ngS1/zA7obPRPtWzU6s8O+U0aOHO/kiB yxFmo7BSRVdySzCzxslBwHIaF0YMx1/0s9nu9Wjuy2X5h5TUtmaSl+t0jE0TOVlUS1 EBsbkbhrsdygt2MQyAvI+MzCLRxXqo/Rl8xbPyNM=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id CGrfV3iKUnK5; Mon, 18 May 2020 20:52:15 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 18 May 2020 20:52:15 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id AA4026020D59; Mon, 18 May 2020 14:52:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A6E2D65E5F; Mon, 18 May 2020 14:52:14 -0400 (EDT)
Date: Mon, 18 May 2020 14:52:14 -0400
From: Paul Wouters <paul@nohats.ca>
To: Linda Dunbar <linda.dunbar@futurewei.com>
cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
In-Reply-To: <SN6PR13MB233450103D13365702E14D7A85B80@SN6PR13MB2334.namprd13.prod.outlook.com>
Message-ID: <alpine.LRH.2.21.2005181442060.29444@bofh.nohats.ca>
References: <SN6PR13MB233450103D13365702E14D7A85B80@SN6PR13MB2334.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/MLej33g9v87MvckrFAdr-37C5eQ>
Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 18 May 2020 18:52:25 -0000

On Mon, 18 May 2020, Linda Dunbar wrote:

> We are experiencing the problems described in RFC 7018 (Auto-Discovery VPN Problem Statement and Requirements), i.e. the  problem of enabling a large number of peers
> (primarily Gateway) to communicate directly using IPsec to protect the traffic between them.

unfortunately, standarization failed because vendors wanted their own
solution standarized, and the WG didn't want multiple standards, so
it decided to do none.

For libreswan, we do "Opportunistic IPsec", which is basically "just try
host-to-host IPsec, fail to either clear or block depending on policy".
We also have a "you can do auth-null for passive attack protection"
in one or both directions" and a migration path from there to fully
authenticated IPsec. Authentication based on a shared CA or DNSSEC.

These are packet trigger based solutions.

It works well for most meshes, and requires no proprietary or new
standards. The only two non-standard parts are that when using
certificates, we allow requiring an addictional call to match
the IKE ID with certificate SAN in the DNS (to prevent a compromised
node from pretending to be another node in the mesh) and we have
one non-standarized payload to signify we can do auth-null as well as
authenticated IPsec, which we hopefully can retire once this document
gets adopted / implemented:

https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-auth-announce/

> Is there any drafts describing the solutions to the problems identified by RFC7018?

There might be the old drafts of the autovpn candidates, but as that is
all incompatible and/or proprietary, and mostly from before my time, I
have not looked at those solutions much.

One issue I have with Cisco solutions, is that they now prefer to wrap
everything in GRE, which isn't the best from a security point of view.

NHRP (using opennhrp) seems somewhat popular too?

Paul