Re: [IPsec] Labeled IPsec options
"Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com> Wed, 11 December 2019 18:44 UTC
Return-Path: <jun.hu@nokia.com>
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 7841A120821 for <ipsec@ietfa.amsl.com>; Wed, 11 Dec 2019 10:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=nokia.onmicrosoft.com
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 G6WTpl9cjyKT for <ipsec@ietfa.amsl.com>; Wed, 11 Dec 2019 10:44:44 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130111.outbound.protection.outlook.com [40.107.13.111]) (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 044F5120820 for <ipsec@ietf.org>; Wed, 11 Dec 2019 10:44:43 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l5s2CI2xvlr2dduz12y+G34bWIZR0qo4SebOKSXsUGN6GYloxdeXeGl5nP+NkVJ/IA0JqEB1KU+Okd+fnVub9u83AZwjaxAndYCi03h12vBqW35jm662hZBK1VWOYCcx0nDeDE5QIDs4GGUH1ZH9u9Xq3uAQ6L/l5Stlun0xlPJiw2pbcIqZZckr4cFsJoUvb1YRGTHhD4U1dQ72yLQLo0H2P1jm1RRWkXoWFeWRMYh0Rx5kZDs7Uw7v0R6y3GFUAkgYthm0z52yyGtffyMdVbjuMbEndi6+dDoxas811AkDjjff/zbntqtgGMuETNVk1NC2Ny+XGToV0+k8NUgKlQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mEI4IGnJoT4A7NxKopKF0t5KNggX6mpv/GPt28Vukl0=; b=U1GoqpxoGOlp0ZgAcbKCIOZK/I1yKIvgN67E5g6VezfS3RXyoedVISi9SdWugyWrImZokDJEi+TGjpPxpkCOD5swVk7ZOeKvpqKFYvnbJyZaHQ2mMpM3p9hG9t5ffkMUaX7ouy58ke6oTHJkRTN7OzOh1frPSLKUs7//9Y9Vgkopumv67wnUsOzkg72x178ipeggr3+pXGKhGHw6o7tXP2NCcnVzQELhNVUfisJ16kLlQXOcb7UwqlYj59cyN55IgCdUJ3Fwux3AoYt2hvgfIOtbSOZ6wBVYNAwHkDI89npzfkfFuDvW/YrDSd0VfcUTW2dg12pt1Q1+/25nYIfWYQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mEI4IGnJoT4A7NxKopKF0t5KNggX6mpv/GPt28Vukl0=; b=GQqupYI7tSB0eciaNGvoxm1K8FIsxmvrN5U/37xDAdjBTsCe/n6p6zUlKV8jJ0Y4l48vaiUW1wzN6sszUnY2aaqBwW2qRuHRa9O8+/DncxQfXwhfXgbvlztk/RpdPVVr25mZTJz77iBEFuhf6NprFwJEZw2rtCH4Iy1zL//u8IU=
Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com (10.169.150.18) by AM5PR0701MB2929.eurprd07.prod.outlook.com (10.168.156.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.4; Wed, 11 Dec 2019 18:44:41 +0000
Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::c00:ee6e:9763:f843]) by AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::c00:ee6e:9763:f843%7]) with mapi id 15.20.2538.016; Wed, 11 Dec 2019 18:44:41 +0000
From: "Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com>
To: Paul Wouters <paul@nohats.ca>, "ipsec@ietf.org WG" <ipsec@ietf.org>
CC: Sahana Prasad <sahana@redhat.com>
Thread-Topic: [IPsec] Labeled IPsec options
Thread-Index: AQHVrxZ09uToqmx5zEOPjFh9TCkZuae1Rf+A
Date: Wed, 11 Dec 2019 18:44:41 +0000
Message-ID: <AM5PR0701MB2353D18756E93CD302C43ABF955A0@AM5PR0701MB2353.eurprd07.prod.outlook.com>
References: <alpine.LRH.2.21.1912092333560.23963@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1912092333560.23963@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com;
x-originating-ip: [2601:646:8500:5ce4:51f0:dbe7:fd3:efdd]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: fb243381-6466-44c5-0a93-08d77e6a2ef9
x-ms-traffictypediagnostic: AM5PR0701MB2929:
x-microsoft-antispam-prvs: <AM5PR0701MB2929B80BD26E6F1D9BA00588955A0@AM5PR0701MB2929.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 024847EE92
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(39860400002)(376002)(366004)(199004)(13464003)(189003)(6506007)(7696005)(9686003)(5660300002)(53546011)(55016002)(478600001)(4326008)(966005)(8936002)(8676002)(66446008)(316002)(81166006)(81156014)(52536014)(86362001)(110136005)(33656002)(2906002)(66946007)(76116006)(66556008)(64756008)(66476007)(71200400001)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2929; H:AM5PR0701MB2353.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vsPL5a9LUKfmJM3+PvY67vrLU5Oz+YWQ0pAILynz0ScsvqSooJdk4p8or91Clk06IJ6VcE/Uwqfm0NpphNERxjKq1ZU8vLf4wp6x1FYeHByW5kkI1xVZQBoqgaQTvkKQ00NOhvxhMjOKjeWjZF0KHn9+sGFNvHfN8VI5/w1Djlz4UIGf4+xB2f4blJKuHOldVPPn1gwY++jSlPIDzIi6phS3xSyHhNXWClsDSPnRdMFbo/ON2rvaIzUHOAHrej86qyUWDbVxRMZYxHoZQy50nRw7snbfEz/UNiFKd1yIXTGP+wvITyrs2gMvGU8Z4QWtnT5vhH+h1MKngLB/Z/K+oCpf22Z9kOOPxmxSAALe2pHRRXdXmkWIk8a02Nn1j4SNnaau5tTJp31HJ1AN3zF4B5dlw8dGnBHwheKJsriPY+K0M4Xn0yxqBgbyxz7SYWPn2yod+8z6ysrOtPW7zO88bMJWTwPnvccU7k5nmypIqzs3cMYl5aL2WpM4c5JDnrL74rdk+USvKIlyo8WathiVwTcT4XT6lGvcaZNF+cK6OIQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fb243381-6466-44c5-0a93-08d77e6a2ef9
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 18:44:41.5331 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iVR0t2LVn2odf3z4Jv4QIQAS4UYi3h/oNKa5ce3f3kWveKkuoEvx/hNkOfQLwkMKi4BBiFT3x2N2+QKhEee/tw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2929
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/IujPTsee4KYJK5BOOdFBX1UWLKM>
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: Wed, 11 Dec 2019 18:44:46 -0000
+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) Option3 is a bit "abusing" the semantic of notification payload, since a "label notification" is not communicating a status, error or capability. -----Original Message----- From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Paul Wouters Sent: Monday, December 9, 2019 8:58 PM To: ipsec@ietf.org WG <ipsec@ietf.org> Cc: Sahana Prasad <sahana@redhat.com> Subject: [IPsec] Labeled IPsec options 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 mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
- [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