IETF Logo Mail Archive

Re: [IPsec] Labeled IPsec options

Paul Wouters <paul@nohats.ca> Fri, 13 December 2019 14: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 CAC6112011D for <ipsec@ietfa.amsl.com>; Fri, 13 Dec 2019 06:52:45 -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 0CLVm9UBj-yw for <ipsec@ietfa.amsl.com>; Fri, 13 Dec 2019 06:52:45 -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 F241412009E for <ipsec@ietf.org>; Fri, 13 Dec 2019 06:52:44 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47ZDDC55lhzDXJ; Fri, 13 Dec 2019 15:52:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576248763; bh=B32f+sA5EHQE3mUxxAjFV4X4HlEFt8lDxGV+Ln/kj9I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Mv4ck0SzAV9QPRv+Ru8wXd+FSI9sCr3rnvvBouCJ8k0q4Gekt9cY7KD2Cv9+hZ/BH S7mAKLETjZnW7HoOJIoCSoeR6sgDXQmPCv4A+9AdPzPNX7+yAxxEZ3u0+vMsdnR0pv 0fiZAzNjSVqbzMCWptCb51un0W73OSWtGsa1KdPo=
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 UEloh2YJyKwq; Fri, 13 Dec 2019 15:52: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; Fri, 13 Dec 2019 15:52:42 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0353A6007ADD; Fri, 13 Dec 2019 09:52:42 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0218166AA8; Fri, 13 Dec 2019 09:52:42 -0500 (EST)
Date: Fri, 13 Dec 2019 09:52:41 -0500
From: Paul Wouters <paul@nohats.ca>
To: Russ Housley <housley@vigilsec.com>
cc: Tero Kivinen <kivinen@iki.fi>, Valery Smyslov <smyslov.ietf@gmail.com>, IETF IPsec <ipsec@ietf.org>, Sahana Prasad <sahana@redhat.com>
In-Reply-To: <32430816-736B-42E3-8988-85D4D3F6392E@vigilsec.com>
Message-ID: <alpine.LRH.2.21.1912130951380.8529@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> <32430816-736B-42E3-8988-85D4D3F6392E@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/5SSkbIH5kqmLcq8rhz8Va7QF1Kc>
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: Fri, 13 Dec 2019 14:52:46 -0000

On Thu, 12 Dec 2019, Russ Housley wrote:

> If the initiator wants to use labels but the responder does not support labels, will the initiator move forward anyway?  Doing so would seem surprising to me.  The point of the label is to indicate what handling is needed to adequately protect the data.  Moving forward without the responder agreeing to that handling seems unlikely to me.  Are there situations where moving forward is "the right thing"?

I don't think anyone has come up with a real use case where the security
labels are optional.

> If not, then Option 1 makes the most sense to me.

noted.

Paul

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