Re: [I2nsf] [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

Yoav Nir <ynir.ietf@gmail.com> Tue, 27 November 2018 22:38 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61121128CFD; Tue, 27 Nov 2018 14:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 b3wsegax7aYc; Tue, 27 Nov 2018 14:38:39 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF65612870E; Tue, 27 Nov 2018 14:38:38 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id t27so16403536wra.6; Tue, 27 Nov 2018 14:38:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XP/rThBQgYf10rO6R+vCfV29xXBl9OnULMSPZS9+PR8=; b=oSsTN0kB4LIZ+t6dJg2k4w7j5q1dxYxgDNHb50MB2vYIa5bYaL3UBAyFvOwFoUebsp DYPTZLk/muk6d0EF9KUfvSF4Ba3Kr7WTRqsx8j9LDt3MavsgTuhj56Zk0sRV9tagfMN+ 6qmkfsWDMrJQnZ+txleSCjuJpSxRjCUZ/Le+Z3iKKMu3WpSkvyhhOpla9gTQqzVV3cz8 BPccjNnlfoBugA4Tn5gHmobibbUWXH5L7fuZTM7p060eM8ld83NrV/8mtOn+LWXCmo6E bB/d7MBpd6oZK+qdNWxbKGabQRrTg31747IvZt1BZgEDFbmyyxlSvNKpn7DYnkDQ2s50 QVAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XP/rThBQgYf10rO6R+vCfV29xXBl9OnULMSPZS9+PR8=; b=dtGMbkyyhU5Iv4XzoNWKiYXHanWUS2M7IKRwatW2LVA6pypEEyonkcbEM9NKsUdgFD 8sudYgowuRPp60Iu8ZzCDTYXfWieTfCEjNj+P4rMvZUI/NnK75w1tOxNKyhXgPV9Se+o PoCE7H5omlJ4VPjzdP1bosOPOVekbVEaL+CZykLQrOSMWXEkRCK1JKyTSwLWDFnOxWrx Y+HrHVjup4GLRfQkhQzPuOTlMMEE6iFYMtbJObcwrPFWaBUy83wdcAmvKS1LFILu3eFm OoD/iV/UTOYdMjHWM7p9Jhx6xLZiNKvcZiU+kBbQUqtXYb3Bq0uEv5dBm4Em8eViVHTi /Gtw==
X-Gm-Message-State: AA+aEWbXdjwws3pP9ccZqk/Wnf9Hd9gEE2mEqpe0PqiyIVRhO0TSyc1Q 6eMW/YPdWQ1LBceAoG+7MUM=
X-Google-Smtp-Source: AFSGD/XGIc9kBrLTxXYIHr6tEFcTQDocw236ex0toXvpJ0YDX6LosaWd5WGUkD6SmpFfecOPM70tHg==
X-Received: by 2002:a5d:6187:: with SMTP id j7mr29342294wru.300.1543358317194; Tue, 27 Nov 2018 14:38:37 -0800 (PST)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 142sm946144wmw.27.2018.11.27.14.38.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 14:38:36 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_187B6ED1-2F73-4CB4-8DF9-ECAEDEEA7038"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 00:38:33 +0200
In-Reply-To: <B47EE67E-1B50-44BB-9821-AB439CA2C2F1@um.es>
Cc: Paul Wouters <paul@nohats.ca>, i2nsf@ietf.org, "ipsec@ietf.org WG" <ipsec@ietf.org>, Rafa Marin Lopez <rafa@um.es>
To: Gabriel Lopez <gabilm@um.es>
References: <A881C135-9BF7-4E93-BB7A-75EB3D1FF605@gmail.com> <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <DAE14995-8504-4134-B021-93D56A4994FB@gmail.com> <alpine.LRH.2.21.1811180149220.25604@bofh.nohats.ca> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> <alpine.LRH.2.21.1811270826430.2053@bofh.nohats.ca> <B47EE67E-1B50-44BB-9821-AB439CA2C2F1@um.es>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/i9FqChH2b4FdImpyqHyZL4dChxw>
Subject: Re: [I2nsf] [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 22:38:41 -0000

A couple of remarks (with no hats)

If we’re bikeshedding the names, I think the difference is that in one case the two NSFs generate traffic keys between themselves, and in the other it is the controller that generates the keys for them.  So how about “distributed keying” vs “centralized keying”, or perhaps “automatic keying” vs “SDN keying”.


Also, I have been asked by someone not on this list whether our work covers the road warrior use case. I said it didn’t and wondered why. So I got these points:
Road warriors are numerous and not where the administrator can configure them manually.
Additionally, the configuration of what networks, gateways (NSFs), and resources a road warrior may access (in IPsec terms, the SPD and PAD) change often.
Because of the above, some automatic method of configuring SPD and PAD is needed.
There is also the issue of multiple VPN gateways covering similar domains, and VPN gateways being overloaded or down for maintenance, as well as malfunctions in the network behind those VPN gateways. So the decision on which gateway a road warrior should use to access a particular resource is also a natural question to ask an SDN controller.

Since I used to work for a VPN vendor, I can tell you what our product did:
The current configuration was formatted (automatically by a management function) as a text file that the road warrior downloaded through the VPN gateway (the gateway doubled as a server serving this one file)
The proper gateway to connect to was determined by pinging all gateways that were possible according to the configuration file.
This did not account for any internal networking issues.

I don’t know if this should be part of *this* effort, but there is a use case for road warrior SDN.

Yoav