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

Yoav Nir <> Tue, 20 November 2018 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83382130DCD; Tue, 20 Nov 2018 09:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mkOZZ4K6X0GR; Tue, 20 Nov 2018 09:54:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79B5D1277BB; Tue, 20 Nov 2018 09:54:50 -0800 (PST)
Received: by with SMTP id u9-v6so2953171wrr.0; Tue, 20 Nov 2018 09:54:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lXN8rOibksqbLHVsOOVizy+ZM/B8D61ik9q5V9Q6uWc=; b=UYPACf+UydALWzhKYWEal4H3qMrIv2vBLhGwiI+C7yzi58ZlrfMF9ZUqhQdx14BZg+ kvWGcl1LOvQIJpY2PT4wKOthkxkroHOxcsnrHjRbr7LgHRR3vSvfngNoTTYbpwW6iaE9 B3QtVAXBhZjQl5vT/kKjFwPUaY57B9T3swbzSZQmpVjRlby6yq1gF9CDwQJmH54D4Zyz /Y2znbI4vt8XDECTLGv9YOPZtiROOeOGkTtDL3HfrOmv0LgKSxB3Z0qT1voJnTWnTyNn 29RCoLmkjYQQmaV3rNg4k87h+vraLF60vF07SKC310Maez6PxkDqyrx+bqQLvrdhHOQy 8oAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lXN8rOibksqbLHVsOOVizy+ZM/B8D61ik9q5V9Q6uWc=; b=HWEuCsHU52aOIxDSiHWzTXc0F3Ux6F3oPAsM276tTVC3kCsfXLfj7opJ2HTx32RZIq T9yGeltCMggdO3W1hZX4IJdYcZlTDWjk5uSOFPBkvmL0g2IZPbMfApmtMbKHsEr5Dxhj RLcRPs3ju1UPv1RnHvnvVwFMPK7GpmmicFJC5aVDB2fGWeSqAqgS7DSb8IWyCfzB0mx0 PAaWTcwP9zBUM+krunzxOsWON50RDgPk7tz4IjTyK/rttUMRfW+HaZffjyRXEry/Omr6 pPIBsR6vKw2N0HTd4DnGu9n00CERAXB+ltuponB6zH9Z7oAy76V/l7ofKML/5EFP0+tK q2uQ==
X-Gm-Message-State: AA+aEWYH3iGKUsRqqiic5KhtcsV3qExIG3bfmyDyooV42WJQjOEVe3kM ckVIoCz1rXW4O/m2qbvO/Ds=
X-Google-Smtp-Source: AFSGD/WQOVqEZ8dN5Gv0H9Vc67llD19GFlrq0VQpULzdkZc3KMJo4RZPWqHl6gmsi8sLynk3J684kg==
X-Received: by 2002:adf:a599:: with SMTP id g25-v6mr2985519wrc.188.1542736488941; Tue, 20 Nov 2018 09:54:48 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id z17sm20860552wrv.2.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 09:54:47 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Tue, 20 Nov 2018 19:54:45 +0200
Cc: Rafa Marin Lopez <>,, " WG" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Paul Wouters <>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <>
Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Nov 2018 17:54:53 -0000

> On 20 Nov 2018, at 17:14, Paul Wouters <> wrote:
> On Mon, 19 Nov 2018, Rafa Marin Lopez wrote:
>>> Based on the introduction and abstract of the draft, this document does two things:
>>> 1) Specify a yang model for use with SDWAN + IKE + IPsec
>>> 2) Define the desired modes and algorithms to use with 1)
>>> It does not try to map the entire IKE/IPsec IANA registry into a yang model. Let me know if this is incorrect, because I use
>>> this as an assumption for the remainder of the review.
>> We must say that our I-D specifies 1) but being SDWAN one of the possible scenarios to operate so that the intent was to map the IKE/IPsec IANA registry. In any case we can change that approach if the WG consider is the right way to proceed.
> Then I would stick with RFC 8221 and RFC 8247 entries that have SHOULD
> or MUST (and not include MUST- or SHOULD-)
> So if any other new uses are defined, they don't try to use obsoleted or
> decayed algorithms.

Hi, Paul.

While I agree with your conclusion (although I think it’s fine to include the single MUST- which is HMAC-SHA1), this is not really a new application. It’s more like a new control plane for the old VPN application.

The typical implementation for the NSF in the ipsec-flow-protection draft will be running on a machine that has an IPsec and potentially IKE implementation. The authors’ own implementation is running on top of the Linux kernel (and StrongSwan). If I was still working for an IPsec vendor, I would implement this as a new usermode process pushing SAs or policy into the kernel and into the VPN daemon. 

So this isn’t like TLS 1.3 where you’ll need to upgrade the TLS implementation anyway to get TLS 1.3, and the new crypto will just come in the same package. The NSF code can be made to run on top of a 10-year-old software implementation or 10-year-old hardware from before AES-GCM existed.

Still, as long as AES-CBC and HMAC-SHA1 are in, even that 10-year-old Linux can work, which is why I agree with your conclusion, except for the tweak that MUST- is also OK.