IETF Logo Mail Archive

Re: [IPsec] Labeled IPsec options

Paul Wouters <paul@nohats.ca> Thu, 12 December 2019 21:24 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 2B4A2120142 for <ipsec@ietfa.amsl.com>; Thu, 12 Dec 2019 13:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 Ow9wreAOJuJE for <ipsec@ietfa.amsl.com>; Thu, 12 Dec 2019 13:24:44 -0800 (PST)
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 6DA2B120121 for <ipsec@ietf.org>; Thu, 12 Dec 2019 13:24:44 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47Ymyz0xnzzDZs; Thu, 12 Dec 2019 22:24:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576185883; bh=EnH3eMmmJ42cQxxiIygfA38hYyewjezWzncK97cuhmk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=b6sxkXXAik72hSHZcxa5IxxIwZ0KIeTX6xExoTATuK/5WM3HUFZoW6f+wCkT41l1S YthZrtgQQJ7gLGiLE2TIfj0w99rvHkFivM6NE9eS9RUOASqJJKqIa4vU4GGlA30YeA fh+E1W1z9P5nwU8zRqgQGc64petY4PSqWPmTSIIQ=
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 2MX5t_-pECVr; Thu, 12 Dec 2019 22:24:42 +0100 (CET)
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; Thu, 12 Dec 2019 22:24:42 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4D5206007C4F; Thu, 12 Dec 2019 16:24:41 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 49B2C308EC; Thu, 12 Dec 2019 16:24:41 -0500 (EST)
Date: Thu, 12 Dec 2019 16:24:41 -0500
From: Paul Wouters <paul@nohats.ca>
To: "Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com>
cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Sahana Prasad <sahana@redhat.com>
In-Reply-To: <AM5PR0701MB2353D18756E93CD302C43ABF955A0@AM5PR0701MB2353.eurprd07.prod.outlook.com>
Message-ID: <alpine.LRH.2.21.1912121623440.22484@bofh.nohats.ca>
References: <alpine.LRH.2.21.1912092333560.23963@bofh.nohats.ca> <AM5PR0701MB2353D18756E93CD302C43ABF955A0@AM5PR0701MB2353.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/5b0OjiMja8tzQor96Ggf4CgfUT8>
Subject: Re: [IPsec] Labeled IPsec options
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: Thu, 12 Dec 2019 21:24:46 -0000

On Wed, 11 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote:

> Subject: Re: [IPsec] Labeled IPsec options
> 
> +1 for option4, +0.5 for option3
> One factor to consider is the granularity of label, for me it is per CHILD_SA; option1 is per TS (e.g TS with label and TS without label could be mixed in the same payload), option2 is per TS payload (e.g. you could have TSi with label, TSr without label)

If you select multiple TS's these all become part of one Child SA. So I
think the granularity of the label does not change between the
solutions?

> Option3 is a bit "abusing" the semantic of notification payload, since a "label notification" is not communicating a status, error or capability.

A bit yes :)

Paul

v2.29.0 | Report a Bug | By Email | System Status