[IPsec] Labeled IPsec options
Paul Wouters <paul@nohats.ca> Tue, 10 December 2019 04:58 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 92F0512021C for <ipsec@ietfa.amsl.com>; Mon, 9 Dec 2019 20:58:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 wpxyO_IucF_5 for <ipsec@ietfa.amsl.com>; Mon, 9 Dec 2019 20:58:11 -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 D69AD1201DC for <ipsec@ietf.org>; Mon, 9 Dec 2019 20:58:10 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47X79V1n4Tz3Ly; Tue, 10 Dec 2019 05:58:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1575953886; bh=Bsir6afxKjUI8sTWPtbqc3PyI5narXZrlcYCP+GJOug=; h=Date:From:To:cc:Subject; b=gL05K5bgt62kCHFqZe2waYnf3yXeXsZIT1PxFWNMM70e9jihfg7BHHyYt9sXbswLa zs/BTSdpKU4t+G872aMZuIpOMYbBCWSjzuVCMnITS2x01PntLQRNhZxeuqVKhN3fla vCZZgXyG6ZeDZFCXP15ueTomhxa1JDcEH4Tba6m8=
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 XHnjW5g6fYBI; Tue, 10 Dec 2019 05:58:04 +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; Tue, 10 Dec 2019 05:58:04 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9309060011A0; Mon, 9 Dec 2019 23:58:03 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8F16323D192; Mon, 9 Dec 2019 23:58:03 -0500 (EST)
Date: Mon, 09 Dec 2019 23:58:03 -0500
From: Paul Wouters <paul@nohats.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
cc: Sahana Prasad <sahana@redhat.com>
Message-ID: <alpine.LRH.2.21.1912092333560.23963@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/32K5c_GnqiOlO-4UaXKk1QOXOcI>
Subject: [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: Tue, 10 Dec 2019 04:58:14 -0000
Hi, As agreed at IETF 106, we would write up the options for negotiating Labeled IPsec that we have discussed, with their PROs and CONs, so that the working group can make a final decision. Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00 This option introduced a new Traffic Selector type that is similar to the core IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but also contain a Security Label field PROs: - Early failure during IKE_AUTH when mismatched. No IPsec SA establishes - Does not otherwise change the Traffic Selector processing CONs: - A bit ugly to have sort of duplicate Traffic Selector types - All new TS types in the future would need to get a seclabel and non-seclabel version. Option 2) TS_SECLABEL https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02 PROs: - No copies of TS TYPE's with/without seclabel CONs: - Error handling is less nice. Responder might setup an IPsec SA narrowed to without security label (unsupported TStypes can be ignored according to RFC 7296), and the initiator has to refuse it by sending a Delete SA message (as security labels are typically mandatory) - Changes Traffic Selector processing, as now one is told that if you pick TS_SECLABEL you must also pick a TS_IPV{46}_ADDR_RANGE. Thus updates RFC 7296 with "sub typing" of TS TYPEs. Option 3) Use NOTIFY payloads (not specified in a draft) PROs: - No changes to Traffic Selector code or specification. Easiest to implement. CONs: - Error handling is less nice. Responder might setup an IPsec SA without supporting the NOTIFY, and initiator has to Delete SA it. Option 4) A new payload type like NOTIFY but now we can set Critical Flag (not specified in a draft) PROs: - No changes to Traffic Selector code or specification. Easiest to implement. - Can use payload with Critical Flag, so exchange fails if not configured or supported for security label type payload - Error handling already done as part of standard IKEv2 CONs: - Takes up a new payload number. - Old Implementations might ignore Critical Flag and new payload type and setup IPsec SA without Security Label? New implementations not receiving the new payload type must also send Delete SA to prevent non-label IPsec SA on responder to linger. Please let us know on the list which solution you prefer and why, so we can make a final decision and move on :) Paul & Sahana
- [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Hu, Jun (Nokia - US/Mountain View)
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Tero Kivinen
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Russ Housley
- Re: [IPsec] Labeled IPsec options Hu, Jun (Nokia - US/Mountain View)
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Hu, Jun (Nokia - US/Mountain View)
- Re: [IPsec] Labeled IPsec options Tero Kivinen
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Paul Wouters