Re: [IPsec] Labeled IPsec options

Paul Wouters <paul@nohats.ca> Thu, 26 December 2019 18:02 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 7177E1200BA for <ipsec@ietfa.amsl.com>; Thu, 26 Dec 2019 10:02:09 -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 bPopmrc2RZ0d for <ipsec@ietfa.amsl.com>; Thu, 26 Dec 2019 10:02:08 -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 AF4B8120091 for <ipsec@ietf.org>; Thu, 26 Dec 2019 10:02:02 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47kHpc5Ky3zDZQ; Thu, 26 Dec 2019 19:02:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577383320; bh=cANJCKESXnDMIj6l6DMpzaVJ/zhXmsG/Unae4jXq/GY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GWCtHNYl8JKhvdKMgIXW2kToxjkz4wXfI+EoviVyqscGs76KTJRr+XFuT+7Sn2Ci/ wFoAp21pz5E7uul4FOUewKwcD9RwoexGHEvzG2sMdSxJm8yywNxaFcuq4bG4mYxqWR vjU7YIZSOC6NlEmvtrpwirPXDvYuu5K56XkNITKo=
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 FXiF3cDpG0Vx; Thu, 26 Dec 2019 19:01:59 +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, 26 Dec 2019 19:01:59 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id D964A6007AD8; Thu, 26 Dec 2019 13:01:58 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D5CC865E47; Thu, 26 Dec 2019 13:01:58 -0500 (EST)
Date: Thu, 26 Dec 2019 13:01:58 -0500
From: Paul Wouters <paul@nohats.ca>
To: Valery Smyslov <smyslov.ietf@gmail.com>
cc: 'Tero Kivinen' <kivinen@iki.fi>, ipsec@ietf.org, 'Sahana Prasad' <sahana@redhat.com>
In-Reply-To: <032201d5bb30$7b70ec00$7252c400$@gmail.com>
Message-ID: <alpine.LRH.2.21.1912261258470.11522@bofh.nohats.ca>
References: <alpine.LRH.2.21.1912092333560.23963@bofh.nohats.ca> <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> <046401d5b1c6$98ed09d0$cac71d70$@gmail.com> <24055.63797.695416.153493@fireball.acr.fi> <032201d5bb30$7b70ec00$7252c400$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/maQd1bHjYIRSKz5Hi3dDuGbFi4E>
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, 26 Dec 2019 18:02:10 -0000

On Wed, 25 Dec 2019, Valery Smyslov wrote:

> Another approach - use some new status notification containing
> seclabel that the initiator would include in any request to create
> Child SA. This is easy to implement, but there is a possibility,
> that unsupporting responder will just ignore this notification
> and create SA w/o proposed seclabel. In this case the initiator
> would need to immediately delete this SA.

That is a big problem but not the only one.

> My proposal only deals with this situation. If initiator and responder
> exchange SECLABELS_SUPPORTED notifications at the time of
> creating IKE SA (in IKE_SA_INIT), then the initiator will know,

During IKE_SA_INIT you do not fully know which configuration you are
talking to, as no ID's have been exchanged. If a server has some
connections with and some without security labels, it cannot guarantee
success despite the notification. And that is assuming the notification
does not indicate "support" but indicates "supported and required"

> Again, I'm fine with either using new Traffic Selectors or Notify
> for this purpose. Both have pros and contras.

I think the majority seems to be in favour of Traffic Selectors. While
a combinatory explosion is a worry, we do not expect that many new types
of traffic selectors, so it is unlikely to become a big problem I think.

Paul