From nobody Mon Oct 12 08:58:44 2020 Return-Path: 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 C4D123A1591; Mon, 12 Oct 2020 08:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Oht7MvKd26Le; Mon, 12 Oct 2020 08:58:40 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3CF3A0E6D; Mon, 12 Oct 2020 08:58:40 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id EB2D76020F; Mon, 12 Oct 2020 15:58:39 +0000 (UTC) From: Christian Hopps Message-Id: <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_49D479BA-5A52-4EA7-8198-98CB3B01D060"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 12 Oct 2020 11:58:38 -0400 In-Reply-To: <160148315262.3746.2680691950315422865@ietfa.amsl.com> Cc: Christian Hopps , ipsecme-chairs@ietf.org To: ipsec@ietf.org References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 15:58:42 -0000 --Apple-Mail=_49D479BA-5A52-4EA7-8198-98CB3B01D060 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi ipsecme and chairs, This is a small update to the IPTFS draft which incorporates the last 2 = changes that had been requested over the last year or so. 1. As requested last year, it dispenses with the late-enabled = functionality, replacing it with a SHOULD clause supporting receiving = IPTFS encapsulated ESP payloads w/o extra configuration. 2. It highlights that one must send payloads that carry inner packet = fragments using consecutive ESP sequence numbered packets (with a caveat = for all pad payload insertion). We feel the document is quite stable at this point and would thus like = to ask for moving to WG Last Call. Thanks, Chris. > On Sep 30, 2020, at 12:25 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions WG of the IETF. >=20 > Title : IP Traffic Flow Security > Author : Christian Hopps > Filename : draft-ietf-ipsecme-iptfs-02.txt > Pages : 26 > Date : 2020-09-30 >=20 > Abstract: > This document describes a mechanism to enhance IPsec traffic flow > security by adding traffic flow confidentiality to encrypted IP > encapsulated traffic. Traffic flow confidentiality is provided by > obscuring the size and frequency of IP traffic using a fixed-sized, > constant-send-rate IPsec tunnel. The solution allows for congestion > control as well. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_49D479BA-5A52-4EA7-8198-98CB3B01D060 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+EfS4ACgkQLh2DDte4 MCVDfw//fhUqUZHbPGZrR0vKAvEVjGW7T5nDavTv4GNp8hKfuOy+jIFHSVwN8E6K /D0DxfcOxPKMoQC0BDEgf2HgouRCFrNWEbbvOz51NJUQYjGXqPOWN0Fz8rTtI1Ek vyBeuumhnEi5TccnBakNagt18pb5Xj9Ce+2fcHVincKg9cO6fGZAkaivG6Jh1vnR U7QXcLiIdN2/Hjf8E4p2GmDza0lTbpzM/Q7dLuM1gkfSkJ/eEPPR7yhCTIl+Se1R cgHVfFRod2A5aP5aHpxtbQHaz+/FyPAdHt+A4J1/3yMXS1KG4AGJTGvrurPm/OEp N0mYV8KBg/8QP7U8G9QaijNjxX0DAMZXUDBCpHphdx8MxIAUX12NgufudBTDb/Vm O1sr4ZikyZbh2yo5cJ+msEa/5YnviJNZKRbB+9WlBMIfjsN5/O1fi985s4xysvhg pEB4nJPtsnEj1DY8OhhDB4ldQ3ICRXMefj84y/8q2GVxpRKjYumV2vZZ8/RkWw+s bS8xLLpiEP8OR7kQQNeKlQNSZ1/URUP1gIl63J49sGW0rvpJdN7kI0QUlWcAA9qG WGu2iEAW/+6tCbfJVO+CajUhC9O20t+iWZwAGvcqH0FwMJlRHFh0tujx2QK2mTyg QF+uskYmsPq7rK3awYLFZj56HT2CLzXdrwpFYtbs0hHrau/Ix9Y= =KNuK -----END PGP SIGNATURE----- --Apple-Mail=_49D479BA-5A52-4EA7-8198-98CB3B01D060-- From nobody Mon Oct 12 09:02:41 2020 Return-Path: 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 E68153A1590; Mon, 12 Oct 2020 09:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=nFVudMF6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EsTOEfR9 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 eZ1LvKF2Ns08; Mon, 12 Oct 2020 09:02:32 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DB33A158C; Mon, 12 Oct 2020 09:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23128; q=dns/txt; s=iport; t=1602518552; x=1603728152; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R45xVfktmefBwhhK0WzB6liNpJ2XnaFJxl77VtlHXNY=; b=nFVudMF67vrUJe0K3yXtae1AtfmHQM2DUTyityP1pbITv321eGZkWINN AhptBLhVBKa96RawmNicSjLIri4qtNMegN55kT344zVWsouE1bEsP8XLJ jwnH0TGKP4DUZFi5i7F5gAl3yIP4JDqB0LEcgIhkOa7iqReBft+t4+WwC g=; IronPort-PHdr: =?us-ascii?q?9a23=3Ac9/q4BcErTcNbEOI8s7gxFVVlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQB9fa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrCQBcfYRf/4kNJK1gHgEBCxIMgzI?= =?us-ascii?q?vUQdwWS8sCoQzg0YDjVCUDIRvglMDVQsBAQENAQEYAQoKAgQBAYRKAheBfwI?= =?us-ascii?q?lOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEEAQEQEQoTAQEsCwEPAgEIEQQ?= =?us-ascii?q?BASQEAwICAiULFAkIAgQBDQUIEweDBYF+TQMuAQMLnEkCgTmIYXaBMoMBAQE?= =?us-ascii?q?FhQYYghADBoE4gnKDboZWG4FBP4FUgk0+glwBAQKBXxUWCYJhM4ILIpBagjQ?= =?us-ascii?q?8hwYmi1qRFAqCaI9bizChOpMioCUCBAIEBQIOAQEFgWsjKoEtcBU7gmlQFwI?= =?us-ascii?q?Njh83gzqFFIVCdAI1AgYBCQEBAwl8jDsBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.77,367,1596499200"; d="scan'208,217";a="580392982" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 16:01:37 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 09CG1beJ027057 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2020 16:01:37 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 12 Oct 2020 11:01:37 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 12 Oct 2020 11:01:37 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 12 Oct 2020 12:01:36 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XaooTw1ffAT/ca8NF5bng5L4Ntj41HQIjj+nI9gxVSCO3KUiHItd1CaMyQvFscf8IbwrgiAF/Q9AXgVwABiTpMZNas47KpEKcSXG8+2+9PZYo5LCW185vywxVEPvvlLm+vhzzQ78LCSRvuhxZEjEiVKsm6fwgYzBe/OUtqoNKLj3pCRfzVe2XBVEHK9B5zWj5gYKCdToPkKc+dA55UvfoZpjzGhR4NK8f9U0oSZX25ji9NxQJBeWkh8oQFfph3/OwNgDFfQwzdBARoCJBshO0QSLck4/95gACaTlGKJFhAxe5kAmTgnPcshDVWmbfdzkSl0uR2YrlgponrTOK3A3UQ== 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=R45xVfktmefBwhhK0WzB6liNpJ2XnaFJxl77VtlHXNY=; b=RH9Pnk/jo3bkRDVYEz/J3fo+ca/BLyryTvobCINpfCVOEFwJ1FiCjp/94eJ64OD6LsBLydjpgPzBQnlZDXbkEd8mI0/5KM7WOWnU/CVXuqlVJzBVjauMm0IYGdxmGBOcQE36nnQIH0YE1/RY00AYJFjXOaXBpL54M5dEPMoCCn8A/lKSO/+yEdF1BzT1fxr6KdA5Ku6tj+UU/3SwB5zMVi4Vr7wbPA8/cEJle+gl1YU3Bft1Dec42ycLuWQ8LLxkcmTIAN1Z/HeLwQMzDcgAHs46XxoH/MFNO6Rgfo5OH/0Il/GJsLvT6f5T3DVeI5RslB/a3JzpE4nCJt6NHQAvUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R45xVfktmefBwhhK0WzB6liNpJ2XnaFJxl77VtlHXNY=; b=EsTOEfR9eQuTCo1j0PFQ6AvxqNc1NmKNVxvVJdz5NQ3Tv4mdVdqp6iXsXgntPGFcBKol/FrGTeScb6Df7Q+XKOEksedsFXcRICnMYCQzIykrrzTWNK04pGDENPIwO98n5g5tvvRyofzA76Ee1whsoZQMZoc7ap34gj8lRqiEbmM= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4479.namprd11.prod.outlook.com (2603:10b6:208:17b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Mon, 12 Oct 2020 16:01:35 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3455.030; Mon, 12 Oct 2020 16:01:35 +0000 From: "Rob Wilton (rwilton)" To: "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , Rafa Marin-Lopez CC: "i2nsf@ietf.org" , Gabriel Lopez , "ipsec@ietf.org" , "last-call@ietf.org" , "yang-doctors@ietf.org" , Christian Hopps , Lou Berger , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= Thread-Topic: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 Thread-Index: AQHWlNo2e9jni2YANkmtZfreFx+hBKmUJBxQ Date: Mon, 12 Oct 2020 16:01:35 +0000 Message-ID: References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> In-Reply-To: <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 197de273-39cd-4ae0-e9f7-08d86ec81877 x-ms-traffictypediagnostic: MN2PR11MB4479: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RcXF/gJdKhpmR5iMthNMuzv9oG7ByCotzDYUjpLyeMDT1CB6IS4RpQwuBLWNpvcGcNV/IV2huKBS4brfAx7GZHHO/qhUtrCKV6hUTl5orG6zRdG9cnG+R9uA0EUKTib4YtTHu9LEyrq/Z69nZfWQIK50yEJUP0K21S83W9NVO9BTDOIbk1s/2ww6Xu8+9yCW1XJc3MoxZS9kUjkZAYTnzWedk1+e8rhUOvSlf1+emmSqdK0JRRASavafNfdJyv4EWaSpflvew4n8eSX71mWtjeZ/jSeTeajjjFZ2BHYWxr9EeDHWLjX016SfMPvAxomsgLv6GKYV0N9A08h3aw6Ov938wOcXU4ETdRoXbg50Ehk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(376002)(396003)(366004)(136003)(64756008)(66556008)(316002)(76116006)(54906003)(66476007)(55016002)(66574015)(26005)(478600001)(6506007)(66446008)(2906002)(166002)(7696005)(71200400001)(186003)(66946007)(52536014)(53546011)(33656002)(83380400001)(966005)(5660300002)(7416002)(86362001)(9686003)(4326008)(110136005)(8936002)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: kxi6eiwaeGAcJG2Eflbgf2SlPlKoJUUadl0MAEIUwtO2eYPmPp/JnC60UIKsqO54DBWGEkdxzX7PNdCCMIlJx7/WG01ibcoVMfrb2HMt3rlEzrVpFjJ1Fqk77ZoXpm7OpvNA3uTXwjTrDhpR+gxUfUXOsKKI2C35fK4/0sgfOkTN2c/270SazQL4pvjLmnpdhRHdjs9iQMSR4SLcNXoFDsXZf3L8Ljz6prnB43hau7zKWNaXmhldOoCZ0lOqlBjUjRXJBRJmVKT9Ia9z2WcApJgAwDPwY75AA2JSKW5YJQh7EOAq8/4j6z8CpzpQ6ME2Hfok9css5wu1o8CKUEiisNfzeGeTFw1+MjhnR6dcL7TKx62jzxCEMgnxCd2IggvaeD4/fVt4FDzWjNdO46zXqTRTB4cc3/RDN6mrjcUKJv/UQNrzORUG5ou2r6jKapZ8GuxtBLKI5PCpHOgO2rvkG2fauc5LgRnODINRH2n/QGD0ayDFAbS4UwEz4aT0ZkxkenvJ615FDfeS4CRWDCzQK3AKHgbw/6pHaZ84Zj/ww6Gmv202DcZj7VAtgV23SHaJ8sxioDT+yeD3Hew4AMySKbmcgrHukK5iol8Gr99iLARfZfVN3du0fOm5pmP4CnLuibcmbxw+CWx0Qdxola7zaQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43662E1711367EDE9A066452B5070MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 197de273-39cd-4ae0-e9f7-08d86ec81877 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2020 16:01:35.5132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hud1L3ceUBFx9J8YF0e/YEf9EbvXwlARqZJ1TaJWUxpy12xHvOhXtosGgVgLNEnuF8kZBGwNwqhSnHVabNI3wg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4479 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [IPsec] [yang-doctors] [Last-Call] [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 16:02:35 -0000 --_000_MN2PR11MB43662E1711367EDE9A066452B5070MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFmYSwgYXV0aG9ycywNCg0KSnVzdCB0byBjaGVjay4NCg0KSGFzIHRoZXJlIGJlZW4gYW55 IGNsb3N1cmUgb24gdGhlIHN1Z2dlc3Rpb24gZnJvbSBDaHJpcyBvbiDigJxub3RpZmljYXRpb25z IGluIHRoZSBpa2VsZXNzIG1vZHVsZSBhcyBhIGZlYXR1cmUiPyAgVGhpcyB3b3VsZCBzZWVtIHRv IGJlIGEgZmFpcmx5IGNoZWFwICYgZWFzeSBjb21wcm9taXNlLg0KDQpUaGFua3MsDQpSb2INCg0K DQpGcm9tOiB5YW5nLWRvY3RvcnMgPHlhbmctZG9jdG9ycy1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgTG91IEJlcmdlcg0KU2VudDogMjcgU2VwdGVtYmVyIDIwMjAgMTU6MjYNClRvOiBD aHJpc3RpYW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPjsgTWFydGluIEJqw7Zya2x1bmQgPG1i aitpZXRmQDQ2Njguc2U+DQpDYzogUm9iZXJ0IFdpbHRvbiA8cndpbHRvbj00MGNpc2NvLmNvbUBk bWFyYy5pZXRmLm9yZz47IGkybnNmQGlldGYub3JnOyBHYWJyaWVsIExvcGV6IDxnYWJpbG1AdW0u ZXM+OyBkcmFmdC1pZXRmLWkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24uYWxsQGlldGYu b3JnOyBpcHNlY0BpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnOyBSYWZhIE1hcmluLUxvcGV6 IDxyYWZhQHVtLmVzPjsgeWFuZy1kb2N0b3JzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3lhbmct ZG9jdG9yc10gW0lQc2VjXSBbTGFzdC1DYWxsXSBbSTJuc2ZdIFlhbmdkb2N0b3JzIGxhc3QgY2Fs bCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLTA4 DQoNClRoaXMgaXMgYSBzdWItb3B0aW1hbCBjb21wcm9taXNlIGIvYyBhbGwgSVBzZWMgaGF2ZSBT QSBkYXRhYmFzZXMgZXZlbiBvbmVzIHJ1bm5pbmcgSUtFIC0tIGkuZS4sIFNBIGRhdGFiYXNlcyBh cmUgY29tbW9uIHdoZXRoZXIgZXhwb3NlZCBpbiBZQU5HIG9yIG5vdCAtLSBidXQgaWYgaXQgY2Fu IG1vdmUgaXQgZm9yd2FyZCBwZXJoYXBzIGdvb2QgZW5vdWdoLg0KDQoNClNwZWFraW5nIGFzIGFu IGludGVyZXN0ZWQgcGFydHksIEkgaG9wZSB0aGF0IHNvbWUgY29tcHJvbWlzZSAvIGdvb2QgZW5v dWdoIHNvbHV0aW9uIGlzIGZvbGxvd2VkIGluIHRoZSAtMDkgdmVyc2lvbiBvZiAgdGhpcyBkcmFm dC4NCg0KTG91DQpPbiA5LzIzLzIwMjAgNzoyMCBBTSwgQ2hyaXN0aWFuIEhvcHBzIHdyb3RlOg0K DQoNCg0KT24gU2VwIDIzLCAyMDIwLCBhdCA2OjU4IEFNLCBNYXJ0aW4gQmrDtnJrbHVuZCA8bWJq K2lldGZANDY2OC5zZTxtYWlsdG86bWJqK2lldGZANDY2OC5zZT4+IHdyb3RlOg0KDQpIaSwNCg0K Q2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZzxtYWlsdG86Y2hvcHBzQGNob3Bwcy5v cmc+PiB3cm90ZToNCg0KDQoNCg0KT24gU2VwIDIzLCAyMDIwLCBhdCA1OjI5IEFNLCBSYWZhIE1h cmluLUxvcGV6IDxyYWZhQHVtLmVzPG1haWx0bzpyYWZhQHVtLmVzPj4gd3JvdGU6DQoNCg0KDQoN CkJ1dCBJIHdvdWxkIGxpa2UgdG8gY2hlY2s6IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUg Y2hhbmdlcyB0aGF0DQpDaHJpcyBpcyBwcm9wb3NpbmcgYXJlIHByZXR0eSBzbWFsbC4gIEkuZS4g bW92ZSB0aGUgU0Egc3RydWN0dXJlIHVuZGVyDQppcHNlYy1jb21tb24sIGFuZCBwdXQgaXQgdW5k ZXIgYSBZQU5HIGZlYXR1cmUuICBBcmUgeW91IHN1cmUgdGhhdCBpdA0KaXMgaW1wcmFjdGljYWwg dG8gYWNjb21tb2RhdGUgdGhpcyBjaGFuZ2Ugd2hpY2ggd291bGQgYWxsb3cgYSBzaW5nbGUNCmlw c2VjIG1vZHVsZSB0byBiZSBzaGFyZWQgYW5kIGV4dGVuZGVkIHZpYSBZQU5HIGF1Z21lbnRhdGlv bnM/DQoNCg0KSW4gdGhlIGNvbnRleHQgb2Ygb3VyIEktRCwgaWYgd2UgbW92ZSBTQUQgc3RydWN0 dXJlIHRvIGlwc2VjLWNvbW1vbiwNCndoYXQgd2UgYXJlIG1lYW5pbmcgaXMgdGhhdCBJUHNlYyBT QSBjb25maWd1cmF0aW9uIGRhdGEgKHNldHRpbmcNCnZhbHVlcyB0byB0aGUgU0FEIHN0cnVjdHVy ZSkgYXJlIGNvbW1vbiB0byB0aGUgSUtFIGNhc2UgYW5kIHRoZQ0KSUtFLWxlc3MgY2FzZXMsIHdo aWNoIGFyZSBub3QuIEl0IGlzIGNvbmZ1c2luZy4NCg0KU29tZXRoaW5nIGRlZmluZWQgaW4gYSBj b21tb24gbW9kdWxlIGJ1dCBtYXJrZWQgYXMgYSBmZWF0dXJlIGRvZXMgbm90DQppbXBseSB0aGF0 IHRoYXQgZmVhdHVyZSBoYXMgdG8gYmUgaW1wbGVtZW50ZWQgYnkgYW4gaW1wb3J0aW5nDQptb2R1 bGUuIFRoaXMgaXMgbm90IGNvbmZ1c2luZyB0byBZQU5HIGltcGxlbWVudGVycyBvciB1c2VycyBJ DQp0aGluay4gSWYgd2UgYXJlIGp1c3QgdGFsa2luZyBhYm91dCBkb2N1bWVudCBmbG93IGhlcmUs IHRoZW4gYQ0Kc2VudGVuY2Ugc2F5aW5nICJ0aGUgU0FEIGZlYXR1cmUgaXMgbm90IHJlcXVpcmVk IHRvIGltcGxlbWVudCBJS0UNCmZ1bmN0aW9uYWxpdHkiIGlzIHF1aXRlIGVub3VnaCB0byBjbGVh ciB0aGF0IHVwIEkgdGhpbmsuDQoNCkFub3RoZXIgYWx0ZXJuYXRpdmUgY291bGQgYmUgdG8gbW92 ZSB0aGVzZSBjb250YWluZXJzIHRvIGFub3RoZXINCihuZXcpIG1vZHVsZS4NCg0KSXQgbWF5IGFs c28gYmUgZW5vdWdoIHRvIG1hcmsgdGhlIG5vdGlmaWNhdGlvbnMgaW4gdGhlIGlrZWxlc3MgbW9k dWxlIGFzIGEgZmVhdHVyZSBJIHN1cHBvc2UuIFRoYXQgaXMgdGhlIGFjdHVhbCB0aGluZyBJIHRo aW5rIG5vbi1TRE4gaW1wbGVtZW50YXRpb25zIHdvdWxkIHdhbnQgdG8gb21pdC4gVGhlIG1vZHVs ZSBuYW1lICJpa2VsZXNzIiBpcyBub3QgZ3JlYXQgaW4gdGhpcyBjYXNlLCBidXQgcGVyaGFwcyB3 b3JrYWJsZS4NCg0KDQpUaGlzIGlzIGEgc3ViLW9wdGltYWwgY29tcHJvbWlzZSBiL2MgYWxsIElQ c2VjIGhhdmUgU0EgZGF0YWJhc2VzIGV2ZW4gb25lcyBydW5uaW5nIElLRSAtLSBpLmUuLCBTQSBk YXRhYmFzZXMgYXJlIGNvbW1vbiB3aGV0aGVyIGV4cG9zZWQgaW4gWUFORyBvciBub3QgLS0gYnV0 IGlmIGl0IGNhbiBtb3ZlIGl0IGZvcndhcmQgcGVyaGFwcyBnb29kIGVub3VnaC4NCg0KDQpJJ20g ZGVmaW5pdGVseSBjb25jZXJuZWQgYWJvdXQgSUVURiBwcm9jZXNzIGFuZCByZWFsIHdvcmxkIHVz YWJpbGl0eSBoZXJlLiBUaGVzZSBtb2R1bGVzIGFyZSBiYXNpY2FsbHkgd29ya2FibGUgZm9yIGlw c2VjIEkgdGhpbmssIHRoZXkgY291bGQgYmUgdXNlZCBieSBvcGVyYXRvcnMgdG9kYXkuIElmIHdl IHJlc3RhcnQgdGhlIGVudGlyZSBwcm9jZXNzIHRvIHJlZG8gdGhpcyB3b3JrIGZvciB0aGUgbW9y ZSBnZW5lcmljIElQc2VjIGNhc2UgaXQgd2lsbCBwcm9iYWJseSBiZSB5ZWFycyBiZWZvcmUgdGhl eSBhcmUgZmluaXNoZWQgYW5kIGluIHRoZSBmaWVsZC4gVGhpcyBuZXcgd29yayBjYW4gYmUgc3Rh cnRlZCwgYnV0IHdoeSBub3QgaGF2ZSBzb21ldGhpbmcgdXNhYmxlIGluIHRoZSBtZWFudGltZT8N Cg0KVGhhbmtzLA0KQ2hyaXMuDQoNCg0KDQovbWFydGluDQoNCg0KDQoNCg0KVGhhbmtzLA0KQ2hy aXMuDQoNCg0KTW9yZW92ZXIsIHRoZSB1c2FnZSBvZiBmZWF0dXJlIG1lYW5zIHRoYXQsIGFmdGVy IGFsbCwgdGhpcyDigJxjb21tb27igJ0gaXMNCm5vdCDigJxjb21tb27igJ0gdG8gYm90aCBjYXNl cyBJS0UgY2FzZSBhbmQgSUtFLWxlc3MuIEFnYWluLCBpdCBzZWVtcw0KY29uZnVzaW5nLiBJbiB0 aGUgSUtFIGNhc2UsIHRoZSBTRE4vSTJOU0YgY29udHJvbGxlciBkb2VzIG5vdA0KY29uZmlndXJl IHRoZSBTQUQgYXQgYWxsIGJ1dCB0aGUgSUtFIGltcGxlbWVudGF0aW9uIGluIHRoZSBOU0YuIElu IG91cg0Kb3BpbmlvbiwgaW4gb3JkZXIgdG8gcHJvcGVybHkgYWRkIHRoaXMgSVBzZWMgU0Egb3Bl cmF0aW9uYWwgc3RhdGUgdG8NCnRoZSBJS0UgY2FzZSB3ZSBzaG91bGQgaW5jbHVkZSBvcGVyYXRp b25hbCBkYXRhIGFib3V0IHRoZSBJUHNlYyBTQXMNCihjb25maWcgZmFsc2UpIHRvIHRoZSBpZXRm LWlwc2VjLWlrZS4gQWx0ZXJuYXRpdmVseSwgd2UgaGF2ZSBjZXJ0YWluDQpvcGVyYXRpb25hbCBk YXRhIChybykgaW4gdGhlIFNBRCBzdHJ1Y3R1cmUgaW4gdGhlIElLRS1sZXNzIGNhc2UuIElmDQpv bmx5IHRob3NlIGFyZSBtb3ZlZCB0byB0aGUgY29tbW9uIHBhcnQgc2hvdWxkIGJlIG9rIGJ1dCB3 ZSB0aGluayBpdA0KZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW0uDQoNCi0tDQpsYXN0LWNhbGwg bWFpbGluZyBsaXN0DQpsYXN0LWNhbGxAaWV0Zi5vcmc8bWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGFzdC1jYWxsDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCklQ c2VjIG1haWxpbmcgbGlzdA0KDQpJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+ DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg== --_000_MN2PR11MB43662E1711367EDE9A066452B5070MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3Vs YXI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1hcmdpbjowY207DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5IaSBSYWZhLCBhdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5KdXN0IHRvIGNoZWNrLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5I YXMgdGhlcmUgYmVlbiBhbnkgY2xvc3VyZSBvbiB0aGUgc3VnZ2VzdGlvbiBmcm9tIENocmlzIG9u IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPm5vdGlmaWNhdGlvbnMgaW4gdGhl IGlrZWxlc3MgbW9kdWxlIGFzIGEgZmVhdHVyZSZxdW90Oz8mbmJzcDsgVGhpcyB3b3VsZCBzZWVt IHRvIGJlIGEgZmFpcmx5IGNoZWFwICZhbXA7IGVhc3kgY29tcHJvbWlzZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+VGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB5YW5nLWRvY3RvcnMgJmx0O3lhbmctZG9jdG9ycy1i b3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3UgQmVyZ2VyPGJyPg0K PGI+U2VudDo8L2I+IDI3IFNlcHRlbWJlciAyMDIwIDE1OjI2PGJyPg0KPGI+VG86PC9iPiBDaHJp c3RpYW4gSG9wcHMgJmx0O2Nob3Bwc0BjaG9wcHMub3JnJmd0OzsgTWFydGluIEJqw7Zya2x1bmQg Jmx0O21iaitpZXRmQDQ2Njguc2UmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSb2JlcnQgV2lsdG9uICZs dDtyd2lsdG9uPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0OzsgaTJuc2ZAaWV0Zi5vcmc7 IEdhYnJpZWwgTG9wZXogJmx0O2dhYmlsbUB1bS5lcyZndDs7IGRyYWZ0LWlldGYtaTJuc2Ytc2Ru LWlwc2VjLWZsb3ctcHJvdGVjdGlvbi5hbGxAaWV0Zi5vcmc7IGlwc2VjQGlldGYub3JnOyBsYXN0 LWNhbGxAaWV0Zi5vcmc7IFJhZmEgTWFyaW4tTG9wZXogJmx0O3JhZmFAdW0uZXMmZ3Q7OyB5YW5n LWRvY3RvcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt5YW5nLWRvY3RvcnNd IFtJUHNlY10gW0xhc3QtQ2FsbF0gW0kybnNmXSBZYW5nZG9jdG9ycyBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJvdGVjdGlvbi0wODxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMg YSBzdWItb3B0aW1hbCBjb21wcm9taXNlIGIvYyBhbGwgSVBzZWMgaGF2ZSBTQSBkYXRhYmFzZXMg ZXZlbiBvbmVzIHJ1bm5pbmcgSUtFIC0tIGkuZS4sIFNBIGRhdGFiYXNlcyBhcmUgY29tbW9uIHdo ZXRoZXIgZXhwb3NlZCBpbiBZQU5HIG9yIG5vdCAtLSBidXQgaWYgaXQgY2FuIG1vdmUgaXQgZm9y d2FyZCBwZXJoYXBzIGdvb2QgZW5vdWdoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWFraW5nIGFzIGFuIGludGVy ZXN0ZWQgcGFydHksIEkgaG9wZSB0aGF0IHNvbWUgY29tcHJvbWlzZSAvIGdvb2QgZW5vdWdoIHNv bHV0aW9uIGlzIGZvbGxvd2VkIGluIHRoZSAtMDkgdmVyc2lvbiBvZiZuYnNwOyB0aGlzIGRyYWZ0 LjxvOnA+PC9vOnA+PC9wPg0KPHA+TG91PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gOS8yMy8yMDIwIDc6MjAgQU0sIENocmlzdGlhbiBIb3BwcyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNlcCAyMywgMjAy MCwgYXQgNjo1OCBBTSwgTWFydGluIEJqw7Zya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmor aWV0ZkA0NjY4LnNlIj5tYmoraWV0ZkA0NjY4LnNlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPkhpLDxicj4NCjxi cj4NCkNocmlzdGlhbiBIb3BwcyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjaG9wcHNAY2hv cHBzLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+Y2hvcHBzQGNob3Bwcy5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3Vs YXImcXVvdDssc2VyaWYiPiZndDsgd3JvdGU6PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYi Pjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+T24gU2VwIDIzLCAyMDIwLCBhdCA1OjI5IEFNLCBS YWZhIE1hcmluLUxvcGV6ICZsdDs8YSBocmVmPSJtYWlsdG86cmFmYUB1bS5lcyI+cmFmYUB1bS5l czwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KQnV0 IEkgd291bGQgbGlrZSB0byBjaGVjazogTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBjaGFu Z2VzIHRoYXQ8YnI+DQpDaHJpcyBpcyBwcm9wb3NpbmcgYXJlIHByZXR0eSBzbWFsbC4gJm5ic3A7 SS5lLiBtb3ZlIHRoZSBTQSBzdHJ1Y3R1cmUgdW5kZXI8YnI+DQppcHNlYy1jb21tb24sIGFuZCBw dXQgaXQgdW5kZXIgYSBZQU5HIGZlYXR1cmUuICZuYnNwO0FyZSB5b3Ugc3VyZSB0aGF0IGl0PGJy Pg0KaXMgaW1wcmFjdGljYWwgdG8gYWNjb21tb2RhdGUgdGhpcyBjaGFuZ2Ugd2hpY2ggd291bGQg YWxsb3cgYSBzaW5nbGU8YnI+DQppcHNlYyBtb2R1bGUgdG8gYmUgc2hhcmVkIGFuZCBleHRlbmRl ZCB2aWEgWUFORyBhdWdtZW50YXRpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPjxicj4NCjxicj4N CkluIHRoZSBjb250ZXh0IG9mIG91ciBJLUQsIGlmIHdlIG1vdmUgU0FEIHN0cnVjdHVyZSB0byBp cHNlYy1jb21tb24sPGJyPg0Kd2hhdCB3ZSBhcmUgbWVhbmluZyBpcyB0aGF0IElQc2VjIFNBIGNv bmZpZ3VyYXRpb24gZGF0YSAoc2V0dGluZzxicj4NCnZhbHVlcyB0byB0aGUgU0FEIHN0cnVjdHVy ZSkgYXJlIGNvbW1vbiB0byB0aGUgSUtFIGNhc2UgYW5kIHRoZTxicj4NCklLRS1sZXNzIGNhc2Vz LCB3aGljaCBhcmUgbm90LiBJdCBpcyBjb25mdXNpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+PGJy Pg0KU29tZXRoaW5nIGRlZmluZWQgaW4gYSBjb21tb24gbW9kdWxlIGJ1dCBtYXJrZWQgYXMgYSBm ZWF0dXJlIGRvZXMgbm90PGJyPg0KaW1wbHkgdGhhdCB0aGF0IGZlYXR1cmUgaGFzIHRvIGJlIGlt cGxlbWVudGVkIGJ5IGFuIGltcG9ydGluZzxicj4NCm1vZHVsZS4gVGhpcyBpcyBub3QgY29uZnVz aW5nIHRvIFlBTkcgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIEk8YnI+DQp0aGluay4gSWYgd2UgYXJl IGp1c3QgdGFsa2luZyBhYm91dCBkb2N1bWVudCBmbG93IGhlcmUsIHRoZW4gYTxicj4NCnNlbnRl bmNlIHNheWluZyAmcXVvdDt0aGUgU0FEIGZlYXR1cmUgaXMgbm90IHJlcXVpcmVkIHRvIGltcGxl bWVudCBJS0U8YnI+DQpmdW5jdGlvbmFsaXR5JnF1b3Q7IGlzIHF1aXRlIGVub3VnaCB0byBjbGVh ciB0aGF0IHVwIEkgdGhpbmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+PGJyPg0KQW5vdGhlciBhbHRl cm5hdGl2ZSBjb3VsZCBiZSB0byBtb3ZlIHRoZXNlIGNvbnRhaW5lcnMgdG8gYW5vdGhlcjxicj4N CihuZXcpIG1vZHVsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JdCBt YXkgYWxzbyBiZSBlbm91Z2ggdG8gbWFyayB0aGUgbm90aWZpY2F0aW9ucyBpbiB0aGUgaWtlbGVz cyBtb2R1bGUgYXMgYSBmZWF0dXJlIEkgc3VwcG9zZS4gVGhhdCBpcyB0aGUgYWN0dWFsIHRoaW5n IEkgdGhpbmsgbm9uLVNETiBpbXBsZW1lbnRhdGlvbnMgd291bGQgd2FudCB0byBvbWl0LiBUaGUg bW9kdWxlIG5hbWUgJnF1b3Q7aWtlbGVzcyZxdW90OyBpcyBub3QgZ3JlYXQNCiBpbiB0aGlzIGNh c2UsIGJ1dCBwZXJoYXBzIHdvcmthYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJy Pg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIGlzIGEgc3ViLW9wdGlt YWwgY29tcHJvbWlzZSBiL2MgYWxsIElQc2VjIGhhdmUgU0EgZGF0YWJhc2VzIGV2ZW4gb25lcyBy dW5uaW5nIElLRSAtLSBpLmUuLCBTQSBkYXRhYmFzZXMgYXJlIGNvbW1vbiB3aGV0aGVyIGV4cG9z ZWQgaW4gWUFORyBvciBub3QgLS0gYnV0IGlmIGl0IGNhbiBtb3ZlIGl0IGZvcndhcmQgcGVyaGFw cyBnb29kIGVub3VnaC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSdtIGRlZmluaXRlbHkgY29uY2VybmVkIGFib3V0 IElFVEYgcHJvY2VzcyBhbmQgcmVhbCB3b3JsZCB1c2FiaWxpdHkgaGVyZS4gVGhlc2UgbW9kdWxl cyBhcmUgYmFzaWNhbGx5IHdvcmthYmxlIGZvciBpcHNlYyBJIHRoaW5rLCB0aGV5IGNvdWxkIGJl IHVzZWQgYnkgb3BlcmF0b3JzIHRvZGF5LiBJZiB3ZSByZXN0YXJ0IHRoZSBlbnRpcmUgcHJvY2Vz cyB0byByZWRvDQogdGhpcyB3b3JrIGZvciB0aGUgbW9yZSBnZW5lcmljIElQc2VjIGNhc2UgaXQg d2lsbCBwcm9iYWJseSBiZSB5ZWFycyBiZWZvcmUgdGhleSBhcmUgZmluaXNoZWQgYW5kIGluIHRo ZSBmaWVsZC4gVGhpcyBuZXcgd29yayBjYW4gYmUgc3RhcnRlZCwgYnV0IHdoeSBub3QgaGF2ZSBz b21ldGhpbmcgdXNhYmxlIGluIHRoZSBtZWFudGltZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFy JnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQovbWFydGluPGJyPg0KPGJyPg0KPGJyPg0KPGJyIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFj aW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01l bmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPjxicj4NClRoYW5rcyw8YnI+DQpDaHJpcy48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+TW9yZW92ZXIs IHRoZSB1c2FnZSBvZiBmZWF0dXJlIG1lYW5zIHRoYXQsIGFmdGVyIGFsbCwgdGhpcyDigJxjb21t b27igJ0gaXM8YnI+DQpub3Qg4oCcY29tbW9u4oCdIHRvIGJvdGggY2FzZXMgSUtFIGNhc2UgYW5k IElLRS1sZXNzLiBBZ2FpbiwgaXQgc2VlbXM8YnI+DQpjb25mdXNpbmcuIEluIHRoZSBJS0UgY2Fz ZSwgdGhlIFNETi9JMk5TRiBjb250cm9sbGVyIGRvZXMgbm90PGJyPg0KY29uZmlndXJlIHRoZSBT QUQgYXQgYWxsIGJ1dCB0aGUgSUtFIGltcGxlbWVudGF0aW9uIGluIHRoZSBOU0YuIEluIG91cjxi cj4NCm9waW5pb24sIGluIG9yZGVyIHRvIHByb3Blcmx5IGFkZCB0aGlzIElQc2VjIFNBIG9wZXJh dGlvbmFsIHN0YXRlIHRvPGJyPg0KdGhlIElLRSBjYXNlIHdlIHNob3VsZCBpbmNsdWRlIG9wZXJh dGlvbmFsIGRhdGEgYWJvdXQgdGhlIElQc2VjIFNBczxicj4NCihjb25maWcgZmFsc2UpIHRvIHRo ZSBpZXRmLWlwc2VjLWlrZS4gQWx0ZXJuYXRpdmVseSwgd2UgaGF2ZSBjZXJ0YWluPGJyPg0Kb3Bl cmF0aW9uYWwgZGF0YSAocm8pIGluIHRoZSBTQUQgc3RydWN0dXJlIGluIHRoZSBJS0UtbGVzcyBj YXNlLiBJZjxicj4NCm9ubHkgdGhvc2UgYXJlIG1vdmVkIHRvIHRoZSBjb21tb24gcGFydCBzaG91 bGQgYmUgb2sgYnV0IHdlIHRoaW5rIGl0PGJyPg0KZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8t UmVndWxhciZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+LS08c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KbGFzdC1jYWxs IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bGFzdC1jYWxsQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5s by1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5sYXN0LWNhbGxAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXIm cXVvdDssc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xhc3QtY2FsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sYXN0LWNhbGw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklQ c2VjIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpJ UHNlY0BpZXRmLm9yZyI+SVBzZWNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYyI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYzwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MN2PR11MB43662E1711367EDE9A066452B5070MN2PR11MB4366namp_-- From nobody Mon Oct 12 12:08:15 2020 Return-Path: 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 4323B3A00E3; Mon, 12 Oct 2020 12:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 7LqUxCNGHOOt; Mon, 12 Oct 2020 12:08:06 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.178]) (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 91BCD3A00D2; Mon, 12 Oct 2020 12:08:05 -0700 (PDT) Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by mx02.puc.rediris.es with ESMTP id 09CJ7sxQ030785-09CJ7sxR030785; Mon, 12 Oct 2020 21:07:54 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id BA58220017; Mon, 12 Oct 2020 21:07:54 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Yn4Tv_CJGZkn; Mon, 12 Oct 2020 21:07:54 +0200 (CEST) Received: from [192.168.1.33] (135.red-79-150-250.dynamicip.rima-tde.net [79.150.250.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon43.um.es (Postfix) with ESMTPSA id 24C96203A0; Mon, 12 Oct 2020 21:07:47 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9DBA0896-01DA-4AE8-AD6F-ED8776315628" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Mon, 12 Oct 2020 21:07:46 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "i2nsf@ietf.org" , Gabriel Lopez , Christian Hopps , "ipsec@ietf.org" , "last-call@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "yang-doctors@ietf.org" , Lou Berger To: "Rob Wilton (rwilton)" References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.170, helo=xenon43.um.es, mailFrom=rafa@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.170 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=noTpIhZtxIuJXWK6Yh83PqwvrZhAse39eBxRtYtyAEU=; b=omTwEgxbrrI//DXo1s6taImYBmkM8X5V0//cbKO0bj5vbV5YUYTHGkprIPQNCvVAATjlSpwe5Bnu 1s3p8ExKSrmYPLXqpF4/w8EoV5J4zmlSj6H/VCxGLszkuBXYfm1n4IhIWNXRRl7rIQMqXKBQRKU7 XGhmL5Jui8RmVZIdMdGYXF/sroJ0ymqinP4WJ5nGPhxsp4bmMGGe45qaoimdHtyOThzW23tN+zaS 2+6Yv5Z7Dp3Cn6KV0gqmo9/EQrNz4n5R8MshDKI64usyl+Ity/lYXhvnXFZLhETqGW9l0fXPeBz7 b9MBZCY8I6jL89prIIRUJEbWHefew9SRWAwAug== Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 19:08:08 -0000 --Apple-Mail=_9DBA0896-01DA-4AE8-AD6F-ED8776315628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob: My apologies but I have just seen this e-mail. We were working on = posting last v09 precisely today, assuming this was all clarified and = the decision was to change the names as Tom suggested. Regarding your comment, having "the notifications in the ikeless module = as a feature" would not help. Let me explain. The ikeless module needs = something inherent to operate, which are the notifications. It is not = something optional for the ikeless module to implement. Hope this helps. Best Regards. > El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) = escribi=C3=B3: >=20 > Hi Rafa, authors, > =20 > Just to check. > =20 > Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as a feature"? This would = seem to be a fairly cheap & easy compromise. > =20 > Thanks, > Rob > =20 > =20 > From: yang-doctors On Behalf Of Lou = Berger > Sent: 27 September 2020 15:26 > To: Christian Hopps ; Martin Bj=C3=B6rklund = > Cc: Robert Wilton ; = i2nsf@ietf.org; Gabriel Lopez ; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; ipsec@ietf.org; = last-call@ietf.org; Rafa Marin-Lopez ; yang-doctors@ietf.org > Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors = last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 > =20 > This is a sub-optimal compromise b/c all IPsec have SA databases even = ones running IKE -- i.e., SA databases are common whether exposed in = YANG or not -- but if it can move it forward perhaps good enough. >=20 >=20 > Speaking as an interested party, I hope that some compromise / good = enough solution is followed in the -09 version of this draft. > Lou >=20 > On 9/23/2020 7:20 AM, Christian Hopps wrote: > =20 >=20 >=20 > On Sep 23, 2020, at 6:58 AM, Martin Bj=C3=B6rklund > wrote: > =20 > Hi, >=20 > Christian Hopps > wrote: >=20 >=20 >=20 >=20 > On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez > wrote: >=20 >=20 >=20 >=20 > But I would like to check: My understanding is that the changes that > Chris is proposing are pretty small. I.e. move the SA structure under > ipsec-common, and put it under a YANG feature. Are you sure that it > is impractical to accommodate this change which would allow a single > ipsec module to be shared and extended via YANG augmentations? >=20 >=20 > In the context of our I-D, if we move SAD structure to ipsec-common, > what we are meaning is that IPsec SA configuration data (setting > values to the SAD structure) are common to the IKE case and the > IKE-less cases, which are not. It is confusing. >=20 > Something defined in a common module but marked as a feature does not > imply that that feature has to be implemented by an importing > module. This is not confusing to YANG implementers or users I > think. If we are just talking about document flow here, then a > sentence saying "the SAD feature is not required to implement IKE > functionality" is quite enough to clear that up I think. >=20 > Another alternative could be to move these containers to another > (new) module. > =20 > It may also be enough to mark the notifications in the ikeless module = as a feature I suppose. That is the actual thing I think non-SDN = implementations would want to omit. The module name "ikeless" is not = great in this case, but perhaps workable. >=20 >=20 > This is a sub-optimal compromise b/c all IPsec have SA databases even = ones running IKE -- i.e., SA databases are common whether exposed in = YANG or not -- but if it can move it forward perhaps good enough. >=20 >=20 > I'm definitely concerned about IETF process and real world usability = here. These modules are basically workable for ipsec I think, they could = be used by operators today. If we restart the entire process to redo = this work for the more generic IPsec case it will probably be years = before they are finished and in the field. This new work can be started, = but why not have something usable in the meantime? > =20 > Thanks, > Chris. > =20 >=20 >=20 > /martin >=20 >=20 >=20 >=20 >=20 > Thanks, > Chris. >=20 >=20 > Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is > not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and IKE-less. = Again, it seems > confusing. In the IKE case, the SDN/I2NSF controller does not > configure the SAD at all but the IKE implementation in the NSF. In our > opinion, in order to properly add this IPsec SA operational state to > the IKE case we should include operational data about the IPsec SAs > (config false) to the ietf-ipsec-ike. Alternatively, we have certain > operational data (ro) in the SAD structure in the IKE-less case. If > only those are moved to the common part should be ok but we think it > does not solve the problem. >=20 > =20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call = >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = _____________________________= __________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_9DBA0896-01DA-4AE8-AD6F-ED8776315628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rob:

My apologies = but I have just seen this e-mail. We were working on posting last v09 = precisely today, assuming this was all clarified and the decision was to = change the names as Tom suggested.

Regarding your comment, having "the = notifications in the ikeless module as a feature" would not help. Let me = explain. The ikeless module needs something inherent to operate, which = are the notifications. It is not something optional for the ikeless = module to implement.

Hope this helps.

Best Regards.

El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> = escribi=C3=B3:

Hi Rafa, authors,
 
Just to check.
 
Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless = module as a feature"?  This would seem to be a fairly cheap & = easy compromise.
 
Thanks,
Rob
 
 
From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf = Of Lou Berger
Sent: 27 September 2020 15:26
To: Christian Hopps <chopps@chopps.org>; = Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton=3D40cisco.com@dmarc.ietf.org>; i2nsf@ietf.org; Gabriel = Lopez <gabilm@um.es>;= draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; = ipsec@ietf.org; last-call@ietf.org; = Rafa Marin-Lopez <rafa@um.es>; yang-doctors@ietf.org
Subject: Re: [yang-doctors] [IPsec] = [Last-Call] [I2nsf] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
 
This = is a sub-optimal compromise b/c all IPsec have SA databases even ones = running IKE -- i.e., SA databases are common whether exposed in YANG or = not -- but if it can move it forward perhaps good enough.


Speaking = as an interested party, I hope that some compromise / good enough = solution is followed in the -09 version of  this draft.

Lou

On 9/23/2020 7:20 AM, Christian Hopps = wrote:
 


On Sep 23, 2020, at 6:58 AM, Martin = Bj=C3=B6rklund <mbj+ietf@4668.se> = wrote:
 
Hi,

Christian Hopps = <chopps@chopps.org> wrote:




On Sep 23, 2020, at 5:29 AM, Rafa = Marin-Lopez <rafa@um.es> wrote:




But I would like to check: My = understanding is that the changes that
Chris is proposing = are pretty small.  I.e. move the SA structure under
ipsec-common, and put it under a YANG feature.  Are you = sure that it
is impractical to accommodate this change = which would allow a single
ipsec module to be shared and = extended via YANG augmentations?


In the context of our I-D, if = we move SAD structure to ipsec-common,
what we are meaning = is that IPsec SA configuration data (setting
values to the = SAD structure) are common to the IKE case and the
IKE-less = cases, which are not. It is confusing.

Something defined in a common module but = marked as a feature does not
imply that that feature has = to be implemented by an importing
module. This is not = confusing to YANG implementers or users I
think. If we are = just talking about document flow here, then a
sentence = saying "the SAD feature is not required to implement IKE
functionality" is quite enough to clear that up I think.

Another alternative could be to move these = containers to another
(new) module.
 
It may also be = enough to mark the notifications in the ikeless module as a feature I = suppose. That is the actual thing I think non-SDN implementations would = want to omit. The module name "ikeless" is not great in this case, but = perhaps workable.


This is a = sub-optimal compromise b/c all IPsec have SA databases even ones running = IKE -- i.e., SA databases are common whether exposed in YANG or not -- = but if it can move it forward perhaps good enough.


I'm definitely concerned about IETF process and = real world usability here. These modules are basically workable for = ipsec I think, they could be used by operators today. If we restart the = entire process to redo this work for the more generic IPsec case it will = probably be years before they are finished and in the field. This new = work can be started, but why not have something usable in the = meantime?
 
Thanks,
Chris.
 


/martin





Thanks,
Chris.


Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is
not =E2=80=9Ccommon=E2=80=9D = to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does = not
configure the SAD at all but the IKE implementation in = the NSF. In our
opinion, in order to properly add this = IPsec SA operational state to
the IKE case we should = include operational data about the IPsec SAs
(config = false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less = case. If
only those are moved to the common part should be = ok but we think it
does not solve the problem.

 
-- 
last-call = mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_9DBA0896-01DA-4AE8-AD6F-ED8776315628-- From nobody Mon Oct 12 13:21:58 2020 Return-Path: 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 969CF3A0924; Mon, 12 Oct 2020 13:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rxD5fOY3MAXT; Mon, 12 Oct 2020 13:21:54 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 63B633A090B; Mon, 12 Oct 2020 13:21:54 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0B0366046D; Mon, 12 Oct 2020 20:21:52 +0000 (UTC) From: Christian Hopps Message-Id: <10116C35-8FBF-4914-9846-883D2C7F7A11@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_CA75578A-46A3-479A-96A1-3B569DBF40FB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 12 Oct 2020 16:21:51 -0400 In-Reply-To: Cc: Christian Hopps , Robert Wilton , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , "yang-doctors@ietf.org" , Lou Berger To: Rafa Marin-Lopez References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 20:21:57 -0000 --Apple-Mail=_CA75578A-46A3-479A-96A1-3B569DBF40FB Content-Type: multipart/alternative; boundary="Apple-Mail=_A3E336BA-8ED5-454D-AC4A-3BF68BEB56D8" --Apple-Mail=_A3E336BA-8ED5-454D-AC4A-3BF68BEB56D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez wrote: >=20 > Hi Rob: >=20 > My apologies but I have just seen this e-mail. We were working on = posting last v09 precisely today, assuming this was all clarified and = the decision was to change the names as Tom suggested. >=20 > Regarding your comment, having "the notifications in the ikeless = module as a feature" would not help. Let me explain. The ikeless module = needs something inherent to operate, which are the notifications. It is = not something optional for the ikeless module to implement. That does not seem like enough justification for not having the module = be usable in such a broader fashion. It is obvious to anyone = implementing this for your use case that the notifications must be = implemented. If you feel that it is not obvious for some reason a simple = sentence can make that clear. Although I would think that sentence might = start with the word "Obviously, ..." :) Thanks, Chris. >=20 > Hope this helps. >=20 > Best Regards. >=20 >> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) = > escribi=C3=B3: >>=20 >> Hi Rafa, authors, >>=20 >> Just to check. >>=20 >> Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as a feature"? This would = seem to be a fairly cheap & easy compromise. >>=20 >> Thanks, >> Rob >>=20 >>=20 >> From: yang-doctors > On Behalf Of Lou Berger >> Sent: 27 September 2020 15:26 >> To: Christian Hopps >; = Martin Bj=C3=B6rklund > >> Cc: Robert Wilton >; i2nsf@ietf.org = ; Gabriel Lopez >; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org = ; = ipsec@ietf.org ; last-call@ietf.org = ; Rafa Marin-Lopez >; yang-doctors@ietf.org = >> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors = last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>=20 >> This is a sub-optimal compromise b/c all IPsec have SA databases even = ones running IKE -- i.e., SA databases are common whether exposed in = YANG or not -- but if it can move it forward perhaps good enough. >>=20 >>=20 >> Speaking as an interested party, I hope that some compromise / good = enough solution is followed in the -09 version of this draft. >> Lou >>=20 >> On 9/23/2020 7:20 AM, Christian Hopps wrote: >>=20 >>=20 >>=20 >> On Sep 23, 2020, at 6:58 AM, Martin Bj=C3=B6rklund > wrote: >>=20 >> Hi, >>=20 >> Christian Hopps > wrote: >>=20 >>=20 >>=20 >>=20 >> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez > wrote: >>=20 >>=20 >>=20 >>=20 >> But I would like to check: My understanding is that the changes that >> Chris is proposing are pretty small. I.e. move the SA structure = under >> ipsec-common, and put it under a YANG feature. Are you sure that it >> is impractical to accommodate this change which would allow a single >> ipsec module to be shared and extended via YANG augmentations? >>=20 >>=20 >> In the context of our I-D, if we move SAD structure to ipsec-common, >> what we are meaning is that IPsec SA configuration data (setting >> values to the SAD structure) are common to the IKE case and the >> IKE-less cases, which are not. It is confusing. >>=20 >> Something defined in a common module but marked as a feature does not >> imply that that feature has to be implemented by an importing >> module. This is not confusing to YANG implementers or users I >> think. If we are just talking about document flow here, then a >> sentence saying "the SAD feature is not required to implement IKE >> functionality" is quite enough to clear that up I think. >>=20 >> Another alternative could be to move these containers to another >> (new) module. >>=20 >> It may also be enough to mark the notifications in the ikeless module = as a feature I suppose. That is the actual thing I think non-SDN = implementations would want to omit. The module name "ikeless" is not = great in this case, but perhaps workable. >>=20 >>=20 >> This is a sub-optimal compromise b/c all IPsec have SA databases even = ones running IKE -- i.e., SA databases are common whether exposed in = YANG or not -- but if it can move it forward perhaps good enough. >>=20 >>=20 >> I'm definitely concerned about IETF process and real world usability = here. These modules are basically workable for ipsec I think, they could = be used by operators today. If we restart the entire process to redo = this work for the more generic IPsec case it will probably be years = before they are finished and in the field. This new work can be started, = but why not have something usable in the meantime? >>=20 >> Thanks, >> Chris. >>=20 >>=20 >>=20 >> /martin >>=20 >>=20 >>=20 >>=20 >>=20 >> Thanks, >> Chris. >>=20 >>=20 >> Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is >> not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and IKE-less. = Again, it seems >> confusing. In the IKE case, the SDN/I2NSF controller does not >> configure the SAD at all but the IKE implementation in the NSF. In = our >> opinion, in order to properly add this IPsec SA operational state to >> the IKE case we should include operational data about the IPsec SAs >> (config false) to the ietf-ipsec-ike. Alternatively, we have certain >> operational data (ro) in the SAD structure in the IKE-less case. If >> only those are moved to the common part should be ok but we think it >> does not solve the problem. >>=20 >>=20 >> -- >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call = >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = _____________________________= __________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf = > ------------------------------------------------------- > Rafa Marin-Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_A3E336BA-8ED5-454D-AC4A-3BF68BEB56D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez <rafa@um.es> wrote:

Hi Rob:

My apologies but I have just seen this e-mail. = We were working on posting last v09 precisely today, assuming this was = all clarified and the decision was to change the names as Tom = suggested.

Regarding your = comment, having "the notifications in the ikeless module as a feature" = would not help. Let me explain. The ikeless module needs something = inherent to operate, which are the notifications. It is not something = optional for the ikeless module to = implement.

That = does not seem like enough justification for not having the module be = usable in such a broader fashion. It is obvious to anyone implementing = this for your use case that the notifications must be implemented. If = you feel that it is not obvious for some reason a simple sentence can = make that clear. Although I would think that sentence might start with = the word "Obviously, ..." :)

Thanks,
Chris.


Hope this helps.

Best Regards.

El 12 = oct 2020, a las 18:01, Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> = escribi=C3=B3:

Hi Rafa, authors,
 
Just to check.
 
Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as = a feature"?  This would seem to be a fairly cheap & easy = compromise.
 
Thanks,
Rob
 
 
From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf = Of Lou Berger
Sent: 27 September 2020 15:26
To: Christian Hopps <chopps@chopps.org>; = Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton=3D40cisco.com@dmarc.ietf.org>; i2nsf@ietf.org; Gabriel = Lopez <gabilm@um.es>; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; = Rafa Marin-Lopez <rafa@um.es>; yang-doctors@ietf.org
Subject: Re: [yang-doctors] [IPsec] = [Last-Call] [I2nsf] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
 
This is a = sub-optimal compromise b/c all IPsec have SA databases even ones running = IKE -- i.e., SA databases are common whether exposed in YANG or not -- = but if it can move it forward perhaps good enough.


Speaking as an = interested party, I hope that some compromise / good enough solution is = followed in the -09 version of  this draft.

Lou

On 9/23/2020 7:20 AM, Christian Hopps = wrote:
 


On Sep 23, = 2020, at 6:58 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> wrote:
 
Hi,

Christian Hopps = <chopps@chopps.org> wrote:




On Sep = 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es> wrote:




But I would like to = check: My understanding is that the changes that
Chris is = proposing are pretty small.  I.e. move the SA structure under
ipsec-common, and put it under a YANG feature.  Are you = sure that it
is impractical to accommodate this change = which would allow a single
ipsec module to be shared and = extended via YANG augmentations?


In the context of = our I-D, if we move SAD structure to ipsec-common,
what we = are meaning is that IPsec SA configuration data (setting
values to the SAD structure) are common to the IKE case and = the
IKE-less cases, which are not. It is confusing.

Something defined in a common = module but marked as a feature does not
imply that that = feature has to be implemented by an importing
module. This = is not confusing to YANG implementers or users I
think. If = we are just talking about document flow here, then a
sentence saying "the SAD feature is not required to implement = IKE
functionality" is quite enough to clear that up I = think.

Another alternative could be to = move these containers to another
(new) module.
 
It may also be enough to mark the = notifications in the ikeless module as a feature I suppose. That is the = actual thing I think non-SDN implementations would want to omit. The = module name "ikeless" is not great in this case, but perhaps = workable.


This is a sub-optimal compromise b/c all = IPsec have SA databases even ones running IKE -- i.e., SA databases are = common whether exposed in YANG or not -- but if it can move it forward = perhaps good enough.


I'm definitely concerned about IETF = process and real world usability here. These modules are basically = workable for ipsec I think, they could be used by operators today. If we = restart the entire process to redo this work for the more generic IPsec = case it will probably be years before they are finished and in the = field. This new work can be started, but why not have something usable = in the meantime?
 
Thanks,
Chris.
 


/martin





Thanks,
Chris.


Moreover, the usage of feature means that, after = all, this =E2=80=9Ccommon=E2=80=9D is
not =E2=80=9Ccommon=E2= =80=9D to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does = not
configure the SAD at all but the IKE implementation in = the NSF. In our
opinion, in order to properly add this = IPsec SA operational state to
the IKE case we should = include operational data about the IPsec SAs
(config = false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less = case. If
only those are moved to the common part should be = ok but we think it
does not solve the problem.

 
-- 
last-call = mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= --Apple-Mail=_A3E336BA-8ED5-454D-AC4A-3BF68BEB56D8-- --Apple-Mail=_CA75578A-46A3-479A-96A1-3B569DBF40FB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+Eut8ACgkQLh2DDte4 MCXHhA/+M3wdyFzaBTgirCquTnoK07Hce7bOWNP38z9DrtANKox21wItyQhSd0is bdIantdAQhcrOMrM953daB3f0laifg46Ykuw7WEzBrx1JhoX0f0B/P4VDwypLqv4 thuGzjX3oJrXTd82NzsGZgF6T4+BefNbx1zPEvSYCWXe+9zri+/qvaVtAnHO0iox eYUp22ujd7E9wWWbLGZG7bVjZqSUeujch5XbAI2O1ylkLbOc6a3GJeJtg9Q3rLuX HwTrsag3px4R2KxKRcvl0+39g+3c8gcUu27phTZIkbfe3MW8JwS9N2euI+/sIlK3 KTPcuoWbo549GutHnFtg7RMSGYtFMvFxiNusJIWYwpxodRR+RiKYWOZb5nO3NtCq +vPztz5UomNU266icjmwdSvbIxjixWegojqmOKWMzYb7i9tlQgbzqTjkw4gVRwdY l36h7HFYBbT7RgGEfkeLUEKBYUojEIfFbnWd6Vaoh3GRALKe4b1DLvrOh2CHroJy 2Vs3fkH+t/aJFQY/UtOfbhoNDjRCDfS8anvvv8RGbF4v0BuXRCIIYJ9ZVeLg/V6T paCrookEL/JzcswPg+51rKtFOmMZCGwL4vDwMCFnQw9LpnSdKctgnodz4VI7ZY11 SCiJV1erZAoMapxmE+hHn9R3Zh8SbiL7VFFCqSHrp0TjA0sPvSs= =iJtB -----END PGP SIGNATURE----- --Apple-Mail=_CA75578A-46A3-479A-96A1-3B569DBF40FB-- From nobody Mon Oct 12 21:16:21 2020 Return-Path: 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 65F3D3A0925; Mon, 12 Oct 2020 21:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 PKWTI6TUdyF2; Mon, 12 Oct 2020 21:16:16 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound6sev.lav.puc.rediris.es [130.206.19.181]) (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 E8F623A09A4; Mon, 12 Oct 2020 21:16:15 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx02.puc.rediris.es with ESMTP id 09D4G1Ct032462-09D4G1Cu032462; Tue, 13 Oct 2020 06:16:01 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 30B611FF01; Tue, 13 Oct 2020 06:16:01 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Vn3D3uA8q_wJ; Tue, 13 Oct 2020 06:16:01 +0200 (CEST) Received: from [192.168.1.33] (135.red-79-150-250.dynamicip.rima-tde.net [79.150.250.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id C4A662024E; Tue, 13 Oct 2020 06:15:53 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_86C75A4C-578C-4DFD-A1B4-2555C14193A2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Tue, 13 Oct 2020 06:15:52 +0200 In-Reply-To: <10116C35-8FBF-4914-9846-883D2C7F7A11@chopps.org> Cc: Rafa Marin-Lopez , "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "yang-doctors@ietf.org" , Lou Berger To: Christian Hopps , "Rob Wilton (rwilton)" References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> <10116C35-8FBF-4914-9846-883D2C7F7A11@chopps.org> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=rafa@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=BlaINpGGh4b1aMAXRbmZzd6saaXUWKt8dRmRumfZ74U=; b=gPJJTGFEv8NWSvZrcjKj/POeGXScjJVtRRThAZSlRUzQAfC8KUBj62Ur+nLhvwvW6+G6HSQ1QoLG b/Emqs8L/4n41QlFvGgtNJbDcvqDjyeukf/7eNkoXRlXowPgcbAKVOCvmojncJSPMiuemo2w8zvJ gucvetwcuEmwGfs393AbdzIR+48GB5ErjjdpnzZb0sweyCx9s7uqV0STiTftUXtYJpZMakzcN+en OPTHfDw9MTblcu5a3CkFkxUqX1Hoq5mY6SZ7Yx7GylpxPz9wv/xW9QxYvs2olvP6dnlnbW/PH8Ku mRBmPPUzAUmTswiC0rglfdr70POmAX1+K8AX4Q== Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 04:16:20 -0000 --Apple-Mail=_86C75A4C-578C-4DFD-A1B4-2555C14193A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christian (, Rob): Thanks for your comments. We really appreciate them. Please see some = comments inline. > El 12 oct 2020, a las 22:21, Christian Hopps = escribi=C3=B3: >=20 >=20 >=20 >> On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez > wrote: >>=20 >> Hi Rob: >>=20 >> My apologies but I have just seen this e-mail. We were working on = posting last v09 precisely today, assuming this was all clarified and = the decision was to change the names as Tom suggested. >>=20 >> Regarding your comment, having "the notifications in the ikeless = module as a feature" would not help. Let me explain. The ikeless module = needs something inherent to operate, which are the notifications. It is = not something optional for the ikeless module to implement. >=20 > That does not seem like enough justification for not having the module = be usable in such a broader fashion. It is obvious to anyone = implementing this for your use case that the notifications must be = implemented. If you feel that it is not obvious for some reason a simple = sentence can make that clear. Although I would think that sentence might = start with the word "Obviously, ..." :) As you may remember we gave several justifications about why these = changes are not correct in the context of the I2NSF work. Let me send = you the link to avoid repeating myself :)=20 https://mailarchive.ietf.org/arch/msg/i2nsf/IZyRrrTZu7tVm5Kpqe2mw5-kZ1w/ = = =20 Thus, the change =E2=80=9Cthe notifications in the ikeless module as a = feature=E2=80=9D is just the tip of the iceberg of a bigger change = discussed in that link (moving SAD container to the common module). In = other words, just simply adding "the notifications in the ikeless module = as a feature=E2=80=9D is not useful and does not help. In fact, the = notifications must be defined in the ikeless module, and adding a = feature in the ikeless module would not make any sense.=20 As a consequence, the resolution was to move forward with a pragmatic = approach at this point of time, by changing the names of the modules = (and prefixes) to refer to the I2NSF work. Best Regards. >=20 > Thanks, > Chris. >=20 >>=20 >> Hope this helps. >>=20 >> Best Regards. >>=20 >>> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) = > escribi=C3=B3: >>>=20 >>> Hi Rafa, authors, >>> =20 >>> Just to check. >>> =20 >>> Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as a feature"? This would = seem to be a fairly cheap & easy compromise. >>> =20 >>> Thanks, >>> Rob >>> =20 >>> =20 >>> From: yang-doctors > On Behalf Of Lou Berger >>> Sent: 27 September 2020 15:26 >>> To: Christian Hopps >; = Martin Bj=C3=B6rklund > >>> Cc: Robert Wilton >; i2nsf@ietf.org = ; Gabriel Lopez >; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org = ; = ipsec@ietf.org ; last-call@ietf.org = ; Rafa Marin-Lopez >; yang-doctors@ietf.org = >>> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors = last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>> =20 >>> This is a sub-optimal compromise b/c all IPsec have SA databases = even ones running IKE -- i.e., SA databases are common whether exposed = in YANG or not -- but if it can move it forward perhaps good enough. >>>=20 >>>=20 >>> Speaking as an interested party, I hope that some compromise / good = enough solution is followed in the -09 version of this draft. >>> Lou >>>=20 >>> On 9/23/2020 7:20 AM, Christian Hopps wrote: >>> =20 >>>=20 >>>=20 >>> On Sep 23, 2020, at 6:58 AM, Martin Bj=C3=B6rklund > wrote: >>> =20 >>> Hi, >>>=20 >>> Christian Hopps > = wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez > wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> But I would like to check: My understanding is that the changes that >>> Chris is proposing are pretty small. I.e. move the SA structure = under >>> ipsec-common, and put it under a YANG feature. Are you sure that it >>> is impractical to accommodate this change which would allow a single >>> ipsec module to be shared and extended via YANG augmentations? >>>=20 >>>=20 >>> In the context of our I-D, if we move SAD structure to ipsec-common, >>> what we are meaning is that IPsec SA configuration data (setting >>> values to the SAD structure) are common to the IKE case and the >>> IKE-less cases, which are not. It is confusing. >>>=20 >>> Something defined in a common module but marked as a feature does = not >>> imply that that feature has to be implemented by an importing >>> module. This is not confusing to YANG implementers or users I >>> think. If we are just talking about document flow here, then a >>> sentence saying "the SAD feature is not required to implement IKE >>> functionality" is quite enough to clear that up I think. >>>=20 >>> Another alternative could be to move these containers to another >>> (new) module. >>> =20 >>> It may also be enough to mark the notifications in the ikeless = module as a feature I suppose. That is the actual thing I think non-SDN = implementations would want to omit. The module name "ikeless" is not = great in this case, but perhaps workable. >>>=20 >>>=20 >>> This is a sub-optimal compromise b/c all IPsec have SA databases = even ones running IKE -- i.e., SA databases are common whether exposed = in YANG or not -- but if it can move it forward perhaps good enough. >>>=20 >>>=20 >>> I'm definitely concerned about IETF process and real world usability = here. These modules are basically workable for ipsec I think, they could = be used by operators today. If we restart the entire process to redo = this work for the more generic IPsec case it will probably be years = before they are finished and in the field. This new work can be started, = but why not have something usable in the meantime? >>> =20 >>> Thanks, >>> Chris. >>> =20 >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Thanks, >>> Chris. >>>=20 >>>=20 >>> Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is >>> not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and IKE-less. = Again, it seems >>> confusing. In the IKE case, the SDN/I2NSF controller does not >>> configure the SAD at all but the IKE implementation in the NSF. In = our >>> opinion, in order to properly add this IPsec SA operational state to >>> the IKE case we should include operational data about the IPsec SAs >>> (config false) to the ietf-ipsec-ike. Alternatively, we have certain >>> operational data (ro) in the SAD structure in the IKE-less case. If >>> only those are moved to the common part should be ok but we think it >>> does not solve the problem. >>>=20 >>> =20 >>> --=20 >>> last-call mailing list >>> last-call@ietf.org >>> https://www.ietf.org/mailman/listinfo/last-call = >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec = _____________________________= __________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf = >> ------------------------------------------------------- >> Rafa Marin-Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf = ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_86C75A4C-578C-4DFD-A1B4-2555C14193A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Christian (, Rob):

Thanks for your comments. We really appreciate them. Please = see some comments inline.

El 12 oct 2020, a las 22:21, = Christian Hopps <chopps@chopps.org> escribi=C3=B3:



On Oct 12, 2020, at 3:07 PM, = Rafa Marin-Lopez <rafa@um.es> wrote:

Hi Rob:

My apologies but I have just seen this e-mail. = We were working on posting last v09 precisely today, assuming this was = all clarified and the decision was to change the names as Tom = suggested.

Regarding your = comment, having "the notifications in the ikeless module as a feature" = would not help. Let me explain. The ikeless module needs something = inherent to operate, which are the notifications. It is not something = optional for the ikeless module to = implement.

That does not seem like enough = justification for not having the module be usable in such a broader = fashion. It is obvious to anyone implementing this for your use case = that the notifications must be implemented. If you feel that it is not = obvious for some reason a simple sentence can make that clear. Although = I would think that sentence might start with the word "Obviously, ..." = :)

As you = may remember we gave several justifications about why these changes are = not correct in the context of the I2NSF work. Let me send you the link = to avoid repeating myself :) 


Thus, the change = =E2=80=9Cthe notifications in the ikeless module as a feature=E2=80=9D = is just the tip of the iceberg of a bigger change discussed in that link = (moving SAD container to the common module). In other words, just simply = adding "the notifications in the ikeless module as a feature=E2=80=9D is = not useful and does not help. In fact, the notifications must be defined = in the ikeless module, and adding a feature in the ikeless module would = not make any sense. 

As a = consequence, the resolution was to move forward with a pragmatic = approach at this point of time, by changing the names of the modules = (and prefixes) to refer to the I2NSF work.

Best Regards.


Thanks,
Chris.


Hope this = helps.

Best Regards.

El 12 oct 2020, a las 18:01, Rob Wilton = (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> = escribi=C3=B3:

Hi Rafa, authors,
 
Just to check.
 
Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as = a feature"?  This would seem to be a fairly cheap & easy = compromise.
 
Thanks,
Rob
 
 
From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf = Of Lou Berger
Sent: 27 September 2020 15:26
To: Christian Hopps <chopps@chopps.org>; = Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton=3D40cisco.com@dmarc.ietf.org>; i2nsf@ietf.org; Gabriel = Lopez <gabilm@um.es>; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; = Rafa Marin-Lopez <rafa@um.es>; yang-doctors@ietf.org
Subject: Re: [yang-doctors] [IPsec] = [Last-Call] [I2nsf] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
 
This is a = sub-optimal compromise b/c all IPsec have SA databases even ones running = IKE -- i.e., SA databases are common whether exposed in YANG or not -- = but if it can move it forward perhaps good enough.


Speaking as an = interested party, I hope that some compromise / good enough solution is = followed in the -09 version of  this draft.

Lou

On 9/23/2020 7:20 AM, Christian Hopps = wrote:
 


On Sep 23, = 2020, at 6:58 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> wrote:
 
Hi,

Christian Hopps = <chopps@chopps.org> wrote:




On Sep = 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es> wrote:




But I would like to = check: My understanding is that the changes that
Chris is = proposing are pretty small.  I.e. move the SA structure under
ipsec-common, and put it under a YANG feature.  Are you = sure that it
is impractical to accommodate this change = which would allow a single
ipsec module to be shared and = extended via YANG augmentations?


In the context of = our I-D, if we move SAD structure to ipsec-common,
what we = are meaning is that IPsec SA configuration data (setting
values to the SAD structure) are common to the IKE case and = the
IKE-less cases, which are not. It is confusing.

Something defined in a common = module but marked as a feature does not
imply that that = feature has to be implemented by an importing
module. This = is not confusing to YANG implementers or users I
think. If = we are just talking about document flow here, then a
sentence saying "the SAD feature is not required to implement = IKE
functionality" is quite enough to clear that up I = think.

Another alternative could be to = move these containers to another
(new) module.
 
It may also be enough to mark the = notifications in the ikeless module as a feature I suppose. That is the = actual thing I think non-SDN implementations would want to omit. The = module name "ikeless" is not great in this case, but perhaps = workable.


This is a sub-optimal compromise b/c all = IPsec have SA databases even ones running IKE -- i.e., SA databases are = common whether exposed in YANG or not -- but if it can move it forward = perhaps good enough.


I'm definitely concerned about IETF = process and real world usability here. These modules are basically = workable for ipsec I think, they could be used by operators today. If we = restart the entire process to redo this work for the more generic IPsec = case it will probably be years before they are finished and in the = field. This new work can be started, but why not have something usable = in the meantime?
 
Thanks,
Chris.
 


/martin





Thanks,
Chris.


Moreover, the usage of feature means that, after = all, this =E2=80=9Ccommon=E2=80=9D is
not =E2=80=9Ccommon=E2= =80=9D to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does = not
configure the SAD at all but the IKE implementation in = the NSF. In our
opinion, in order to properly add this = IPsec SA operational state to
the IKE case we should = include operational data about the IPsec SAs
(config = false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less = case. If
only those are moved to the common part should be = ok but we think it
does not solve the problem.

 
-- 
last-call = mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_86C75A4C-578C-4DFD-A1B4-2555C14193A2-- From nobody Tue Oct 13 00:23:05 2020 Return-Path: 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 6BACE3A0EC6; Tue, 13 Oct 2020 00:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tdqatxESI7fN; Tue, 13 Oct 2020 00:23:01 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0093A0EC3; Tue, 13 Oct 2020 00:23:01 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id u8so26817340ejg.1; Tue, 13 Oct 2020 00:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=BoKBsOJEjqbqvUd9vDm4Wz99b35O9hgBkWpuMePued0=; b=hAaEr1ELeO51r1h1bsp2NPWlU2h1bgJv8KhitWaWbHMO0UcjfDm3yE43hSdGNgSFr/ KrrNz0QD1w+Hze3ETWTDAn86qfTHjQYjrDkTUEZOhBr9zoS7iXn7sV1MY+zcjayNIDgJ Zo2lO9DiTxfOpprHVXBsBpRS2kx1WpL6BRfkHFhe4RrZtZnrrm9fAoW2N2U5iGkcd67c Jw/3J4AOej1oVCz61QyF+b3c3GflLs6VmDYFLWacY8u35YZiO7iMf1Xf8qkziJoEhf2L yy4XJaJyYgc0N/W2dyDlTDDdJBeGoW7Op74T3NUL6Drpc6GAhQn5hArGt7MG1b8Ga3Nd BUFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=BoKBsOJEjqbqvUd9vDm4Wz99b35O9hgBkWpuMePued0=; b=NLMSSESADet6a/GJ7B593Jklc0Muc9wtE9QhyzYsuqZpZPJrgxIm4moCtdCRnuFOlj MoK6THDmdW6Aq/y5uumMAjfV1rRI+9pAOmqrU9T+IQa21vgXRCOkksTEfCfoNJzB35Q8 O8E1Yghust2WsRUIqoWSAldrm7j5PB+m+ahu4Jdh6JoUkcYT4v1DaCLovbFLJOMXf1eI eDfeYRmBbjXqag8fiYemjehSXx5piVsTt07PfymgmXwjASFlQglRAHoJIED5wzBzbEKT OJacFRIAF630hFGbAM46WoD2mOGCdf4zqCYRU1PpqsrUlLvM/egmGGmW/BOMFjgqd+jQ Es6w== X-Gm-Message-State: AOAM533CS6ZOryx8WJivA7zbuvW4IgbDnZCax0Olp8gElXB3JlUSdzwx Vg84LTYzy07sOLhsBUi7UgbCmyioYKo= X-Google-Smtp-Source: ABdhPJy3bcn2xjtiX5G50x67WwE8Bbmtpm4+PL1p1OGRhINiwozaLIKpGp8eTOktqt5VrnBDSWNnNg== X-Received: by 2002:a17:906:6682:: with SMTP id z2mr33478243ejo.434.1602573779672; Tue, 13 Oct 2020 00:22:59 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id o3sm11781696edv.63.2020.10.13.00.22.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 00:22:59 -0700 (PDT) From: "Valery Smyslov" To: "'Christian Hopps'" , Cc: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> In-Reply-To: <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> Date: Tue, 13 Oct 2020 10:22:58 +0300 Message-ID: <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBR9Dg1QdoZI0c6Vo/AaLkIdpDHgLCxSxRp6m16bA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 07:23:04 -0000 Hi Chris, > Hi ipsecme and chairs, > > This is a small update to the IPTFS draft which incorporates the last 2 changes that had been requested over > the last year or so. > > 1. As requested last year, it dispenses with the late-enabled functionality, replacing it with a SHOULD clause > supporting receiving IPTFS encapsulated ESP payloads w/o extra configuration. I prefer this functionality to be removed. Either you are doing classical tunnel/transport in the SA or you are doing IPTFS. >From my understanding it's just another encapsulation mode. Otherwise we have the following problems: - Since this functionality is optional its capability must be negotiated (or indicated by the peers) in IKEv2. And negotiation of IPTFS features is already complex enough. - It complicates processing in the kernel. E.g, it's not clear for me what "on receipt of the first IP-TFS payload" means. If packets are reordered in the network and the first received IPTFS packet is not the first sent IPTFS packet? What to do with the non-IPTFS packets sent before first IPTFS packet but received after it? And so on. IPTFS processing in the kernel is already quite complex, let's not introduce additional complexity. - I see no value in this functionality apart from the debugging and I don't want debugging capability to be present in the RFC, so that people, who really don't need it, implement it in their products introducing new bugs. You may argue, that you made it optional, but SHOULD is very close to MUST and in addition making it optional only complicates negotiation of IPTFS. So, please, remove it. > 2. It highlights that one must send payloads that carry inner packet fragments using consecutive ESP > sequence numbered packets (with a caveat for all pad payload insertion). That's useful clarification, thanks. Regards, Valery. > We feel the document is quite stable at this point and would thus like to ask for moving to WG Last Call. > > Thanks, > Chris. > > > On Sep 30, 2020, at 12:25 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > > > Title : IP Traffic Flow Security > > Author : Christian Hopps > > Filename : draft-ietf-ipsecme-iptfs-02.txt > > Pages : 26 > > Date : 2020-09-30 > > > > Abstract: > > This document describes a mechanism to enhance IPsec traffic flow > > security by adding traffic flow confidentiality to encrypted IP > > encapsulated traffic. Traffic flow confidentiality is provided by > > obscuring the size and frequency of IP traffic using a fixed-sized, > > constant-send-rate IPsec tunnel. The solution allows for congestion > > control as well. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-02 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > From nobody Tue Oct 13 01:38:50 2020 Return-Path: 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 6E3A43A097C; Tue, 13 Oct 2020 01:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FJa5COP79H4f; Tue, 13 Oct 2020 01:38:34 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 469E23A0992; Tue, 13 Oct 2020 01:38:34 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0E10761679; Tue, 13 Oct 2020 08:38:32 +0000 (UTC) From: Christian Hopps Message-Id: <7C422A91-5543-41A0-B907-6AAD9F83E6DA@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_011F4A32-7E56-4EF1-8008-905FB0467BFB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 13 Oct 2020 04:38:31 -0400 In-Reply-To: Cc: Christian Hopps , "Rob Wilton (rwilton)" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , "yang-doctors@ietf.org" , Lou Berger To: Rafa Marin-Lopez References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> <10116C35-8FBF-4914-9846-883D2C7F7A11@chopps.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 08:38:38 -0000 --Apple-Mail=_011F4A32-7E56-4EF1-8008-905FB0467BFB Content-Type: multipart/alternative; boundary="Apple-Mail=_445EA150-8B61-486D-8188-16D7FF811B67" --Apple-Mail=_445EA150-8B61-486D-8188-16D7FF811B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 13, 2020, at 12:15 AM, Rafa Marin-Lopez wrote: >=20 > Hi Christian (, Rob): >=20 > Thanks for your comments. We really appreciate them. Please see some = comments inline. >=20 >> El 12 oct 2020, a las 22:21, Christian Hopps > escribi=C3=B3: >>=20 >>=20 >>=20 >>> On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez > wrote: >>>=20 >>> Hi Rob: >>>=20 >>> My apologies but I have just seen this e-mail. We were working on = posting last v09 precisely today, assuming this was all clarified and = the decision was to change the names as Tom suggested. >>>=20 >>> Regarding your comment, having "the notifications in the ikeless = module as a feature" would not help. Let me explain. The ikeless module = needs something inherent to operate, which are the notifications. It is = not something optional for the ikeless module to implement. >>=20 >> That does not seem like enough justification for not having the = module be usable in such a broader fashion. It is obvious to anyone = implementing this for your use case that the notifications must be = implemented. If you feel that it is not obvious for some reason a simple = sentence can make that clear. Although I would think that sentence might = start with the word "Obviously, ..." :) >=20 > As you may remember we gave several justifications about why these = changes are not correct in the context of the I2NSF work. Let me send = you the link to avoid repeating myself :) >=20 > = https://mailarchive.ietf.org/arch/msg/i2nsf/IZyRrrTZu7tVm5Kpqe2mw5-kZ1w/ = = >=20 > Thus, the change =E2=80=9Cthe notifications in the ikeless module as a = feature=E2=80=9D is just the tip of the iceberg of a bigger change = discussed in that link (moving SAD container to the common module). In = other words, just simply adding "the notifications in the ikeless module = as a feature=E2=80=9D is not useful and does not help. In fact, the = notifications must be defined in the ikeless module, and adding a = feature in the ikeless module would not make any sense. >=20 > As a consequence, the resolution was to move forward with a pragmatic = approach at this point of time, by changing the names of the modules = (and prefixes) to refer to the I2NSF work. These are 2 different things. The original discussion was about moving = the SAD and SPD from ikeless module to the common one which then would = have brought them into the IKE module, and required people just = implementing IKE to also implement the SAD and SPD parts. In comparison this new compromise request is a tiny change, and allows a = much larger audience to reap the benefit of your work. The change is the = addition of "feature ikeless-notification" and then putting the "if = ikeless-notification" under the notifications. This doesn't change the semantics of your module it just allows people = to re-use the ikeless module for supporting SAD and SPD w/o implementing = the notifications. If you feel more clarity is needed for the SDN use-case then adding the = text, "To allow for greater re-use of this module, the notifications are = marked as a feature. For the SDN use case clients will expect this = feature to be implemented." Features are reported just as modules are in the capabilities. An SDN = client would look for both capabilities rather than just the one (along = with all the other capabilities they will be looking for to actually be = a functional YANG client). Thanks, Chris. >=20 > Best Regards. >=20 >>=20 >> Thanks, >> Chris. >>=20 >>>=20 >>> Hope this helps. >>>=20 >>> Best Regards. >>>=20 >>>> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) = > escribi=C3=B3: >>>>=20 >>>> Hi Rafa, authors, >>>>=20 >>>> Just to check. >>>>=20 >>>> Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as a feature"? This would = seem to be a fairly cheap & easy compromise. >>>>=20 >>>> Thanks, >>>> Rob >>>>=20 >>>>=20 >>>> From: yang-doctors > On Behalf Of Lou Berger >>>> Sent: 27 September 2020 15:26 >>>> To: Christian Hopps >; = Martin Bj=C3=B6rklund > >>>> Cc: Robert Wilton >; i2nsf@ietf.org = ; Gabriel Lopez >; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org = ; = ipsec@ietf.org ; last-call@ietf.org = ; Rafa Marin-Lopez >; yang-doctors@ietf.org = >>>> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors = last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>>>=20 >>>> This is a sub-optimal compromise b/c all IPsec have SA databases = even ones running IKE -- i.e., SA databases are common whether exposed = in YANG or not -- but if it can move it forward perhaps good enough. >>>>=20 >>>>=20 >>>> Speaking as an interested party, I hope that some compromise / good = enough solution is followed in the -09 version of this draft. >>>> Lou >>>>=20 >>>> On 9/23/2020 7:20 AM, Christian Hopps wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 23, 2020, at 6:58 AM, Martin Bj=C3=B6rklund = > wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Christian Hopps > = wrote: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez > wrote: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> But I would like to check: My understanding is that the changes = that >>>> Chris is proposing are pretty small. I.e. move the SA structure = under >>>> ipsec-common, and put it under a YANG feature. Are you sure that = it >>>> is impractical to accommodate this change which would allow a = single >>>> ipsec module to be shared and extended via YANG augmentations? >>>>=20 >>>>=20 >>>> In the context of our I-D, if we move SAD structure to = ipsec-common, >>>> what we are meaning is that IPsec SA configuration data (setting >>>> values to the SAD structure) are common to the IKE case and the >>>> IKE-less cases, which are not. It is confusing. >>>>=20 >>>> Something defined in a common module but marked as a feature does = not >>>> imply that that feature has to be implemented by an importing >>>> module. This is not confusing to YANG implementers or users I >>>> think. If we are just talking about document flow here, then a >>>> sentence saying "the SAD feature is not required to implement IKE >>>> functionality" is quite enough to clear that up I think. >>>>=20 >>>> Another alternative could be to move these containers to another >>>> (new) module. >>>>=20 >>>> It may also be enough to mark the notifications in the ikeless = module as a feature I suppose. That is the actual thing I think non-SDN = implementations would want to omit. The module name "ikeless" is not = great in this case, but perhaps workable. >>>>=20 >>>>=20 >>>> This is a sub-optimal compromise b/c all IPsec have SA databases = even ones running IKE -- i.e., SA databases are common whether exposed = in YANG or not -- but if it can move it forward perhaps good enough. >>>>=20 >>>>=20 >>>> I'm definitely concerned about IETF process and real world = usability here. These modules are basically workable for ipsec I think, = they could be used by operators today. If we restart the entire process = to redo this work for the more generic IPsec case it will probably be = years before they are finished and in the field. This new work can be = started, but why not have something usable in the meantime? >>>>=20 >>>> Thanks, >>>> Chris. >>>>=20 >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>> Chris. >>>>=20 >>>>=20 >>>> Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is >>>> not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and IKE-less. = Again, it seems >>>> confusing. In the IKE case, the SDN/I2NSF controller does not >>>> configure the SAD at all but the IKE implementation in the NSF. In = our >>>> opinion, in order to properly add this IPsec SA operational state = to >>>> the IKE case we should include operational data about the IPsec SAs >>>> (config false) to the ietf-ipsec-ike. Alternatively, we have = certain >>>> operational data (ro) in the SAD structure in the IKE-less case. If >>>> only those are moved to the common part should be ok but we think = it >>>> does not solve the problem. >>>>=20 >>>>=20 >>>> -- >>>> last-call mailing list >>>> last-call@ietf.org >>>> https://www.ietf.org/mailman/listinfo/last-call = >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec = _____________________________= __________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2nsf = >>> ------------------------------------------------------- >>> Rafa Marin-Lopez, PhD >>> Dept. Information and Communications Engineering (DIIC) >>> Faculty of Computer Science-University of Murcia >>> 30100 Murcia - Spain >>> Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = >>> ------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec = >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf = > ------------------------------------------------------- > Rafa Marin-Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_445EA150-8B61-486D-8188-16D7FF811B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 13, 2020, at 12:15 AM, Rafa Marin-Lopez <rafa@um.es> wrote:

Hi Christian (, Rob):

Thanks for your comments. We really appreciate = them. Please see some comments inline.

El 12 = oct 2020, a las 22:21, Christian Hopps <chopps@chopps.org> = escribi=C3=B3:



On Oct = 12, 2020, at 3:07 PM, Rafa Marin-Lopez <rafa@um.es> wrote:

Hi Rob:

My apologies but I have just seen this e-mail. = We were working on posting last v09 precisely today, assuming this was = all clarified and the decision was to change the names as Tom = suggested.

Regarding your = comment, having "the notifications in the ikeless module as a feature" = would not help. Let me explain. The ikeless module needs something = inherent to operate, which are the notifications. It is not something = optional for the ikeless module to = implement.

That does not seem like enough = justification for not having the module be usable in such a broader = fashion. It is obvious to anyone implementing this for your use case = that the notifications must be implemented. If you feel that it is not = obvious for some reason a simple sentence can make that clear. Although = I would think that sentence might start with the word "Obviously, ..." = :)

As you may remember we gave several justifications about why = these changes are not correct in the context of the I2NSF work. Let me = send you the link to avoid repeating myself :) 

https://mailarchive.ietf.org/arch/msg/i2nsf/IZyRrrTZu7tVm5Kpqe2= mw5-kZ1w/ 

Thus, the change =E2=80=9Cthe notifications in the ikeless = module as a feature=E2=80=9D is just the tip of the iceberg of a bigger = change discussed in that link (moving SAD container to the common = module). In other words, just simply adding "the notifications in the = ikeless module as a feature=E2=80=9D is not useful and does not help. In = fact, the notifications must be defined in the ikeless module, and = adding a feature in the ikeless module would not make any = sense. 

As = a consequence, the resolution was to move forward with a pragmatic = approach at this point of time, by changing the names of the modules = (and prefixes) to refer to the I2NSF = work.

These are 2 different things. The original = discussion was about moving the SAD and SPD from ikeless module to the = common one which then would have brought them into the IKE module, and = required people just implementing IKE to also implement the SAD and SPD = parts.

In comparison this new = compromise request is a tiny change, and allows a much larger audience = to reap the benefit of your work. The change is the addition of "feature = ikeless-notification" and then putting the "if ikeless-notification" = under the notifications.

This = doesn't change the semantics of your module it just allows people to = re-use the ikeless module for supporting SAD and SPD w/o implementing = the notifications.

If you feel more = clarity is needed for the SDN use-case then adding the text, "To allow = for greater re-use of this module, the notifications are marked as a = feature. For the SDN use case clients will expect this feature to be = implemented."

Features are = reported just as modules are in the capabilities. An SDN client would = look for both capabilities rather than just the one (along with all the = other capabilities they will be looking for to actually be a functional = YANG client).

Thanks,
Chris.


Best Regards.


Thanks,
Chris.


Hope this helps.

Best Regards.

El 12 = oct 2020, a las 18:01, Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> = escribi=C3=B3:

Hi Rafa, authors,
 
Just to check.
 
Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as = a feature"?  This would seem to be a fairly cheap & easy = compromise.
 
Thanks,
Rob
 
 
From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf = Of Lou Berger
Sent: 27 September 2020 15:26
To: Christian Hopps <chopps@chopps.org>; = Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton=3D40cisco.com@dmarc.ietf.org>; i2nsf@ietf.org; Gabriel = Lopez <gabilm@um.es>; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; = Rafa Marin-Lopez <rafa@um.es>; yang-doctors@ietf.org
Subject: Re: [yang-doctors] [IPsec] = [Last-Call] [I2nsf] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
 
This is a = sub-optimal compromise b/c all IPsec have SA databases even ones running = IKE -- i.e., SA databases are common whether exposed in YANG or not -- = but if it can move it forward perhaps good enough.


Speaking as an = interested party, I hope that some compromise / good enough solution is = followed in the -09 version of  this draft.

Lou

On 9/23/2020 7:20 AM, Christian Hopps = wrote:
 


On Sep 23, = 2020, at 6:58 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> wrote:
 
Hi,

Christian Hopps = <chopps@chopps.org> wrote:




On Sep = 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es> wrote:




But I would like to = check: My understanding is that the changes that
Chris is = proposing are pretty small.  I.e. move the SA structure under
ipsec-common, and put it under a YANG feature.  Are you = sure that it
is impractical to accommodate this change = which would allow a single
ipsec module to be shared and = extended via YANG augmentations?


In the context of = our I-D, if we move SAD structure to ipsec-common,
what we = are meaning is that IPsec SA configuration data (setting
values to the SAD structure) are common to the IKE case and = the
IKE-less cases, which are not. It is confusing.

Something defined in a common = module but marked as a feature does not
imply that that = feature has to be implemented by an importing
module. This = is not confusing to YANG implementers or users I
think. If = we are just talking about document flow here, then a
sentence saying "the SAD feature is not required to implement = IKE
functionality" is quite enough to clear that up I = think.

Another alternative could be to = move these containers to another
(new) module.
 
It may also be enough to mark the = notifications in the ikeless module as a feature I suppose. That is the = actual thing I think non-SDN implementations would want to omit. The = module name "ikeless" is not great in this case, but perhaps = workable.


This is a sub-optimal compromise b/c all = IPsec have SA databases even ones running IKE -- i.e., SA databases are = common whether exposed in YANG or not -- but if it can move it forward = perhaps good enough.


I'm definitely concerned about IETF = process and real world usability here. These modules are basically = workable for ipsec I think, they could be used by operators today. If we = restart the entire process to redo this work for the more generic IPsec = case it will probably be years before they are finished and in the = field. This new work can be started, but why not have something usable = in the meantime?
 
Thanks,
Chris.
 


/martin





Thanks,
Chris.


Moreover, the usage of feature means that, after = all, this =E2=80=9Ccommon=E2=80=9D is
not =E2=80=9Ccommon=E2= =80=9D to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does = not
configure the SAD at all but the IKE implementation in = the NSF. In our
opinion, in order to properly add this = IPsec SA operational state to
the IKE case we should = include operational data about the IPsec SAs
(config = false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less = case. If
only those are moved to the common part should be = ok but we think it
does not solve the problem.

 
-- 
last-call = mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= --Apple-Mail=_445EA150-8B61-486D-8188-16D7FF811B67-- --Apple-Mail=_011F4A32-7E56-4EF1-8008-905FB0467BFB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+FZ4cACgkQLh2DDte4 MCUoBw/7BeAw9RxI9QYZGzbk4TVu/9SsW9PX6ouvomOxAS+Rf7HUPRxS6ppGnEdf todua/iN+eY8V7Y7/8LKNIXaRZF5gFuBgEYL8v0INl464CdV5Dsu3UeIM63xwDgg oq4PzEcqpqzcnyL2uUjfw7IiqdGsU1uldqzT0BUe0Qd6xnsReruWXKjJuklzpnKr eXw1wp6sAAnGy5tvLpjbLnQvr6qOe8YFkbYdW7YCMPmuTBfZtcfnSshxHoNORkHT p7eLUcvHNNh/8aCgZa+yElXxdX7SYpzqzGOnJwGjkBbafO8sZOlWOULFB7DLuBqX sAc6LZmx+xvM3XzPIl8lggv2vjvNWKosgRl/XorhKKYOfPgrXQXSNVLXMalCBT46 sR8z05V7D9XYCaCgRLpHCG8lvH8D3uQaBDl6/jyl+7SOVKOYmrWaYbRcaMgMV4a7 LK3zGubQDHtNHgdLxDPFTxb8WybMlD/zw14gG2+9d4rww5EW+KYrlKc4euhw8Hc5 JPkbCY1hZq7WoblgL865hMtxNvVBRx+Ck2q6Xtc8Jg3KlWUM33vgWXs1r8LIGz/x BYyX+Vev7/jRN7ndafZ2FGe2EZ57o8b7RgoXJmMc8a8Kg1e3dfH5zXHLCFZCaCqQ wNPSJ3OwqUwpuZ3SseERh0EKT6i7S2doVzgrI3a2r/dmC8FSUmk= =oFq7 -----END PGP SIGNATURE----- --Apple-Mail=_011F4A32-7E56-4EF1-8008-905FB0467BFB-- From nobody Tue Oct 13 04:27:27 2020 Return-Path: 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 ED0323A0F5B for ; Tue, 13 Oct 2020 04:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 c-I7RaKlW1so for ; Tue, 13 Oct 2020 04:27:24 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 438E83A09F6 for ; Tue, 13 Oct 2020 04:27:24 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id BD77814044E for ; Tue, 13 Oct 2020 05:27:17 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id SISbkc2MhDlydSISbkZa9f; Tue, 13 Oct 2020 05:27:17 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=Ofe28CbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=afefHYAZSVUA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=bzp_J528P0tcQY3hi4gA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bLBPmxOOFPZwvaEz8QkYXurqaz012/C45Kt8cFmlyRA=; b=jYfQESZtwb/9m27+PvKkE7HtJO LzT/L4M5evt1a0K+2CodP/YYW/Sdqe1McP2P6vumdFRiXTQnX/41MgjvDmrzru7cU592EPjgp91uh c7rgQTttMUfxTGSQ1rQljuKxW; Received: from [127.0.0.1] (port=43665 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kSISb-002681-9P; Tue, 13 Oct 2020 05:27:17 -0600 To: Valery Smyslov , 'Christian Hopps' , ipsec@ietf.org Cc: ipsecme-chairs@ietf.org References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> From: Lou Berger Message-ID: Date: Tue, 13 Oct 2020 07:27:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1kSISb-002681-9P X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:43665 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 11:27:26 -0000 Valery, Please see below. On 10/13/2020 3:22 AM, Valery Smyslov wrote: > Hi Chris, > >> Hi ipsecme and chairs, >> >> This is a small update to the IPTFS draft which incorporates the last 2 changes that had been requested over >> the last year or so. >> >> 1. As requested last year, it dispenses with the late-enabled functionality, replacing it with a SHOULD clause >> supporting receiving IPTFS encapsulated ESP payloads w/o extra configuration. > I prefer this functionality to be removed. Either you are doing classical tunnel/transport in the SA or you are doing IPTFS. I agree that there is added code complexity, but have you considered the operational benefit of having this?  Specifically (a) adding yet another required configuration parameter that must match at both ends to get an ipsec tunnels up and (b) what it takes to go from an operational non-TFS configuration to a TFS configuration in one or both directions? > >From my understanding it's just another encapsulation mode. Otherwise we have the following problems: > - Since this functionality is optional its capability must be negotiated (or indicated by the peers) in IKEv2. > And negotiation of IPTFS features is already complex enough. I'm not sure what needs to be negotiated here -- without negotiation the behavior is the same as would be seen with a miss-configured  endpoint or mismatch in TFS config that will occur without the option. > - It complicates processing in the kernel. E.g, it's not clear for me what "on receipt of the first IP-TFS payload" means. > If packets are reordered in the network and the first received IPTFS packet is not the first sent IPTFS packet? > What to do with the non-IPTFS packets sent before first IPTFS packet but received after it? And so on. This is an implementation choice, right?  Why not just drop it or process it as the implementation sees fit? > IPTFS processing in the kernel is already quite complex, let's not introduce additional complexity. > - I see no value in this functionality apart from the debugging and I don't want debugging capability to > be present in the RFC, so that people, who really don't need it, implement it in > their products introducing new bugs. You may argue, that you made it optional, but SHOULD is very close > to MUST and in addition making it optional only complicates negotiation of IPTFS. My view is that the main benefit is simpler configuration and removing a requirement for timing manual configuration changes at each end of a tunnel.  Configuring IPsec is complex enough,  from the operational perspective, I'd prefer to see this as a MUST, but can live with SHOULD.  (IMO - Getting the code right once per implementation is greatly outweighed by the returns in not having to impose more configuration and configuration timing burdens.) Thanks, Lou > So, please, remove it. > >> 2. It highlights that one must send payloads that carry inner packet fragments using consecutive ESP >> sequence numbered packets (with a caveat for all pad payload insertion). > That's useful clarification, thanks. > > Regards, > Valery. > >> We feel the document is quite stable at this point and would thus like to ask for moving to WG Last Call. >> >> Thanks, >> Chris. >> >>> On Sep 30, 2020, at 12:25 PM, internet-drafts@ietf.org wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. >>> >>> Title : IP Traffic Flow Security >>> Author : Christian Hopps >>> Filename : draft-ietf-ipsecme-iptfs-02.txt >>> Pages : 26 >>> Date : 2020-09-30 >>> >>> Abstract: >>> This document describes a mechanism to enhance IPsec traffic flow >>> security by adding traffic flow confidentiality to encrypted IP >>> encapsulated traffic. Traffic flow confidentiality is provided by >>> obscuring the size and frequency of IP traffic using a fixed-sized, >>> constant-send-rate IPsec tunnel. The solution allows for congestion >>> control as well. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 >>> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-02 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Oct 13 05:06:32 2020 Return-Path: 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 E4F283A0F8A; Tue, 13 Oct 2020 05:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UCll0Yraougu; Tue, 13 Oct 2020 05:06:29 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id CC0313A0F86; Tue, 13 Oct 2020 05:06:28 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0974461674; Tue, 13 Oct 2020 12:06:27 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AAF29A86-2476-4853-AB52-135CF4DEC08C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 13 Oct 2020 08:06:26 -0400 In-Reply-To: Cc: Christian Hopps , ipsec@ietf.org, ipsecme-chairs@ietf.org, Lou Berger To: Valery Smyslov References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 12:06:31 -0000 --Apple-Mail=_AAF29A86-2476-4853-AB52-135CF4DEC08C Content-Type: multipart/alternative; boundary="Apple-Mail=_084FC542-7FEC-4883-A49B-689AB4EEF5DD" --Apple-Mail=_084FC542-7FEC-4883-A49B-689AB4EEF5DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 13, 2020, at 7:27 AM, Lou Berger wrote: >=20 > Valery, >=20 > Please see below. >=20 > On 10/13/2020 3:22 AM, Valery Smyslov wrote: >> Hi Chris, >>=20 >>> Hi ipsecme and chairs, >>>=20 >>> This is a small update to the IPTFS draft which incorporates the = last 2 changes that had been requested over >>> the last year or so. >>>=20 >>> 1. As requested last year, it dispenses with the late-enabled = functionality, replacing it with a SHOULD clause >>> supporting receiving IPTFS encapsulated ESP payloads w/o extra = configuration. >> I prefer this functionality to be removed. Either you are doing = classical tunnel/transport in the SA or you are doing IPTFS. >=20 > I agree that there is added code complexity, but have you considered = the operational benefit of having this? Specifically (a) adding yet = another required configuration parameter that must match at both ends to = get an ipsec tunnels up and (b) what it takes to go from an operational = non-TFS configuration to a TFS configuration in one or both directions? FWIW, there really was no complexity to support this. If one chooses to = support it (it is a SHOULD not a MUST after all), you initialize a small = amount of receive side IPTFS state for INBOUND SAs. The change to add = this functionality to our implementation required: Code: add global always rx tfs ability 3 files changed, 38 insertions(+), 6 deletions(-) ... Less than 50 lines of (init/config) code were modified, quite minimal = actually. Perhaps most importantly to your concern, nothing in the = data-path (fast-path) actually needs to change. It simplifies configurations for people that are using systems other = than IKE for IPsec configuration, it's easy to add to the code, and it's = not required (SHOULD not MUST). So I think it's good support this. Thanks, Chris. >=20 >> >=46rom my understanding it's just another encapsulation mode. = Otherwise we have the following problems: >> - Since this functionality is optional its capability must be = negotiated (or indicated by the peers) in IKEv2. >> And negotiation of IPTFS features is already complex enough. >=20 > I'm not sure what needs to be negotiated here -- without negotiation = the behavior is the same as would be seen with a miss-configured = endpoint or mismatch in TFS config that will occur without the option. >=20 >> - It complicates processing in the kernel. E.g, it's not clear for me = what "on receipt of the first IP-TFS payload" means. >> If packets are reordered in the network and the first received = IPTFS packet is not the first sent IPTFS packet? >> What to do with the non-IPTFS packets sent before first IPTFS = packet but received after it? And so on. >=20 > This is an implementation choice, right? Why not just drop it or = process it as the implementation sees fit? >=20 >> IPTFS processing in the kernel is already quite complex, let's not = introduce additional complexity. >> - I see no value in this functionality apart from the debugging and I = don't want debugging capability to >> be present in the RFC, so that people, who really don't need it, = implement it in >> their products introducing new bugs. You may argue, that you made = it optional, but SHOULD is very close >> to MUST and in addition making it optional only complicates = negotiation of IPTFS. >=20 > My view is that the main benefit is simpler configuration and removing = a requirement for timing manual configuration changes at each end of a = tunnel. Configuring IPsec is complex enough, from the operational = perspective, I'd prefer to see this as a MUST, but can live with SHOULD. = (IMO - Getting the code right once per implementation is greatly = outweighed by the returns in not having to impose more configuration and = configuration timing burdens.) >=20 > Thanks, >=20 > Lou >=20 >> So, please, remove it. >>=20 >>> 2. It highlights that one must send payloads that carry inner packet = fragments using consecutive ESP >>> sequence numbered packets (with a caveat for all pad payload = insertion). >> That's useful clarification, thanks. >>=20 >> Regards, >> Valery. >>=20 >>> We feel the document is quite stable at this point and would thus = like to ask for moving to WG Last Call. >>>=20 >>> Thanks, >>> Chris. >>>=20 >>>> On Sep 30, 2020, at 12:25 PM, internet-drafts@ietf.org wrote: >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the IP Security Maintenance and = Extensions WG of the IETF. >>>>=20 >>>> Title : IP Traffic Flow Security >>>> Author : Christian Hopps >>>> Filename : draft-ietf-ipsecme-iptfs-02.txt >>>> Pages : 26 >>>> Date : 2020-09-30 >>>>=20 >>>> Abstract: >>>> This document describes a mechanism to enhance IPsec traffic flow >>>> security by adding traffic flow confidentiality to encrypted IP >>>> encapsulated traffic. Traffic flow confidentiality is provided = by >>>> obscuring the size and frequency of IP traffic using a = fixed-sized, >>>> constant-send-rate IPsec tunnel. The solution allows for = congestion >>>> control as well. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ >>>>=20 >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-02 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_084FC542-7FEC-4883-A49B-689AB4EEF5DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 13, 2020, at 7:27 AM, Lou Berger <lberger@labn.net> = wrote:

Valery,

Please see below.

On 10/13/2020 3:22 AM, Valery Smyslov wrote:
Hi = Chris,

Hi ipsecme and chairs,

This is a = small update to the IPTFS draft which incorporates the last 2 changes = that had been requested over
the last year or so.

1. As requested last year, it dispenses with = the late-enabled functionality, replacing it with a SHOULD clause
supporting receiving IPTFS encapsulated ESP payloads w/o = extra configuration.
I prefer this = functionality to be removed. Either you are doing classical = tunnel/transport in the SA or you are doing IPTFS.

I agree that there is added code complexity, but have you = considered the operational benefit of having this?  Specifically = (a) adding yet another required configuration parameter that must match = at both ends to get an ipsec tunnels up and (b) what it takes to go from = an operational non-TFS configuration to a TFS configuration in one or = both directions?

FWIW, there really was no complexity to support = this. If one chooses to support it (it is a SHOULD not a MUST after = all), you initialize a small amount of receive side IPTFS state for = INBOUND SAs. The change to add this functionality to our implementation = required:

  Code: add global = always rx tfs ability

  3 files = changed, 38 insertions(+), 6 deletions(-)
  = ...

Less than 50 lines of = (init/config) code were modified, quite minimal actually. Perhaps most = importantly to your concern, nothing in the data-path (fast-path) = actually needs to change.

It simplifies configurations for people that are using = systems other than IKE for IPsec configuration, it's easy to add to the = code, and it's not required (SHOULD not MUST). So I think it's good = support this.

Thanks,
Chris.


>=46rom my understanding it's just another encapsulation = mode. Otherwise we have the following problems:
- Since = this functionality is optional its capability must be negotiated (or = indicated by the peers) in IKEv2.
   And = negotiation of IPTFS features is already complex enough.

I'm not sure what needs to be negotiated here -- without = negotiation the behavior is the same as would be seen with a = miss-configured  endpoint or mismatch in TFS config that will occur = without the option.

- It complicates processing in the = kernel. E.g, it's not clear for me what "on receipt of the first IP-TFS = payload" means.
   If packets are reordered = in the network and the first received IPTFS packet is not the first sent = IPTFS packet?
   What to do with the = non-IPTFS packets sent before first IPTFS packet but received after it? = And so on.

This is an implementation choice, right?  Why not just = drop it or process it as the implementation sees fit?

   IPTFS processing in the kernel is already = quite complex, let's not introduce additional complexity.
- = I see no value in this functionality apart from the debugging and I = don't want debugging capability to
   be = present in the RFC, so that people, who really don't need it, implement = it in
   their products introducing new = bugs. You may argue, that you made it optional, but SHOULD is very = close
   to MUST and in addition making it = optional only complicates negotiation of IPTFS.

My view is that the main benefit is simpler configuration and = removing a requirement for timing manual configuration changes at each = end of a tunnel.  Configuring IPsec is complex enough,  from = the operational perspective, I'd prefer to see this as a MUST, but can = live with SHOULD.  (IMO - Getting the code right once per = implementation is greatly outweighed by the returns in not having to = impose more configuration and configuration timing burdens.)

Thanks,

Lou

So, please, remove it.

2. It = highlights that one must send payloads that carry inner packet fragments = using consecutive ESP
sequence numbered packets (with a = caveat for all pad payload insertion).
That's = useful clarification, thanks.

Regards,
Valery.

We feel the document is quite stable at this point and would = thus like to ask for moving to WG Last Call.

Thanks,
Chris.

On Sep 30, 2020, at = 12:25 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work = item of the IP Security Maintenance and Extensions WG of the IETF.

       Title =           : IP Traffic = Flow Security
       Author =          : Christian = Hopps
Filename        : = draft-ietf-ipsecme-iptfs-02.txt
Pages =           : 26
= Date =            : = 2020-09-30

Abstract:
  This document describes a mechanism to enhance = IPsec traffic flow
  security by adding traffic = flow confidentiality to encrypted IP
  encapsulated traffic.  Traffic flow = confidentiality is provided by
  obscuring the = size and frequency of IP traffic using a fixed-sized,
  constant-send-rate IPsec tunnel.  The = solution allows for congestion
  control as = well.


The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/<= br class=3D"">
There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-= 02

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-02=


Please note that it may = take a couple of minutes from the time of submission
until = the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_084FC542-7FEC-4883-A49B-689AB4EEF5DD-- --Apple-Mail=_AAF29A86-2476-4853-AB52-135CF4DEC08C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+FmEIACgkQLh2DDte4 MCUH9Q/+KQDoyNGGpSKGUyafYsIq0czGXJekOVQawWVOeQcEFhLstQQUthT1tXho OE/Sm6MGQRvxpOfFs/S3gfEILGeAQzQw2befEUmAeAOOgDVVXliCLqcbq+m0r7VC k6CmJlZ+Ay6b0Fek0V7SxpdPY+zvK4iE8fDwQCoj/tPVD8eUnXqQ0HOhMd/T80Ar qvxOZlg6FjLMsV8+PqfxQBsijYoFtYFZ+Xi+/Fjent0tPs6u2fX9idVIfccGfgLk H5Ygm0ZPaLmq2rwYLeG8WdBZ2u+F2I6zgSjbbmE2/tEsH/saFi2+Zc1TrAU4JyBl CjbzsaUG6cJFiq0ZdmGhc6IexsOfUvwHDrxf5KzRpOqCfQ18EUY52pO4Un+muCET UT9u//x7Nc+cssACLatEW28HW/WVNiHN7wtfHo6FwG7fDT7CyI8VbOOz/PT6WCkE q18Uid4tGlwbFsFN9oCNukJPnRoENAGKBNh5j5XKIXfT6yhY7E1A6XnItvAQf9ij uFkqz00CXaHU2vIwKr89TojY5q3EygfR/v7pkcxIWWYb+KJHRaD9i5AM+SfC9BXF 4pkGDITNOHk2DobGh4QHShZCP4SNGgJtmJcYlJn6WQnjbLv4Qyki70/XXzliCNw6 yOBF/nBXQ65mbKpIdJtC/mFEruqpyQ9nc7frEMOcGd4jLjjYA2U= =cIub -----END PGP SIGNATURE----- --Apple-Mail=_AAF29A86-2476-4853-AB52-135CF4DEC08C-- From nobody Tue Oct 13 06:16:52 2020 Return-Path: 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 3779D3A1036; Tue, 13 Oct 2020 06:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 x0JhEIAwj9nZ; Tue, 13 Oct 2020 06:16:42 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EED73A1034; Tue, 13 Oct 2020 06:16:41 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id v6so6396953lfa.13; Tue, 13 Oct 2020 06:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=7bsM6/Wz/Qa7NRrXcBHk/xhvWHXSsJmrFjRsk+hT3/o=; b=aC5MGCKoHdRuqRnJPaUQkNzCH/fsVEIIXweM3+7nj6Uvsexl/bXfnCnljUMvAjbjE+ wkBbQg9RGpNRAN2Wlo0ZAahmly1XQL91lL3Qp2TTBXtQSTYGLDUlObe2JKrvRgTINYOY 0sGXOD+VZJzuJKaRLFZB6z7mdcydboaft2So+SQ47Y6l796BG1B6HLdmBsAwr+hjITG0 evcknclE01GLuDUM3lya/lUkuUVh29k2vPC0ZI23fNoSfElObggNT9kw1rEEC6qT3o4m gYVd5TNjtydbhSlpGCfGomBIqCBXWrtJLoHCuQMjeAG1y017+e9QdTDfOinh1R8ZZrNR wrvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=7bsM6/Wz/Qa7NRrXcBHk/xhvWHXSsJmrFjRsk+hT3/o=; b=ipoaECEqQ0jSEgMD+wiIXXMu42HLiiZNVSeWAePrSPY5CLW1zWg931aPVCJJHCuTPm 5cuOjKiGgyccX7Hm1ahYMmbwOjkO0G7qEf6NydbIf/X1R0BdHSd6aQIEcKEIluQHj1sJ ybRjc8uvJqEiptjjn+ihd1mTm60U91sKICQ+IAPsv0ngqFDMwMXAcogPSQvEajukIACM LZa392KslYtcob8R7F/0PHKOuaNGmEilGXleOvvKFhSroqU/oKDRF0XoODlDbOH7WdrD TwpTxl28crFVDFsQY+DVueDbM4/Hf6bOF8L97SgfKK9QzVa3FoDSjICeg/hQ06y3LKhe Qyqw== X-Gm-Message-State: AOAM533KhoZvUN5QmTYFp1J4PfB7BurospQ+8DV8g5ZXQzISW9dBPXhR yS+cBfU+MfYs0pXigmbSxTk= X-Google-Smtp-Source: ABdhPJzdPc/WJMqkWm22k2M1QS9s7/9X3qX+ejRFmaHR7MpI/9aedinb68yl0Q4us1KrFzRHw3C1uA== X-Received: by 2002:a19:f517:: with SMTP id j23mr5580500lfb.152.1602594999078; Tue, 13 Oct 2020 06:16:39 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id 65sm4380095lfb.260.2020.10.13.06.16.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 06:16:38 -0700 (PDT) From: "Valery Smyslov" To: "'Lou Berger'" , "'Christian Hopps'" , Cc: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> In-Reply-To: Date: Tue, 13 Oct 2020 16:16:39 +0300 Message-ID: <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBR9Dg1QdoZI0c6Vo/AaLkIdpDHgLCxSxRAjbXs18B6rBqnaeI/wkQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 13:16:51 -0000 Hi Lou, > Valery, > > Please see below. > > On 10/13/2020 3:22 AM, Valery Smyslov wrote: > > Hi Chris, > > > >> Hi ipsecme and chairs, > >> > >> This is a small update to the IPTFS draft which incorporates the last 2 changes that had been requested > over > >> the last year or so. > >> > >> 1. As requested last year, it dispenses with the late-enabled functionality, replacing it with a SHOULD > clause > >> supporting receiving IPTFS encapsulated ESP payloads w/o extra configuration. > > I prefer this functionality to be removed. Either you are doing classical tunnel/transport in the SA or you are > doing IPTFS. > > I agree that there is added code complexity, but have you considered the > operational benefit of having this? Specifically (a) adding yet another > required configuration parameter that must match at both ends to get an > ipsec tunnels up and (b) what it takes to go from an operational non-TFS > configuration to a TFS configuration in one or both directions? I can't buy these arguments. Using IPTFS is negotiated in IKEv2 via exchange of USE_IPTFS notify (BTW, note a typo in Section 5.1 title: USE_TFS instead of USE_IPTFS). So, unless you upgrade both ends and update configuration IPTFS won't be used at all. Once you upgrade one end you can add a configuration parameter to it to propose using IPTFS while being initiator. Until the other end is upgraded too, it will ignore the USE_IPTFS notify and SA will be established in tunnel mode. Once the other end is upgraded and its configuration is changed they will start using IPTFS. > > >From my understanding it's just another encapsulation mode. Otherwise we have the following problems: > > - Since this functionality is optional its capability must be negotiated (or indicated by the peers) in IKEv2. > > And negotiation of IPTFS features is already complex enough. > > I'm not sure what needs to be negotiated here -- without negotiation the > behavior is the same as would be seen with a miss-configured endpoint > or mismatch in TFS config that will occur without the option. Not true. If peers are misconfigured, then IPTFS won't be negotiated and SA will be established in tunnel mode (if using IPTFS is optional for both) or not established at all (if using PFS is mandatory for the peer suggesting it). On the contrary, if switching from tunnel to IPTFS on live SA is not negotiated, and one of the peers doesn't support it, then when the other peer switches from tunnel mode to IPTFS on live IPsec SA and starts sending IPTFS packets, then the first peer will most probably drop them. We'll get a classical "black hole", and the worst thing that it won't be detected by liveness checks, since IKE SA will be perfectly workable. > > - It complicates processing in the kernel. E.g, it's not clear for me what "on receipt of the first IP-TFS > payload" means. > > If packets are reordered in the network and the first received IPTFS packet is not the first sent IPTFS > packet? > > What to do with the non-IPTFS packets sent before first IPTFS packet but received after it? And so on. > > This is an implementation choice, right? Why not just drop it or > process it as the implementation sees fit? Right, but it complicates processing. Currently I uniformly process all the packets within window. Now I have to remember on which E(SN) the switching occured and process previous packets as tunnel (or start dropping them) and subsequent packets as IPTFS. > > IPTFS processing in the kernel is already quite complex, let's not introduce additional complexity. > > - I see no value in this functionality apart from the debugging and I don't want debugging capability to > > be present in the RFC, so that people, who really don't need it, implement it in > > their products introducing new bugs. You may argue, that you made it optional, but SHOULD is very close > > to MUST and in addition making it optional only complicates negotiation of IPTFS. > > My view is that the main benefit is simpler configuration and removing a > requirement for timing manual configuration changes at each end of a > tunnel. Configuring IPsec is complex enough, from the operational > perspective, I'd prefer to see this as a MUST, but can live with > SHOULD. (IMO - Getting the code right once per implementation is > greatly outweighed by the returns in not having to impose more > configuration and configuration timing burdens.) Please, see above. Since using IPTFS is negotiated, I see no simplification in configuring. You still need to upgrade and configure properly both ends before you can use it. If you badly need this feature, then please make it MAY and negotiable, so that people can ignore it. SHOULD is too strong for it, leaving it non-negotiable is just unacceptable, IMHO. Regards, Valery. > Thanks, > > Lou > > > So, please, remove it. > > > >> 2. It highlights that one must send payloads that carry inner packet fragments using consecutive ESP > >> sequence numbered packets (with a caveat for all pad payload insertion). > > That's useful clarification, thanks. > > > > Regards, > > Valery. > > > >> We feel the document is quite stable at this point and would thus like to ask for moving to WG Last Call. > >> > >> Thanks, > >> Chris. > >> > >>> On Sep 30, 2020, at 12:25 PM, internet-drafts@ietf.org wrote: > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. > >>> This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > >>> > >>> Title : IP Traffic Flow Security > >>> Author : Christian Hopps > >>> Filename : draft-ietf-ipsecme-iptfs-02.txt > >>> Pages : 26 > >>> Date : 2020-09-30 > >>> > >>> Abstract: > >>> This document describes a mechanism to enhance IPsec traffic flow > >>> security by adding traffic flow confidentiality to encrypted IP > >>> encapsulated traffic. Traffic flow confidentiality is provided by > >>> obscuring the size and frequency of IP traffic using a fixed-sized, > >>> constant-send-rate IPsec tunnel. The solution allows for congestion > >>> control as well. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ > >>> > >>> There are also htmlized versions available at: > >>> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 > >>> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-02 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of submission > >>> until the htmlized version and diff are available at tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> > >>> _______________________________________________ > >>> IPsec mailing list > >>> IPsec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipsec > >>> > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > From nobody Tue Oct 13 06:22:59 2020 Return-Path: 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 F18373A0FC4; Tue, 13 Oct 2020 06:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Rwawx6tKCgpb; Tue, 13 Oct 2020 06:22:54 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 601CE3A0FC1; Tue, 13 Oct 2020 06:22:54 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 91A5061674; Tue, 13 Oct 2020 13:22:53 +0000 (UTC) From: Christian Hopps Message-Id: <980B89DC-28AA-4C1C-ACD5-9CEE5992459D@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F346255C-7085-40A7-997C-D906AD08961E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 13 Oct 2020 09:22:52 -0400 In-Reply-To: <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> Cc: Christian Hopps , Lou Berger , ipsec@ietf.org, ipsecme-chairs@ietf.org To: Valery Smyslov References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 13:22:57 -0000 --Apple-Mail=_F346255C-7085-40A7-997C-D906AD08961E Content-Type: multipart/alternative; boundary="Apple-Mail=_4BB2F0CD-0291-4F2E-A5D0-71D8E3FB6AF0" --Apple-Mail=_4BB2F0CD-0291-4F2E-A5D0-71D8E3FB6AF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 13, 2020, at 9:16 AM, Valery Smyslov = wrote: >=20 > Hi Lou, >=20 >> Valery, >>=20 >> Please see below. >>=20 >> On 10/13/2020 3:22 AM, Valery Smyslov wrote: >>> Hi Chris, >>>=20 >>>> Hi ipsecme and chairs, >>>>=20 >>>> This is a small update to the IPTFS draft which incorporates the = last 2 changes that had been requested >> over >>>> the last year or so. >>>>=20 >>>> 1. As requested last year, it dispenses with the late-enabled = functionality, replacing it with a SHOULD >> clause >>>> supporting receiving IPTFS encapsulated ESP payloads w/o extra = configuration. >>> I prefer this functionality to be removed. Either you are doing = classical tunnel/transport in the SA or you are >> doing IPTFS. >>=20 >> I agree that there is added code complexity, but have you considered = the >> operational benefit of having this? Specifically (a) adding yet = another >> required configuration parameter that must match at both ends to get = an >> ipsec tunnels up and (b) what it takes to go from an operational = non-TFS >> configuration to a TFS configuration in one or both directions? >=20 > I can't buy these arguments. Using IPTFS is negotiated in IKEv2 via > exchange of USE_IPTFS notify (BTW, note a typo in Section 5.1 title: = USE_TFS instead of USE_IPTFS). > So, unless you upgrade both ends and update configuration IPTFS won't = be used at all. > Once you upgrade one end you can add a configuration parameter to it = to > propose using IPTFS while being initiator. Until the other end is = upgraded too, > it will ignore the USE_IPTFS notify and SA will be established in = tunnel mode. > Once the other end is upgraded and its configuration is changed they > will start using IPTFS. >=20 >>>> =46rom my understanding it's just another encapsulation mode. = Otherwise we have the following problems: >>> - Since this functionality is optional its capability must be = negotiated (or indicated by the peers) in IKEv2. >>> And negotiation of IPTFS features is already complex enough. >>=20 >> I'm not sure what needs to be negotiated here -- without negotiation = the >> behavior is the same as would be seen with a miss-configured = endpoint >> or mismatch in TFS config that will occur without the option. >=20 > Not true. If peers are misconfigured, then IPTFS won't be negotiated = and SA will be established in tunnel mode > (if using IPTFS is optional for both) or not established at all (if = using PFS is mandatory for the peer suggesting it). > On the contrary, if switching from tunnel to IPTFS on live SA is not = negotiated, and one of the peers doesn't > support it, then when the other peer switches from tunnel mode to = IPTFS on live IPsec SA and starts sending > IPTFS packets, then the first peer will most probably drop them. We'll = get a classical "black hole", and the worst > thing that it won't be detected by liveness checks, since IKE SA will = be perfectly workable. >=20 >>> - It complicates processing in the kernel. E.g, it's not clear for = me what "on receipt of the first IP-TFS >> payload" means. >>> If packets are reordered in the network and the first received = IPTFS packet is not the first sent IPTFS >> packet? >>> What to do with the non-IPTFS packets sent before first IPTFS = packet but received after it? And so on. >>=20 >> This is an implementation choice, right? Why not just drop it or >> process it as the implementation sees fit? >=20 > Right, but it complicates processing. Currently I uniformly process = all the packets within window. > Now I have to remember on which E(SN) the switching occured and = process previous > packets as tunnel (or start dropping them) and subsequent packets as = IPTFS. >=20 >>> IPTFS processing in the kernel is already quite complex, let's = not introduce additional complexity. >>> - I see no value in this functionality apart from the debugging and = I don't want debugging capability to >>> be present in the RFC, so that people, who really don't need it, = implement it in >>> their products introducing new bugs. You may argue, that you made = it optional, but SHOULD is very close >>> to MUST and in addition making it optional only complicates = negotiation of IPTFS. >>=20 >> My view is that the main benefit is simpler configuration and = removing a >> requirement for timing manual configuration changes at each end of a >> tunnel. Configuring IPsec is complex enough, from the operational >> perspective, I'd prefer to see this as a MUST, but can live with >> SHOULD. (IMO - Getting the code right once per implementation is >> greatly outweighed by the returns in not having to impose more >> configuration and configuration timing burdens.) >=20 > Please, see above. Since using IPTFS is negotiated, I see no = simplification > in configuring. You still need to upgrade and configure properly both = ends > before you can use it. IPTFS is not always negotiated, as IKE is not always used. Supporting = zero-conf IPTFS receive is very useful for supporting these non-IKE = use-cases. Thanks, Chris. >=20 > If you badly need this feature, then please make it MAY and = negotiable, > so that people can ignore it. SHOULD is too strong for it, > leaving it non-negotiable is just unacceptable, IMHO. >=20 > Regards, > Valery. >=20 >> Thanks, >>=20 >> Lou >>=20 >>> So, please, remove it. >>>=20 >>>> 2. It highlights that one must send payloads that carry inner = packet fragments using consecutive ESP >>>> sequence numbered packets (with a caveat for all pad payload = insertion). >>> That's useful clarification, thanks. >>>=20 >>> Regards, >>> Valery. >>>=20 >>>> We feel the document is quite stable at this point and would thus = like to ask for moving to WG Last Call. >>>>=20 >>>> Thanks, >>>> Chris. >>>>=20 >>>>> On Sep 30, 2020, at 12:25 PM, internet-drafts@ietf.org wrote: >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>> This draft is a work item of the IP Security Maintenance and = Extensions WG of the IETF. >>>>>=20 >>>>> Title : IP Traffic Flow Security >>>>> Author : Christian Hopps >>>>> Filename : draft-ietf-ipsecme-iptfs-02.txt >>>>> Pages : 26 >>>>> Date : 2020-09-30 >>>>>=20 >>>>> Abstract: >>>>> This document describes a mechanism to enhance IPsec traffic = flow >>>>> security by adding traffic flow confidentiality to encrypted IP >>>>> encapsulated traffic. Traffic flow confidentiality is provided = by >>>>> obscuring the size and frequency of IP traffic using a = fixed-sized, >>>>> constant-send-rate IPsec tunnel. The solution allows for = congestion >>>>> control as well. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-02 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_4BB2F0CD-0291-4F2E-A5D0-71D8E3FB6AF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 13, 2020, at 9:16 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi = Lou,

Valery,

Please see below.

On 10/13/2020 3:22 AM, Valery Smyslov = wrote:
Hi Chris,

Hi = ipsecme and chairs,

This is a small update = to the IPTFS draft which incorporates the last 2 changes that had been = requested
over
the last year or so.

1. As = requested last year, it dispenses with the late-enabled functionality, = replacing it with a SHOULD
clause
supporting = receiving IPTFS encapsulated ESP payloads w/o extra configuration.
I prefer this functionality to be removed. = Either you are doing classical tunnel/transport in the SA or you are
doing IPTFS.

I = agree that there is added code complexity, but have you considered = the
operational benefit of having this?  Specifically = (a) adding yet another
required configuration parameter = that must match at both ends to get an
ipsec tunnels up = and (b) what it takes to go from an operational non-TFS
configuration to a TFS configuration in one or both = directions?

I can't buy these arguments. Using IPTFS is negotiated in = IKEv2 via 
exchange of = USE_IPTFS notify (BTW, note a typo in Section 5.1 title: USE_TFS instead = of USE_IPTFS).
So, unless you upgrade both ends and update configuration = IPTFS won't be used at all.
Once you upgrade one end you can add a configuration = parameter to it to 
propose using = IPTFS while being initiator. Until the other end is upgraded = too,
it will = ignore the USE_IPTFS notify and SA will be established in tunnel = mode.
Once the = other end is upgraded and its configuration is changed they 
will start = using IPTFS.

=46rom my understanding it's just another encapsulation mode. = Otherwise we have the following problems:
- = Since this functionality is optional its capability must be negotiated = (or indicated by the peers) in IKEv2.
   And = negotiation of IPTFS features is already complex enough.

I'm not sure what needs to be = negotiated here -- without negotiation the
behavior is the = same as would be seen with a miss-configured  endpoint
or mismatch in TFS config that will occur without the = option.

Not true. If peers are misconfigured, then IPTFS won't be = negotiated and SA will be established in tunnel mode
(if using = IPTFS is optional for both) or not established at all (if using PFS is = mandatory for the peer suggesting it).
On the contrary, if switching from tunnel to IPTFS on live SA = is not negotiated, and one of the peers doesn't
support it, = then when the other peer switches from tunnel mode to IPTFS on live = IPsec SA and starts sending
IPTFS packets, then the first peer will most probably drop = them. We'll get a classical "black hole", and the worst
thing that it = won't be detected by liveness checks, since IKE SA will be perfectly = workable.

- It complicates = processing in the kernel. E.g, it's not clear for me what "on receipt of = the first IP-TFS
payload" means.
   If = packets are reordered in the network and the first received IPTFS packet = is not the first sent IPTFS
packet?
   What = to do with the non-IPTFS packets sent before first IPTFS packet but = received after it? And so on.

This is an implementation choice, right?  Why not just = drop it or
process it as the implementation sees fit?

Right, but it complicates processing. Currently I uniformly = process all the packets within window.
Now I have to remember on which E(SN) the switching occured = and process previous
packets as tunnel (or start dropping them) and subsequent = packets as IPTFS.

   IPTFS processing in the kernel is already = quite complex, let's not introduce additional complexity.
- = I see no value in this functionality apart from the debugging and I = don't want debugging capability to
   be = present in the RFC, so that people, who really don't need it, implement = it in
   their products introducing new = bugs. You may argue, that you made it optional, but SHOULD is very = close
   to MUST and in addition making it = optional only complicates negotiation of IPTFS.

My view is that the main benefit = is simpler configuration and removing a
requirement for = timing manual configuration changes at each end of a
tunnel.=  Configuring IPsec is complex enough,  from the = operational
perspective, I'd prefer to see this as a MUST, = but can live with
SHOULD.  (IMO - Getting the code = right once per implementation is
greatly outweighed by the = returns in not having to impose more
configuration and = configuration timing burdens.)

Please, see = above. Since using IPTFS is negotiated, I see no = simplification
in configuring. You still need to upgrade and configure = properly both ends
before you can use it.

IPTFS is not always negotiated, as IKE is not = always used. Supporting zero-conf IPTFS receive is very useful for = supporting these non-IKE use-cases.

Thanks,
Chris.


If you badly = need this feature, then please make it MAY and negotiable,
so that = people can ignore it. SHOULD is too strong for it,
leaving it = non-negotiable is just unacceptable, IMHO.

Regards,
Valery.

Thanks,

Lou

So, please, remove it.

2. It highlights that one must send payloads = that carry inner packet fragments using consecutive ESP
sequence numbered packets (with a caveat for all pad payload = insertion).
That's useful clarification, = thanks.

Regards,
Valery.

We feel = the document is quite stable at this point and would thus like to ask = for moving to WG Last Call.

Thanks,
Chris.

On Sep 30, 2020, at 12:25 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work = item of the IP Security Maintenance and Extensions WG of the IETF.

       Title =           : IP Traffic = Flow Security
       Author =          : Christian = Hopps
Filename        : = draft-ietf-ipsecme-iptfs-02.txt
Pages =           : 26
= Date =            : = 2020-09-30

Abstract:
  This document describes a mechanism to enhance = IPsec traffic flow
  security by adding traffic = flow confidentiality to encrypted IP
  encapsulated traffic.  Traffic flow = confidentiality is provided by
  obscuring the = size and frequency of IP traffic using a fixed-sized,
  constant-send-rate IPsec tunnel.  The = solution allows for congestion
  control as = well.


The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/<= br class=3D"">
There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-= 02

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-02=


Please note that it may = take a couple of minutes from the time of submission
until = the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_4BB2F0CD-0291-4F2E-A5D0-71D8E3FB6AF0-- --Apple-Mail=_F346255C-7085-40A7-997C-D906AD08961E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+FqiwACgkQLh2DDte4 MCXh5BAAisAMK/u+4Yf3kppHWwvFmrMn+2gmtTW6/odGFZOtyEu6TvnutXbqZ2yU Ggd33JvkUHZGPChG+6BSdrR0K7PcaEdgA8imEYAL+bPpVzpT8uWtE8gp7GIxC8Mt tgL/VWvonXYSI7byUhXuCJdAYPjAgWTy3tYTKzhTCZqj8c563pJY+gxWlBoXeEu7 XlQN6u3QjIzxbxa4EGJs2pVjmJY4nTGbCvpoS64uC1TS0L5p4sXHf/9mp7gosCzo SAFzvliSwiCei0zaD4dJSRCWSxffQny7aUav1U1KUEVUM4C+XsjT1VbxAv8nJxRT LHrsFxVtVAXsaFBs06XJmHEn5Ye27CsEQ4HMrTmoWpjopLI5rvp22d2pXQZeiOED DMyeJo7BmSn7uQbG0+9uNxRdzUfoI8d2vseh1YdvDo+AF9HHV5LX0tVO4toy1udn Et+7xmtg7P909CzzruEY4mCFNN+sF0OQ3V+qEcmtmTcAV2kigJ+HngqPGIbFPp6V clk2STMrsrc0So9SqDsOL1eNaX1768jXs6XOasuUdYf7yuAuOzyDG359jUMWGUoz XZGvc7z9N93GNdst9+QTI1bAu4/mycpRMJDz1M6RNtNW55bEEBL4JwWo3OhWC9tf d0D6bje59juHgoQcHIdp2UCh3hI7k7bcE3lDbb4n1l6pa5dBBNA= =68G6 -----END PGP SIGNATURE----- --Apple-Mail=_F346255C-7085-40A7-997C-D906AD08961E-- From nobody Tue Oct 13 06:43:16 2020 Return-Path: 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 0A8B63A0FF0; Tue, 13 Oct 2020 06:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 re9NZy0FLx02; Tue, 13 Oct 2020 06:43:13 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5FD3A0FD2; Tue, 13 Oct 2020 06:43:12 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id 33so20913466edq.13; Tue, 13 Oct 2020 06:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=0Et6TAysE7CbwnoCvbvzwj2GLk5/32b/FjgD/O4sJf4=; b=rPPsyslOvt01VbbCVwAAOANAgkJMMCf55weWr82fZ/9+T+CRHlUPd7Oc3aiv9dgpTX 5pjY6xR8TQcXWGR6cTfFf0ZXpf1jRNDQRyfrIwOLmKS8gpN29F+lMMNTAHE4lF3HgQqv IYHb7K13iE9+HD52BUiQb1oNN/kCN+Euvjwq6nhDRdiTaRlPu9KJMhBlwQQX2S3Q+1Hv DZddcD+CggeBuX/LyzxkQRuUUtnI82CjBK2D4KU5v3O4rswbWfpPlAkEC4thIEgUdPBM 5KJlsx3qDYQEUvcYZUko34Kmo6KhDKZ2mMO4ljl4nB16riWTykHzgi0DhlysBPktm7O2 Cbdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=0Et6TAysE7CbwnoCvbvzwj2GLk5/32b/FjgD/O4sJf4=; b=RkstwGAkrXZHsMlyss8hkWj2oZv1rZTEJEpuHXhV9YiNRdfH9Sq2ip2MSsg0wTaLz8 SwQQfWRGU7VoX9MPZs/lBVw3wncHkbB21zUZC3qgzMZWe1Vn5wE8i+7tadNja8iopLF7 cPsq3vW8gTaD2+//H/e2tWRNnsOUIbuRVZuVuTX0nOzAuJWLs3HD6qkRXKcKIkq34wmt sE4vUtDcAENtAX1GSFVXye12konei+zaSYxdXNJLUzRfhiUQenGTx6Pz6r6TKdrHCy9f tFHssZ4cSJbTZEEhz33qh8yCem12PeRHUO35RhS2Ce71K1Iub/bGQaOCRO+Nx02nI6kj GGtA== X-Gm-Message-State: AOAM530IFSBradOMVL8TH9g9JjxeZmP69mWoDP7DGuv4ag1Efq3gwtbU K+vJ8711MWKRM6uMcNEIylxfuTX/5Jk= X-Google-Smtp-Source: ABdhPJxVdObpFNlqlC4PtSf38cO12D4PviIjg+05YS06+vyyT09SqVnYX1pq0QFwMiksQxTmD7n8EA== X-Received: by 2002:aa7:db82:: with SMTP id u2mr20687089edt.262.1602596591300; Tue, 13 Oct 2020 06:43:11 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id c5sm12689282edx.58.2020.10.13.06.43.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 06:43:10 -0700 (PDT) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'Lou Berger'" , , References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <980B89DC-28AA-4C1C-ACD5-9CEE5992459D@chopps.org> In-Reply-To: <980B89DC-28AA-4C1C-ACD5-9CEE5992459D@chopps.org> Date: Tue, 13 Oct 2020 16:43:10 +0300 Message-ID: <1b1a01d6a166$cb02e8f0$6108bad0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1B1B_01D6A17F.F051A790" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBR9Dg1QdoZI0c6Vo/AaLkIdpDHgLCxSxRAjbXs18B6rBqnQEamLQSAVwRoYqndWUHcA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 13:43:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1B1B_01D6A17F.F051A790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Chris, IPTFS is not always negotiated, as IKE is not always used. Supporting zero-conf IPTFS receive is very useful for supporting these non-IKE use-cases. If you plan to use IPTFS without IKE, then make it clear in the draft that Zero-Conf is only applicable for these use cases and MUST NOT be used if IKE is employed. That will make me happy :-) Regards, Valery. Thanks, Chris. If you badly need this feature, then please make it MAY and negotiable, so that people can ignore it. SHOULD is too strong for it, leaving it non-negotiable is just unacceptable, IMHO. Regards, Valery. Thanks, Lou So, please, remove it. 2. It highlights that one must send payloads that carry inner packet fragments using consecutive ESP sequence numbered packets (with a caveat for all pad payload insertion). That's useful clarification, thanks. Regards, Valery. We feel the document is quite stable at this point and would thus like to ask for moving to WG Last Call. Thanks, Chris. On Sep 30, 2020, at 12:25 PM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP Traffic Flow Security Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-02.txt Pages : 26 Date : 2020-09-30 Abstract: This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_1B1B_01D6A17F.F051A790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris,

 

IPTFS is not = always negotiated, as IKE is not always used. Supporting = zero-conf IPTFS receive is very useful for supporting these non-IKE = use-cases.

 

          If you plan to = use IPTFS without IKE, then make it clear in the draft that =

          Zero-Conf is = only applicable for these use cases and MUST NOT be = used

          if IKE is = employed. That will make me happy :-)

 

          = Regards,

          = Valery.

        &= nbsp;

 

 

Thanks,

Chris.




If = you badly need this feature, then please make it MAY and = negotiable,
so that people can ignore it. SHOULD is too strong for = it,
leaving it non-negotiable is just unacceptable, = IMHO.

Regards,
Valery.


Thanks,
Lou


So, = please, remove it.


2. It = highlights that one must send payloads that carry inner packet fragments = using consecutive ESP
sequence numbered packets (with a caveat for = all pad payload insertion).

That's = useful clarification, = thanks.

Regards,
Valery.


We feel = the document is quite stable at this point and would thus like to ask = for moving to WG Last = Call.

Thanks,
Chris.


On Sep = 30, 2020, at 12:25 PM, internet-drafts@ietf.org = wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the IP = Security Maintenance and Extensions WG of the = IETF.

       Title =           : IP Traffic = Flow Security
       Author =          : Christian = Hopps
        &n= bsp; Filename        : = draft-ietf-ipsecme-iptfs-02.txt
        &n= bsp; Pages =           : = 26
        &n= bsp; Date =            : = 2020-09-30

Abstract:
  This document describes a = mechanism to enhance IPsec traffic flow
  security by = adding traffic flow confidentiality to encrypted = IP
  encapsulated traffic.  Traffic flow = confidentiality is provided by
  obscuring the size and = frequency of IP traffic using a = fixed-sized,
  constant-send-rate IPsec tunnel.  The = solution allows for congestion
  control as = well.


The IETF datatracker status page for this draft = is:
https= ://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/

There = are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02
https:/= /datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02

A diff = from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-02

Please note that it may take a couple of minutes from the time = of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also available by anonymous = FTP = at:
ftp://ftp.ietf.org/internet-drafts/


___________________= ____________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


______= _________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

 

------=_NextPart_000_1B1B_01D6A17F.F051A790-- From nobody Tue Oct 13 06:59:49 2020 Return-Path: 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 2E5773A0D3F for ; Tue, 13 Oct 2020 06:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 8vk3UOmPy8Kj for ; Tue, 13 Oct 2020 06:59:46 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 7D72D3A0C17 for ; Tue, 13 Oct 2020 06:59:46 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id AE6F11404F0 for ; Tue, 13 Oct 2020 07:59:45 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id SKq9kZekWdCH5SKq9klA0V; Tue, 13 Oct 2020 07:59:45 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=SuC+FsG0 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=afefHYAZSVUA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=KC-SLc3tw_2tqZiqEgIA:9 a=QEXdDO2ut3YA:10:nop_charset_2 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=TwDpoxNm6sd8Q3KiylwdgOA2QWDtyM9dOadwptYOz/s=; b=WJ67chwhcZNwfQQHC4ASTPDH2N PbWKORJ6Publ2i2LCggFNiZS/C9mlnlzZpW+EsgZDdkGj8de9nqrKgJcB7Ju+8SR3P/VjWmG+hKmz HshKPzDPDQXHlgc4zpSS8N6CF; Received: from [127.0.0.1] (port=28369 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kSKq9-002dIG-Fz; Tue, 13 Oct 2020 07:59:45 -0600 To: Valery Smyslov , 'Christian Hopps' , ipsec@ietf.org Cc: ipsecme-chairs@ietf.org References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> From: Lou Berger Message-ID: <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> Date: Tue, 13 Oct 2020 09:59:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1kSKq9-002dIG-Fz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:28369 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 13:59:48 -0000 I can live with MAY. On 10/13/2020 9:16 AM, Valery Smyslov wrote: > If you badly need this feature, then please make it MAY and negotiable, > so that people can ignore it. SHOULD is too strong for it, > leaving it non-negotiable is just unacceptable, IMHO. From nobody Tue Oct 13 07:07:07 2020 Return-Path: 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 BD6113A111F; Tue, 13 Oct 2020 07:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9ALPrnvbM8kM; Tue, 13 Oct 2020 07:06:57 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6673A10D9; Tue, 13 Oct 2020 07:06:40 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id h6so22274562lfj.3; Tue, 13 Oct 2020 07:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=WEIFmF9SiIkl8BkOPf2TjCZg1Mj7nCJrzy4MCKIXD18=; b=Qh3qzAh7QntLCTVLIp0MCq0PBJUf918Tu+9YxqCtHmG/U/sfTxPrULAWmurEBqx3ZI dx+pMuYTA4aRYqpravMBv87WDUVkoRuy7QiDG0aqUdHl/c+YRFnV27H5LI+CmYjLe0Yt 9YU1K4BqHWtkt+PjHB+52lrEYJa65ns+0C7pTctw2CO4VI+wVq7jzSvyJQ3HhIIe75jz QA4say/tpbCXmj24MqRih+oMLS0WB98/JgQoip6hioL6pUrC04tyJlKyjgt9GfH8Q8ad TVEffYIE467bUgGb+VChZ/UpKBmSpD32198pKtVERhjdWRljBH2oMPYk7XLzAQ39goJF EQqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=WEIFmF9SiIkl8BkOPf2TjCZg1Mj7nCJrzy4MCKIXD18=; b=aaHhN//dQrUEAE+nzloJ5+fHLqZMDE9Mov4HmGZKcqMUDgTKZ6LbSzeeaKTuUjhnY4 bIrXQyDGjFOoigIUiqpXol2EgwZurfpUiz1ray3APhqhA2R92ckN/7LFKnrVEkzS+lre KAT5/dqhK3R0x87Lc4PmJwAbFXQRRAxBVlZueR4fQjVcXfh817QA1IoJkqNtcUJtLWyk Xm8Pn0shzcZRYOQR+IWHvd1VraYOIGwFv3T8EzbIGZeQrbLvWJ4T7i2dBYx5pTrFYOEt 4PqQS9Hvd70fIuFoi5o0PCQ47GmqSNG477jZ80teygNZ3T9Thx/FE5v29UkAmioNL7uC GU2w== X-Gm-Message-State: AOAM532yiVzXmzVpjMsXw51zmPKYSKhpTh3OT30iBc/jKomyI3RYXuHt 6C448dcOn3YQytxsGdbgUHE= X-Google-Smtp-Source: ABdhPJxCRMofSzr6Klw8/La3xHey4H8sleZz52RKGeOwPnhmhpqCTbQh8QujVSm4nGz0Wiq5t7J9XA== X-Received: by 2002:a19:4a8a:: with SMTP id x132mr9147313lfa.423.1602597999019; Tue, 13 Oct 2020 07:06:39 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id z10sm3247215lfi.76.2020.10.13.07.06.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 07:06:38 -0700 (PDT) From: "Valery Smyslov" To: "'Lou Berger'" , "'Christian Hopps'" , Cc: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> In-Reply-To: <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> Date: Tue, 13 Oct 2020 17:06:39 +0300 Message-ID: <1b2401d6a16a$12110940$36331bc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBR9Dg1QdoZI0c6Vo/AaLkIdpDHgLCxSxRAjbXs18B6rBqnQEamLQSAoWVN8OnbCBVoA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 14:07:06 -0000 > I can live with MAY. OK, but it must be negotiable in any case if you plan to use it with IKE. Otherwise we'll get black holes. > On 10/13/2020 9:16 AM, Valery Smyslov wrote: > > If you badly need this feature, then please make it MAY and negotiable, > > so that people can ignore it. SHOULD is too strong for it, > > leaving it non-negotiable is just unacceptable, IMHO. From nobody Tue Oct 13 07:25:50 2020 Return-Path: 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 C1AF23A0317 for ; Tue, 13 Oct 2020 07:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 POeJ9bHlDdeC for ; Tue, 13 Oct 2020 07:25:48 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 41CA53A02DC for ; Tue, 13 Oct 2020 07:25:48 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id DFC49140493 for ; Tue, 13 Oct 2020 08:25:47 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id SLFLkZpPXdCH5SLFLklKVD; Tue, 13 Oct 2020 08:25:47 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=SuC+FsG0 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=afefHYAZSVUA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=QANUyKFxJw7utpJxKfYA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=pGLkceISAAAA:8 a=r6bQVh5MnHq0Bv71AcgA:9 a=M8pKo24N9L-qOkcp:21 a=_W_S_7VecoQA:10:nop_html a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=yfa1k7d2aqQei/LfHDXwtjb8KqeiccKAwyvwJEnSmIA=; b=H6eAfof/wzuHDNJzctj83oB4If GKGeXUy5lhEGHMIkzmL07nyPqDQr2uv+SomKkWq58Mcayquxu1ajX1/fPycWdFKvhGfejYCUhA6T8 CVPZxZEv1bSVc0rxT13HN6Xsl; Received: from [127.0.0.1] (port=33861 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kSLFL-002jAf-Fd; Tue, 13 Oct 2020 08:25:47 -0600 To: Valery Smyslov , 'Christian Hopps' , ipsec@ietf.org Cc: ipsecme-chairs@ietf.org References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> From: Lou Berger Message-ID: <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> Date: Tue, 13 Oct 2020 10:25:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1b2401d6a16a$12110940$36331bc0$@gmail.com> Content-Type: multipart/alternative; boundary="------------0A760EFB4322D4DD97DB9EFB" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1kSLFL-002jAf-Fd X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:33861 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 14:25:50 -0000 This is a multi-part message in MIME format. --------------0A760EFB4322D4DD97DB9EFB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Valery, How about this: OLD    Receive-side operation of IP-TFS does not require any per-SA    configuration on the receiver; as such, an IP-TFS implementation    SHOULD support the option of switching to IP-TFS receive-side    operation on receipt of the first IP-TFS payload. NEW    Receive-side operation of IP-TFS does not require any per-SA    configuration on the receiver; as such, for tunnels created    without IKE, an IP-TFS implementation    SHOULD support the option of switching to IP-TFS receive-side    operation on receipt of the first IP-TFS payload for tunnels. I can live with MAY, but would prefer SHOULD. Does this work for you? Lou On 10/13/2020 10:06 AM, Valery Smyslov wrote: >> I can live with MAY. > OK, but it must be negotiable in any case if you plan to use it with IKE. > Otherwise we'll get black holes. > >> On 10/13/2020 9:16 AM, Valery Smyslov wrote: >>> If you badly need this feature, then please make it MAY and negotiable, >>> so that people can ignore it. SHOULD is too strong for it, >>> leaving it non-negotiable is just unacceptable, IMHO. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --------------0A760EFB4322D4DD97DB9EFB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Valery,

How about this:

OLD
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload.

NEW
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, for tunnels created
   without IKE, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload for tunnels.

I can live with MAY, but would prefer SHOULD.
Does this work for you?
Lou
On 10/13/2020 10:06 AM, Valery Smyslov wrote:
I can live with MAY.

OK, but it must be negotiable in any case if you plan to use it with IKE.
Otherwise we'll get black holes.


On 10/13/2020 9:16 AM, Valery Smyslov wrote:

If you badly need this feature, then please make it MAY and negotiable,
so that people can ignore it. SHOULD is too strong for it,
leaving it non-negotiable is just unacceptable, IMHO.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--------------0A760EFB4322D4DD97DB9EFB-- From nobody Tue Oct 13 07:37:58 2020 Return-Path: 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 E67B43A07CE; Tue, 13 Oct 2020 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E6p2ZmjyDv-u; Tue, 13 Oct 2020 07:37:53 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401D83A07F5; Tue, 13 Oct 2020 07:37:53 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id c22so178146ejx.0; Tue, 13 Oct 2020 07:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=i18TOPp9x66j2XgokZLzLbeWeFuC38gQFfmeBe+atMU=; b=LjEGEsGwTnssKBuclBGabjCEICJnaRch6F0we7ub9YVUJtSTS8uEjE6q1SR/Qy3kGx 26M1+rl8iKC4eLAym+wGPTI1+XdjC3/BdYzVmdp9/eShWH2GPKEViX6lHxK3hbj9fps3 fKqAeZKwJa6Zza4zPQGgd2iOpl20otrlw1Lt0m64wMA0RnkDsKVsEi+u9JHeQyCGLWEq Id8cRO8N1fDKt7HWAnLkZotVzQus2kh4tQn7ywlwkhsCMg6C9vQ9YE7yiUy3lHWrYxYs QrCuWtQKZ5OAZ6xwuD5EgFuAidxk6iexevajHCgUQW1uk4ThbTf8jHkqe0wrWp7MZkC0 X5vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=i18TOPp9x66j2XgokZLzLbeWeFuC38gQFfmeBe+atMU=; b=UFEfJn3L7bwQLltkkSr89G3BE0LdBBKuoHIjYbnxTHNvi6bvs1S2hzllNGxwlsi3+A +P1CP7G+XFqfYZXg1PJt7ESV6EmNFvN9D4SXMSAsws0PM8y/YNR8gLRm74cicSgauLCK fkYeyuTKFW6Vu9VoIpFZjhoORc206z5yYrYeAJ4ZA66j7NPo+Jjq2NDdJJY3PBg7PiWE BLhBvJYyK2itQUEQx99aaGfyVo4WdWDLcNyLkgmxyEX9BPSPdSokfMUOFwE3lXJRCu7p fADaMXFpj5Gx04WLM89a76w9HwXHTzy7NNa+4ZQ2+IQ5iPrEkmfVCe4Fr6X1ndr91ueX YTfA== X-Gm-Message-State: AOAM532XcE/xrDtPMo0qm9aD1WZVUcudaWMTTyWbEdOFk2Bb1IdOQU/4 wd2lIIeHJJEA38c4bpYVv7w= X-Google-Smtp-Source: ABdhPJyANAdzCIiZ2gUWq1dMRJLyg5m9ExEk2ajsg3k5E0tK7gk5FiqAxstKPSvk1JtaBVrpZf222Q== X-Received: by 2002:a17:906:1955:: with SMTP id b21mr84948eje.42.1602599871793; Tue, 13 Oct 2020 07:37:51 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id le12sm90974ejb.1.2020.10.13.07.37.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 07:37:51 -0700 (PDT) From: "Valery Smyslov" To: "'Lou Berger'" , "'Christian Hopps'" , Cc: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> In-Reply-To: <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> Date: Tue, 13 Oct 2020 17:37:50 +0300 Message-ID: <1b3001d6a16e$6e614030$4b23c090$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1B31_01D6A187.93AFFED0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBR9Dg1QdoZI0c6Vo/AaLkIdpDHgLCxSxRAjbXs18B6rBqnQEamLQSAoWVN8MCQOm3xwKebyejp0UsfoA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 14:37:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1B31_01D6A187.93AFFED0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Valery, How about this: OLD Receive-side operation of IP-TFS does not require any per-SA configuration on the receiver; as such, an IP-TFS implementation SHOULD support the option of switching to IP-TFS receive-side operation on receipt of the first IP-TFS payload. NEW Receive-side operation of IP-TFS does not require any per-SA configuration on the receiver; as such, for tunnels created=20 without IKE, an IP-TFS implementation SHOULD support the option of switching to IP-TFS receive-side operation on receipt of the first IP-TFS payload for tunnels. I can live with MAY, but would prefer SHOULD. =20 =20 Does this work for you? =20 Yes, with the following addition. =20 Receive-side operation of IP-TFS does not require any per-SA configuration on the receiver; as such, for tunnels created=20 without IKE, an IP-TFS implementation SHOULD support the option of switching to IP-TFS receive-side operation on receipt of the first IP-TFS payload for tunnels. If IKE is used to negotiate using IP-TFS, then such switching MUST NOT take place. With this addition I don=E2=80=99t mind having SHOULD for = ike-less case. =20 Regards, Valery. =20 Lou =20 On 10/13/2020 10:06 AM, Valery Smyslov wrote: I can live with MAY. =20 OK, but it must be negotiable in any case if you plan to use it with = IKE. Otherwise we'll get black holes. =20 On 10/13/2020 9:16 AM, Valery Smyslov wrote: If you badly need this feature, then please make it MAY and negotiable, so that people can ignore it. SHOULD is too strong for it, leaving it non-negotiable is just unacceptable, IMHO. =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_1B31_01D6A187.93AFFED0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Valery,

How = about this:

OLD
   = Receive-side operation of IP-TFS does not require any = per-SA
   configuration on the receiver; as such, an IP-TFS = implementation
   SHOULD support the option of switching to = IP-TFS receive-side
   operation on receipt of the first = IP-TFS payload.

NEW
   Receive-side operation of = IP-TFS does not require any per-SA
   configuration on the = receiver; as such, for tunnels created
   without IKE, an = IP-TFS implementation
   SHOULD support the option of = switching to IP-TFS receive-side
   operation on receipt of = the first IP-TFS payload for tunnels.

I can live with MAY, but = would prefer SHOULD.

 

 
Does this work for you?
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Yes, with the following addition.
 
   =
Receive-side operation of IP-TFS does not require any =
per-SA
   configuration on the receiver; as such, for =
tunnels created 
   without IKE, an IP-TFS =
implementation
   SHOULD support the option of switching to =
IP-TFS receive-side
   operation on receipt of the first =
IP-TFS payload for tunnels.
=C2=A0=C2=A0 If IKE is used to negotiate using IP-TFS, then =
such =
switching
=C2=A0=C2=A0 =
MUST NOT take place.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 With this addition I don=E2=80=99t mind having SHOULD for =
ike-less case.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Valery.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 
Lou
 

On 10/13/2020 10:06 AM, Valery = Smyslov wrote:

I =
can live with MAY.
 
OK, =
but it must be negotiable in any case if you plan to use it with =
IKE.
Otherwise we'll get black =
holes.
 
On 10/13/2020 9:16 =
AM, Valery Smyslov wrote:
If you badly need =
this feature, then please make it MAY and =
negotiable,
so that people can ignore it. SHOULD is =
too strong for it,
leaving it non-negotiable is =
just unacceptable, =
IMHO.
 
_______________________________________________
<=
pre>IPsec mailing list
IPsec@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
<= /blockquote>
------=_NextPart_000_1B31_01D6A187.93AFFED0-- From nobody Tue Oct 13 09:05:45 2020 Return-Path: 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 5712D3A0822 for ; Tue, 13 Oct 2020 09:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 PchFdOD_ArvB for ; Tue, 13 Oct 2020 09:05:41 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 BA5B13A082F for ; Tue, 13 Oct 2020 09:05:41 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 5BC601E175D for ; Tue, 13 Oct 2020 10:05:39 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id SMnzknn88hDCCSMnzkAIQH; Tue, 13 Oct 2020 10:05:39 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=IeOpp1ia c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=afefHYAZSVUA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=iZmimLUrk-GYysTm8QYA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=pGLkceISAAAA:8 a=IeogeWDSlLTIWme1uskA:9 a=O7-sMXtjC0H3q5GO:21 a=UiCQ7L4-1S4A:10:nop_mshtml_css_classes a=hTZeC7Yk6K0A:10:nop_msword_html a=frz4AuCg-hUA:10:nop_css_in_html a=_W_S_7VecoQA:10:nop_html a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=6O1eUjUQz/zySvUE/LDr4gnoV5pO/80Z9X/smd7tKfY=; b=ui0XhIjyLro1B9NYIh6SXHb/Dx gbLqceFd0jOr0TWnXrdVv5ovA+HCxBjjIurvTmUcqhiciEa+ggK5QT8OTCSJkjZCv8VevNHMrbOVJ W0Vkb6OVxwfct+888reB6regc; Received: from [127.0.0.1] (port=58571 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kSMny-0035iK-W1; Tue, 13 Oct 2020 10:05:39 -0600 To: Valery Smyslov , 'Christian Hopps' , ipsec@ietf.org Cc: ipsecme-chairs@ietf.org References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <1b3001d6a16e$6e614030$4b23c090$@gmail.com> From: Lou Berger Message-ID: <2af84d55-539a-cc37-5952-731d4d86473b@labn.net> Date: Tue, 13 Oct 2020 12:05:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1b3001d6a16e$6e614030$4b23c090$@gmail.com> Content-Type: multipart/alternative; boundary="------------3B632A76E41F81A64CC9B38F" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1kSMny-0035iK-W1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:58571 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 16:05:43 -0000 This is a multi-part message in MIME format. --------------3B632A76E41F81A64CC9B38F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Valery, >    If IKE is used to negotiate using IP-TFS, then such switching MUST NOT take place. I read this added line as saying you can switch from tunnel to TFS, I think you mean that use of TFS is controlled via IKE.  How about?    If IKE is used to negotiate using IP-TFS, then use of TFS is controlled per Section 5.1. Lou On 10/13/2020 10:37 AM, Valery Smyslov wrote: > > Valery, > > How about this: > > OLD >    Receive-side operation of IP-TFS does not require any per-SA >    configuration on the receiver; as such, an IP-TFS implementation >    SHOULD support the option of switching to IP-TFS receive-side >    operation on receipt of the first IP-TFS payload. > > NEW >    Receive-side operation of IP-TFS does not require any per-SA >    configuration on the receiver; as such, for tunnels created >    without IKE, an IP-TFS implementation >    SHOULD support the option of switching to IP-TFS receive-side >    operation on receipt of the first IP-TFS payload for tunnels. > > I can live with MAY, but would prefer SHOULD. > > Does this work for you? > Yes, with the following addition. >    Receive-side operation of IP-TFS does not require any per-SA    > configuration on the receiver; as such, for tunnels created    without > IKE, an IP-TFS implementation    SHOULD support the option of > switching to IP-TFS receive-side    operation on receipt of the first > IP-TFS payload for tunnels. >    If IKE is used to negotiate using IP-TFS, then such switching >    MUST NOT take place. >               With this addition I don’t mind having SHOULD for > ike-less case. >               Regards, >               Valery. > Lou > > On 10/13/2020 10:06 AM, Valery Smyslov wrote: > > I can live with MAY. > > OK, but it must be negotiable in any case if you plan to use it with IKE. > > Otherwise we'll get black holes. > > On 10/13/2020 9:16 AM, Valery Smyslov wrote: > > If you badly need this feature, then please make it MAY and negotiable, > > so that people can ignore it. SHOULD is too strong for it, > > leaving it non-negotiable is just unacceptable, IMHO. > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --------------3B632A76E41F81A64CC9B38F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Valery,

>    If IKE is used to negotiate using IP-TFS, then such switching MUST NOT take place.

I read this added line as saying you can switch from tunnel to TFS, I think you mean that use of TFS is controlled via IKE.  How about?

   If IKE is used to negotiate using IP-TFS, then use of
   TFS is controlled per Section 5.1.

Lou

On 10/13/2020 10:37 AM, Valery Smyslov wrote:

Valery,

How about this:

OLD
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload.

NEW
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, for tunnels created
   without IKE, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload for tunnels.

I can live with MAY, but would prefer SHOULD.

 

 
Does this work for you?
 
              Yes, with the following addition.
 
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, for tunnels created 
   without IKE, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload for tunnels.
   If IKE is used to negotiate using IP-TFS, then such switching
   MUST NOT take place.


              With this addition I don’t mind having SHOULD for ike-less case.
 
              Regards,
              Valery.
 

 


             
Lou
 

On 10/13/2020 10:06 AM, Valery Smyslov wrote:

I can live with MAY.
 
OK, but it must be negotiable in any case if you plan to use it with IKE.
Otherwise we'll get black holes.
 
On 10/13/2020 9:16 AM, Valery Smyslov wrote:
If you badly need this feature, then please make it MAY and negotiable,
so that people can ignore it. SHOULD is too strong for it,
leaving it non-negotiable is just unacceptable, IMHO.
 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--------------3B632A76E41F81A64CC9B38F-- From nobody Tue Oct 13 10:33:48 2020 Return-Path: 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 019C43A0B5A for ; Tue, 13 Oct 2020 10:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 JC2-VkFZQbl4 for ; Tue, 13 Oct 2020 10:33:45 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 EB70D3A0B56 for ; Tue, 13 Oct 2020 10:33:44 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 285581B00145; Tue, 13 Oct 2020 20:33:39 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602610419; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BH9jf1nnfeM9feG7a1HusnnVW/wEnMhDkEY9Q8oIjtg=; b=u5kmY4tdkIpQ/wPYncD2rMbmmOHGbqFAMtzSKXeL1XN4agfNcNeHfsCFAAxzAopT/sXv4x 11odVU+8g1dwb91xTS3ujl4FtCagLY9yq3Xo6Yi43gGneveCyuIkMhMCKF7vkHg3gufGBD +RPxAZ2IuQeUJZsDCyCnbjVQx6BVfSOYpFn2ETkmOEPhwEpZmNIRBwb6SyNDaiN9Z+wgh/ wAEesoncDA68MjXsA6TBpvKfsO70yE172QAHJkRzcI+zUYw6YyXxd1UAozjPCe4ME5Y8e+ QUf1oln7nI4CitcbS93WBH4+OBqi5OrDb6JX4F3lWoyAs844vF1b48NTtydSCg== Received: by fireball.acr.fi (Postfix, from userid 15204) id 28C6325C1204; Tue, 13 Oct 2020 20:32:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24453.58544.114398.668064@fireball.acr.fi> Date: Tue, 13 Oct 2020 20:32:32 +0300 From: Tero Kivinen To: Lou Berger Cc: Valery Smyslov , 'Christian Hopps' , ipsec@ietf.org In-Reply-To: <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602610419; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BH9jf1nnfeM9feG7a1HusnnVW/wEnMhDkEY9Q8oIjtg=; b=TrtaCoGqNuSrJJLkWpNcPuao4U/H2C21LKHEO9fBzwVlrOK6Rr4o6BJFOc0y90+0sIf1lG p7oqGT9M7HCwJh6Q0I9NPnSe+IH/zGDnm5u9WMeA7UCelZCU7HRaeqKZTc3wkbaIrLsvwj imVM5su3kv//ZP+ylPOxILSQVR86Fqd7eTm0INqL4uhf5c8Du9MmhIwyhx7zhsAMvj4fpb l9srhk8DNptsu7PaHRcjTUIL58oiC+ofLyYS2R7U6eCaGPaEGwIrNckCOqbpn8/Ikw3GIF iIIHy16AZntvyuXzAMpbwRGpf/w82WpK4bGQ4l7OhieQfHH1UdD+1oDoyEQBvQ== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1602610419; a=rsa-sha256; cv=none; b=TbVCR60zRt78yM/EosampuogUhZy5KAmtDoJL8oX5gmy/RjPKYnROxO5z3BhbBWguXYQrC wll8cbjuMaAfU0WPXl4q9gXQ0wbW/PF49dnNHZktuBfPqG3KB1Bv1rA/P0LcgYzGzmcsOR u6L1LzrZqScH2Lz/0vme4N7gQUUNs2Rq6pzF6WPutrbi8LIkZ9DbhyLVW4QFrc2R4whwP/ VMZrR4AjS7Azs6eFzC3NpXAb3SMw58WbzCVPs/4W58eiSJVTOpXmrI9kBwRKGF4/2dmXiL x/HVPHQMGg7VYvzCmZ7dhkoMZkfLH9M7+++KPyDz1JP9vd+QJrJPqSUJlhvhcg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 17:33:47 -0000 Lou Berger writes: > Valery, >=20 > How about this: >=20 > OLD > =A0=A0 Receive-side operation of IP-TFS does not require any per-SA > =A0=A0 configuration on the receiver; as such, an IP-TFS implementati= on > =A0=A0 SHOULD support the option of switching to IP-TFS receive-side > =A0=A0 operation on receipt of the first IP-TFS payload. >=20 > NEW > =A0=A0 Receive-side operation of IP-TFS does not require any per-SA > =A0=A0 configuration on the receiver; as such, for tunnels created > =A0=A0 without IKE, an IP-TFS implementation > =A0=A0 SHOULD support the option of switching to IP-TFS receive-side > =A0=A0 operation on receipt of the first IP-TFS payload for tunnels. >=20 > I can live with MAY, but would prefer SHOULD. >=20 > Does this work for you=3F I have to admit that I have not read this draft, but noting, that most of the cipher we use do require automated key management like IKE, I just wonder are you really going to be limited to 3DES, or what automated key management you are going to be using instead of IKE, and how can you guarantee that it actually does its job correctly for securing the key management over reboots etc. --=20 kivinen@iki.fi From nobody Tue Oct 13 13:40:10 2020 Return-Path: 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 99D9D3A1120 for ; Tue, 13 Oct 2020 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 U-K63PKAit5q for ; Tue, 13 Oct 2020 13:40:08 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 244FA3A08DA for ; Tue, 13 Oct 2020 13:40:08 -0700 (PDT) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 93EEC40024 for ; Tue, 13 Oct 2020 14:40:04 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id SR5YkSde0eMJHSR5YkgXT4; Tue, 13 Oct 2020 14:40:04 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=VuIN/d+n c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=afefHYAZSVUA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=8ymL5eeLoNpTXseJgiwA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=-RoEEKskQ1sA:10:nop_election2020_name_body a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nprPdx1KGA8vHg2N3r6yHF42B1ZfyFDXus/8ayQcb1Y=; b=fQZd6oB/zLwDORw/XoGV6+8Tqv DV6HZZsSg+mxydGmyccbrpv1a1zLut+a8xbzWPjexZg08QAj9O/e8aE5wjc+nSigz5/LKy4UYoKRN QmyfQzoZb2VuZGg11T2WOd/ss; Received: from [127.0.0.1] (port=25923 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kSR5Y-00484v-6z; Tue, 13 Oct 2020 14:40:04 -0600 To: Tero Kivinen Cc: ipsec@ietf.org, Valery Smyslov , 'Christian Hopps' References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> From: Lou Berger Message-ID: <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> Date: Tue, 13 Oct 2020 16:40:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <24453.58544.114398.668064@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1kSR5Y-00484v-6z X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:25923 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 20:40:10 -0000 Hi Tero, see below On 10/13/2020 1:32 PM, Tero Kivinen wrote: > Lou Berger writes: >> Valery, >> >> How about this: >> >> OLD >>    Receive-side operation of IP-TFS does not require any per-SA >>    configuration on the receiver; as such, an IP-TFS implementation >>    SHOULD support the option of switching to IP-TFS receive-side >>    operation on receipt of the first IP-TFS payload. >> >> NEW >>    Receive-side operation of IP-TFS does not require any per-SA >>    configuration on the receiver; as such, for tunnels created >>    without IKE, an IP-TFS implementation >>    SHOULD support the option of switching to IP-TFS receive-side >>    operation on receipt of the first IP-TFS payload for tunnels. >> >> I can live with MAY, but would prefer SHOULD. >> >> Does this work for you? > I have to admit that I have not read this draft, but noting, that most > of the cipher we use do require automated key management like IKE, I > just wonder are you really going to be limited to 3DES, or what > automated key management you are going to be using instead of IKE, and > how can you guarantee that it actually does its job correctly for > securing the key management over reboots etc. I'm not advocating ike vs ike-less, just trying to have a comprehensive solution.  One example ikeless usecase is captured by the YANG model in last call: https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 Lou From nobody Tue Oct 13 14:01:01 2020 Return-Path: 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 098B23A08C1 for ; Tue, 13 Oct 2020 14:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 IHREVSAFMi_7 for ; Tue, 13 Oct 2020 14:00:57 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 E92AA3A08E3 for ; Tue, 13 Oct 2020 14:00:54 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 32D531B00258; Wed, 14 Oct 2020 00:00:51 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602622851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5qTHhlqEqOCzS9A+gxY7jFp2eWilq1SM6GMeHUe5/UY=; b=qjC0eQ19IzOn/MeammJ8jsM5oYz/JBm+TKGsGJD8nFZd+s7WoC2z5yWt7JvbAnDGjYrJBD +F8Ic2qCdelZeO/Riop7W3NQHeLkKRhhkjycabOq00J1Iu94Pt8Uvum7B6NFAZPHXE5bDi ILUHO1Xk8EKo8mHFdVK6EcwN4a3NTQSdGYlFXSiDaBBAu8xPktwjXeco+Qp0fxX7E4t8zx yPcKYyBBOIZo5MoGJ90XDvVp5r3nG9tSbhgkM21bNE8j6bHneRVf5oxGfG0teM57wQJtoa unoE0wlQ79yYjrhack5vfVkCvisLOnigosfhRAdo+NIO0TGxOQiMfMUhSLofeQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id E57A725C123C; Wed, 14 Oct 2020 00:00:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24454.5506.450515.501200@fireball.acr.fi> Date: Wed, 14 Oct 2020 00:00:50 +0300 From: Tero Kivinen To: Lou Berger Cc: ipsec@ietf.org, Valery Smyslov , "'Christian Hopps'" In-Reply-To: <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 17 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602622851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5qTHhlqEqOCzS9A+gxY7jFp2eWilq1SM6GMeHUe5/UY=; b=fiFVa3Bhb3MKhV3xW3/3RAOmMMbJiho8rHgoECvd6EixhghAuPts2Ocamws11kixc1T/X2 Fbqxhg4JO5HEci0K/MMsq6xRd46+s9v2pseD/3e7qJjCz1TVZADkocZO7uAhlfGYsc6IQW Szt5hH2YTP6F1oguqdEyGL/rNVUcshr+vg0LHx5wSwH7gVds1ZWo1xWPxkv2GeX6MT9ttI LgyldBgHT42ltGjBS04WiZRvzi9kJ7zU/Yz0M5YFdfscImRuatQZKsKPK1Bj6zNL0hZX0u CDag2Z+kojqHGZ0ipwZTs9lDGSkE3ViLsBCXom/6yraWq9oSMrrXbBMYBlE3XA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1602622851; a=rsa-sha256; cv=none; b=lEglGmEwZ5l6foMVP6iw/63qTLMJcPsCfbwYNzrhRAK4QDmOLfOyU0DFfEQrBYK2XBMoTU CVXTzJ+gTCOkatv38EnAfA9Q+VLpTT5spQ2sPy+MkUYXjoGgQOH9atZrs1ZGaJFlhSTFaD ky+mEhZxoZw9X0PC5Lt5qYJ+UCWgkvUA5QkwH+nGwm3BFRNAYtbELE3T4v27hPqtLvcbKJ 6Y9IU2nFbvObBgSWo7mNs1NtF8Jl4K1C6XElKQ7hy/nn+l7j/EkyxiQ94ls+fHxvGTVU0g nZm3tuKblyJeestIMUKLTWtfaQrYLPMiYBOuUE1rttieCtRnx17w+K1JNUWhwQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 21:01:00 -0000 Lou Berger writes: > > I have to admit that I have not read this draft, but noting, that m= ost > > of the cipher we use do require automated key management like IKE, = I > > just wonder are you really going to be limited to 3DES, or what > > automated key management you are going to be using instead of IKE, = and > > how can you guarantee that it actually does its job correctly for > > securing the key management over reboots etc. >=20 > I'm not advocating ike vs ike-less, just trying to have a comprehensi= ve=20 > solution.=A0 One example ikeless usecase is captured by the YANG mode= l in=20 > last call:=20 > https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n-09 Which will require similar behavior from the IPsec part than IKE, meaning you can't really change any parameters on the fly for existing SAs. You can't change for example the ciphers of the existing SA, and expect that to work. My understanding for that is that ike-less will not change any parameters of the existing SAs in the SAD, as that would definitely break everything, but instead they will allocate new SPI, install new SAD entry, and then remove the old SAD entry which causes the traffic move to use the newly created SAD entry. So for that use, there is no point of having a way to turn on IPTFS in the middle of SA use time, exactly as there is no need to try to change algorithms of the existing SAs. If you do that kind of things, you just create new SA, and delete old one. I am not sure whether this should be reflected on the draft-ietf-i2nsf-sdn-ipsec-flow-protection somehow, i.e., indicating that most (if not all) of the items in the sad-entry are write once type of things, i.e., you can write them once, but you can't modify them once they have been set, and only way to change them is to delete the whole sad-entry and recreate it with new values (most likely doing it other way round, i.e., first create new and delete old).=20 --=20 kivinen@iki.fi From nobody Tue Oct 13 15:31:22 2020 Return-Path: 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 00C103A11CF for ; Tue, 13 Oct 2020 15:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 Yw6iqf5yt3pX for ; Tue, 13 Oct 2020 15:31:18 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 DB43E3A11D3 for ; Tue, 13 Oct 2020 15:31:18 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 6028A215C10 for ; Tue, 13 Oct 2020 16:31:05 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id SSozkRO4mwNNlSSozkkdxM; Tue, 13 Oct 2020 16:31:05 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=OZq28CbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=afefHYAZSVUA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=-CPQQ8YuIOnntS2bvwAA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=-RoEEKskQ1sA:10:nop_election2020_name_body a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dlElJicn2RhVGk6e5FRA3BVJpNipIZW0ha1kPvlrCvA=; b=M9PgvnxeMGJwmB/R85Wi5ZzX5I GazvGhEitoBfhao/DINIvBc5Ed6wc7UzWa9vOKQjBRMqsTvDc5BXZkXbnM/VGZf3kJMchI/Hf1Gi5 TIzmxnDirKNzDGdTdgBAk2Z2a; Received: from [127.0.0.1] (port=52347 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kSSoz-000AuD-1t; Tue, 13 Oct 2020 16:31:05 -0600 To: Tero Kivinen Cc: ipsec@ietf.org, Valery Smyslov , 'Christian Hopps' References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> From: Lou Berger Message-ID: <0a608e6e-b220-6f64-c24d-83e80fe974dd@labn.net> Date: Tue, 13 Oct 2020 18:31:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <24454.5506.450515.501200@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1kSSoz-000AuD-1t X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:52347 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 22:31:21 -0000 Tero,     are you saying you not happy with the proposed text as discussed with valery? Thanks, Lou On 10/13/2020 5:00 PM, Tero Kivinen wrote: > Lou Berger writes: >>> I have to admit that I have not read this draft, but noting, that most >>> of the cipher we use do require automated key management like IKE, I >>> just wonder are you really going to be limited to 3DES, or what >>> automated key management you are going to be using instead of IKE, and >>> how can you guarantee that it actually does its job correctly for >>> securing the key management over reboots etc. >> I'm not advocating ike vs ike-less, just trying to have a comprehensive >> solution.  One example ikeless usecase is captured by the YANG model in >> last call: >> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 > Which will require similar behavior from the IPsec part than IKE, > meaning you can't really change any parameters on the fly for existing > SAs. You can't change for example the ciphers of the existing SA, and > expect that to work. > > My understanding for that is that ike-less will not change any > parameters of the existing SAs in the SAD, as that would definitely > break everything, but instead they will allocate new SPI, install new > SAD entry, and then remove the old SAD entry which causes the traffic > move to use the newly created SAD entry. > > So for that use, there is no point of having a way to turn on IPTFS in > the middle of SA use time, exactly as there is no need to try to > change algorithms of the existing SAs. If you do that kind of things, > you just create new SA, and delete old one. I am not sure whether this > should be reflected on the draft-ietf-i2nsf-sdn-ipsec-flow-protection > somehow, i.e., indicating that most (if not all) of the items in the > sad-entry are write once type of things, i.e., you can write them > once, but you can't modify them once they have been set, and only way > to change them is to delete the whole sad-entry and recreate it with > new values (most likely doing it other way round, i.e., first create > new and delete old). From nobody Tue Oct 13 23:26:59 2020 Return-Path: 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 27CBD3A13A0; Tue, 13 Oct 2020 23:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9C0bws-Jqtw9; Tue, 13 Oct 2020 23:26:53 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70FD3A0A60; Tue, 13 Oct 2020 23:26:52 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id a4so1900034lji.12; Tue, 13 Oct 2020 23:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=FlV/H2C/dsw1g9K0iFEddMb03n7NnWeR8lYj28AFeBA=; b=LPw4pa+li2u/nkd8GsoePLBTV7Yi2RhPm2Be5Op+8L26VhZVshA7uoeUKYZtnLI7UT xOvRkjyKA9XCYKBe26Rjwf/xTTHLUhtZn1soOB0P/acmlr9tvIfHlbr5cIoJEOzd7rH4 Cdxa/mX/D8gawSQuNjvvDtggIQ3eTRuTUnd9Nk3/tKc1O6lBNvabPTZ9mHesu3uM4yI9 99Pw0GOxTFhSObJQpQBEUmSAbkxSfY5yGi+H/WXpYX9ExKiYccKdUoox+ExvDTdP673P 0Rr+0WvxX7BqtVdkwTPooqVQHW2d/KtMNTMJRtIjrqCzykmRCdj0W0Qc0QoPMWoZ+57V +hgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=FlV/H2C/dsw1g9K0iFEddMb03n7NnWeR8lYj28AFeBA=; b=a9GQ3sXILszI/3vvLaNn+gV6igfEKRGG/cu0Z+bO0gePKelNyrPzVPP9gV1AzhWjiD SLdRkuAMidYjAxXOqbBqoDiZv/0NaBGlaMEcWvsySviUU+froAu9YI5XPxBBy6nLnRhQ IvS0g/+hEyt6N74uasgsldXGNENWfQol35z9xiLJkq0t5Y5ihgPHyhFOd6sD8kTn6VDG o268kW4O02UuNygRJqZ3MuDrZlActfkhIUBm2ZcmwEZABzdRhJ+XNeSyG2EIN8OmY3yB NLNZJvB6n2vIocpKt3J42BmmShGOiK0PW/9j6QkXn1Te/JOUTI59k0chQvTs8J4Wn+Ue S+MQ== X-Gm-Message-State: AOAM5304KwbLhJt6j7qJZlTm4gB2OUzSlD0PJ4+TFyHHocXFFy7GIN3r fo0y5aWX+hLA7oXp6GeM1M3gFHaH0gM= X-Google-Smtp-Source: ABdhPJyycypU6YgRQ9MIrAK162ZaZdI95spW40lNvPTKxiXBReAIh4NWWZnrh3gX6+g+IQdtAZ113Q== X-Received: by 2002:a2e:92d5:: with SMTP id k21mr1159991ljh.258.1602656810975; Tue, 13 Oct 2020 23:26:50 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id o14sm754600lfc.29.2020.10.13.23.26.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 23:26:50 -0700 (PDT) From: "Valery Smyslov" To: "'Lou Berger'" , "'Christian Hopps'" , Cc: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <1b3001d6a16e$6e614030$4b23c090$@gmail.com> <2af84d55-539a-cc37-5952-731d4d86473b@labn.net> In-Reply-To: <2af84d55-539a-cc37-5952-731d4d86473b@labn.net> Date: Wed, 14 Oct 2020 09:26:43 +0300 Message-ID: <000c01d6a1f2$fd2ef940$f78cebc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D6A20C.227E7B30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBR9Dg1QdoZI0c6Vo/AaLkIdpDHgLCxSxRAjbXs18B6rBqnQEamLQSAoWVN8MCQOm3xwKebyejAclKvHwCPz51A6cl78UA Content-Language: ru Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 06:26:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01D6A20C.227E7B30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Lou, Valery,=20 > If IKE is used to negotiate using IP-TFS, then such switching MUST = NOT take place. I read this added line as saying you can switch from tunnel to TFS, I = think you mean that use of TFS is controlled via IKE. How about? If IKE is used to negotiate using IP-TFS, then use of TFS is controlled per Section 5.1. =20 I think the text is still a bit ambiguous, since previous = sentence uses a normative SHOULD to support switching from tunnel to IPTFS and the proposed = text doesn=E2=80=99t forbid this behavior explicitly if IKE is used. I=E2=80=99d like to = see more explicit language for IKE case. How about: =20 If IKE is used to negotiate using IP-TFS, then use of TFS is controlled per Section 5.1, and thus the option of switching to IP-TFS receive-side operation on receipt of the first IP-TFS = payload MUST NOT be used. =20 Feel free to change the text keeping its sense... =20 Regards, Valery. Lou On 10/13/2020 10:37 AM, Valery Smyslov wrote: Valery, How about this: OLD Receive-side operation of IP-TFS does not require any per-SA configuration on the receiver; as such, an IP-TFS implementation SHOULD support the option of switching to IP-TFS receive-side operation on receipt of the first IP-TFS payload. NEW Receive-side operation of IP-TFS does not require any per-SA configuration on the receiver; as such, for tunnels created=20 without IKE, an IP-TFS implementation SHOULD support the option of switching to IP-TFS receive-side operation on receipt of the first IP-TFS payload for tunnels. I can live with MAY, but would prefer SHOULD. =20 =20 Does this work for you? =20 Yes, with the following addition. =20 Receive-side operation of IP-TFS does not require any per-SA configuration on the receiver; as such, for tunnels created=20 without IKE, an IP-TFS implementation SHOULD support the option of switching to IP-TFS receive-side operation on receipt of the first IP-TFS payload for tunnels. If IKE is used to negotiate using IP-TFS, then such switching MUST NOT take place. =20 With this addition I don=E2=80=99t mind having SHOULD for = ike-less case. =20 Regards, Valery. =20 =20 =20 =20 Lou =20 On 10/13/2020 10:06 AM, Valery Smyslov wrote: I can live with MAY. =20 OK, but it must be negotiable in any case if you plan to use it with = IKE. Otherwise we'll get black holes. =20 On 10/13/2020 9:16 AM, Valery Smyslov wrote: If you badly need this feature, then please make it MAY and negotiable, so that people can ignore it. SHOULD is too strong for it, leaving it non-negotiable is just unacceptable, IMHO. =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_000D_01D6A20C.227E7B30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Lou,

Valery,

> =    If IKE is used to negotiate using IP-TFS, then such = switching MUST NOT take place.

I read this added line = as saying you can switch from tunnel to TFS, I think you mean that use = of TFS is controlled via IKE.  How about?

   If IKE is used to negotiate using IP-TFS, then =
use of
=C2=A0=C2=A0 TFS =
is controlled per Section 5.1.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 I think the text is still a bit ambiguous, =C2=A0since previous =
sentence uses a normative SHOULD
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 to support switching from tunnel to IPTFS and the proposed text =
doesn=E2=80=99t forbid this
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 behavior explicitly if IKE is used. I=E2=80=99d like to see more =
explicit language for IKE case.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 How about:
 
   If IKE is used to negotiate using IP-TFS, then =
use of
=C2=A0=C2=A0 TFS =
is controlled per Section 5.1, and thus the option of =
switching
=C2=A0 =C2=A0to =
IP-TFS receive-side operation on receipt of the first IP-TFS =
payload
=C2=A0=C2=A0 MUST =
NOT be used.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Feel free to change the text keeping its =
sense...
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Valery.

Lou

On 10/13/2020 10:37 AM, Valery Smyslov = wrote:

Valery,

<= p>How about this:

OLD
   = Receive-side operation of IP-TFS does not require any = per-SA
   configuration on the receiver; as such, an IP-TFS = implementation
   SHOULD support the option of switching to = IP-TFS receive-side
   operation on receipt of the first = IP-TFS payload.

NEW
   Receive-side operation of = IP-TFS does not require any per-SA
   configuration on the = receiver; as such, for tunnels created
   without IKE, an = IP-TFS implementation
   SHOULD support the option of = switching to IP-TFS receive-side
   operation on receipt of = the first IP-TFS payload for tunnels.

I can live with MAY, but = would prefer SHOULD.

 

 
Does this work for =
you?
 
           &nbs=
p;  Yes, with the following addition.
 
   =
Receive-side operation of IP-TFS does not require any =
per-SA
   =
configuration on the receiver; as such, for tunnels created =

   without =
IKE, an IP-TFS implementation
   SHOULD support the option of switching to =
IP-TFS receive-side
   operation on receipt of the first IP-TFS =
payload for tunnels.
   If IKE is used to negotiate using IP-TFS, then =
such switching
   MUST NOT take =
place.
 
           &nbs=
p;  With this addition I don=E2=80=99t mind having SHOULD for =
ike-less case.
 
           &nbs=
p;  Regards,
           &nbs=
p;  Valery.
 

 

 

           &nbs=
p; 
Lou
 

On 10/13/2020 10:06 AM, Valery = Smyslov wrote:

I =
can live with MAY.
 
OK, =
but it must be negotiable in any case if you plan to use it with =
IKE.
Otherwise we'll get black =
holes.
 
On 10/13/2020 9:16 =
AM, Valery Smyslov wrote:
If you badly need =
this feature, then please make it MAY and =
negotiable,
so that people can ignore it. SHOULD is =
too strong for it,
leaving it non-negotiable is =
just unacceptable, =
IMHO.
 
_______________________________________________
<=
pre>IPsec mailing list
IPsec@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
<= /blockquote>



___________________________=
____________________
IPsec mailing =
list
IPsec@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
------=_NextPart_000_000D_01D6A20C.227E7B30-- From nobody Tue Oct 13 23:58:57 2020 Return-Path: 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 E6D983A13C4 for ; Tue, 13 Oct 2020 23:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VW2gjWFJeOuC for ; Tue, 13 Oct 2020 23:58:54 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E873A13C3 for ; Tue, 13 Oct 2020 23:58:54 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id dt13so3206730ejb.12 for ; Tue, 13 Oct 2020 23:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=4nLgJB5b+3B5kcFJegyckI0aNAP1ub1pDTanxm9F6Y4=; b=MBa81fKoVJh148dPQoOZXpAZGaWmfasC6ERHg2FNGCR+yOQs965qbhStfJhfR7BKBB YYrNnmK1BHvuKe16dOB8qTiOqY9QHv8Xzr+VY94YZvNjPpz0xVtkrVcEjFZmo+WKfTHA OvHXeiwTDt5XAKZClT+fS3OOHrZAHFiv5hvzJOpxYz7nSRhOAA76T41I/a752GP9RA1n f013N8CApIE+/ZXeKjQeZAcz94Kdfg2YOcw5OsYxmTTUt1IBFoO1W+xEHwFUa6kOBOYG 3k96GDw+zglAfcqNcIPO3MBWadeR3lpmuHRn7o9Dge/mOk8Df1opZsMcsP6nssrQb6oi FQlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=4nLgJB5b+3B5kcFJegyckI0aNAP1ub1pDTanxm9F6Y4=; b=I5map93OrBw4uh5NPYX/uPviawFNztbjemF2soPSaV/6w+xmJu9yIOTsPsyR6EUaC4 c55VIYzwF5/6hJFZ0uF0hOxPxEQUFlBubLi/zCa0HZqdnk+889M2l5vxSN6ImsuSNFEG IF4FEx3UC8/K3T+Y5uV8fcbfUirnw0j3a577jiAqbVe3ALy10YLtnHoEjw+xL/GjtONG Pn7QwbaBVc+OCvW9h2r0TqjNBcVXr2ixfohTv2j2LMKaImABQpoaaH4VkD7eZJWjDR+k 1Rfl/3bIpFZEKmZVYxpQP9FDlToIoBNT+tK1OQAE/g3CVB+yGbyed+JcW0xNyWnSsszz +tnQ== X-Gm-Message-State: AOAM5323cuW4J/jI+owrhkOYPl5Htw0upps0V/9E8LtWQaXmPyanXdiA ljUQbcIGyPI6sNX6b0B+0QJdVRZsPwQ= X-Google-Smtp-Source: ABdhPJx1sKidRIRYVZECJdCgqrW6EVLzzKLhMtXca4BkySTYT2ztU+5Zv+oUGZGHhyfg14nh26TLvA== X-Received: by 2002:a17:907:2179:: with SMTP id rl25mr3856777ejb.450.1602658732629; Tue, 13 Oct 2020 23:58:52 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id r24sm944718edm.95.2020.10.13.23.58.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 23:58:51 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Lou Berger'" Cc: , "'Christian Hopps'" References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> In-Reply-To: <24454.5506.450515.501200@fireball.acr.fi> Date: Wed, 14 Oct 2020 09:58:46 +0300 Message-ID: <001701d6a1f7$76981240$63c836c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBR9Dg1QdoZI0c6Vo/AaLkIdpDHgLCxSxRAjbXs18B6rBqnQEamLQSAoWVN8MCQOm3xwKebyejAfAZezoCQHfUywFMuMbDpxpTbtA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 06:58:56 -0000 Hi Tero, > > I'm not advocating ike vs ike-less, just trying to have a = comprehensive > > solution.=9A One example ikeless usecase is captured by the YANG = model in > > last call: > > = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09= >=20 > Which will require similar behavior from the IPsec part than IKE, > meaning you can't really change any parameters on the fly for existing > SAs. You can't change for example the ciphers of the existing SA, and > expect that to work. In fact, unlike changing e.g. cipher on the fly, that is not possible, because the cipher used is not present in the ESP packet, so that you=20 cannot distinguish two ESP packets with different ciphers, you can = distinguish=20 tunnel packets from IPTFS packets on receiving side=20 (by analyzing Next Header), so technically the proposed switching is workable. That said, I fully agree with you that it is a very bad idea and must be prohibited, at least for traditional IPsec.=20 I care less about other use cases (I recall that authors wanted to use IPTFS not only for IPsec, but as more generic=20 mechanism to pack several IP packets into one). So, I may leave with this option if it will be explicitly prohibited for traditional IPsec. IKE-less (l2nsf) use case is a corner case, I tend to agree with you that it should be prohibited for this case too. Regards, Valery. > My understanding for that is that ike-less will not change any > parameters of the existing SAs in the SAD, as that would definitely > break everything, but instead they will allocate new SPI, install new > SAD entry, and then remove the old SAD entry which causes the traffic > move to use the newly created SAD entry. >=20 > So for that use, there is no point of having a way to turn on IPTFS in > the middle of SA use time, exactly as there is no need to try to > change algorithms of the existing SAs. If you do that kind of things, > you just create new SA, and delete old one. I am not sure whether this > should be reflected on the draft-ietf-i2nsf-sdn-ipsec-flow-protection > somehow, i.e., indicating that most (if not all) of the items in the > sad-entry are write once type of things, i.e., you can write them > once, but you can't modify them once they have been set, and only way > to change them is to delete the whole sad-entry and recreate it with > new values (most likely doing it other way round, i.e., first create > new and delete old). > -- > kivinen@iki.fi From nobody Wed Oct 14 00:40:53 2020 Return-Path: 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 330F73A13E8 for ; Wed, 14 Oct 2020 00:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 M6o5ANHW3H4s for ; Wed, 14 Oct 2020 00:40:50 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A4CE73A13E4 for ; Wed, 14 Oct 2020 00:40:50 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id B7E1D61674; Wed, 14 Oct 2020 07:40:49 +0000 (UTC) From: Christian Hopps Message-Id: <56F3A6E6-EDD6-46FA-8829-EC10FD9AD058@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_89D667A0-016F-4173-9FAD-83D32513EF46"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 14 Oct 2020 03:40:48 -0400 In-Reply-To: <001701d6a1f7$76981240$63c836c0$@gmail.com> Cc: Christian Hopps , Tero Kivinen , Lou Berger , ipsec@ietf.org To: Valery Smyslov References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 07:40:52 -0000 --Apple-Mail=_89D667A0-016F-4173-9FAD-83D32513EF46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Indeed, this isn't about switching a pair of SAs to IPTFS in the middle = of the tunnel operation. This is only about supporting the receipt of = IPTFS as a payload in ESP. Zero conf (or globally config enabled) receive support of IPTFS payloads = is seen by some as a real value add. I'm not sure what the kerfuffle is = all about. :) Thanks, Chris. > On Oct 14, 2020, at 2:58 AM, Valery Smyslov = wrote: >=20 > Hi Tero, >=20 >>> I'm not advocating ike vs ike-less, just trying to have a = comprehensive >>> solution. One example ikeless usecase is captured by the YANG model = in >>> last call: >>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 >>=20 >> Which will require similar behavior from the IPsec part than IKE, >> meaning you can't really change any parameters on the fly for = existing >> SAs. You can't change for example the ciphers of the existing SA, and >> expect that to work. >=20 > In fact, unlike changing e.g. cipher on the fly, that is not possible, > because the cipher used is not present in the ESP packet, so that you > cannot distinguish two ESP packets with different ciphers, you can = distinguish > tunnel packets from IPTFS packets on receiving side > (by analyzing Next Header), so technically the proposed > switching is workable. That said, I fully agree with you > that it is a very bad idea and must be prohibited, > at least for traditional IPsec. >=20 > I care less about other use cases (I recall that authors wanted > to use IPTFS not only for IPsec, but as more generic > mechanism to pack several IP packets into one). So, I may leave > with this option if it will be explicitly prohibited > for traditional IPsec. IKE-less (l2nsf) use case is a corner case, > I tend to agree with you that it should be prohibited > for this case too. >=20 > Regards, > Valery. >=20 >> My understanding for that is that ike-less will not change any >> parameters of the existing SAs in the SAD, as that would definitely >> break everything, but instead they will allocate new SPI, install new >> SAD entry, and then remove the old SAD entry which causes the traffic >> move to use the newly created SAD entry. >>=20 >> So for that use, there is no point of having a way to turn on IPTFS = in >> the middle of SA use time, exactly as there is no need to try to >> change algorithms of the existing SAs. If you do that kind of things, >> you just create new SA, and delete old one. I am not sure whether = this >> should be reflected on the draft-ietf-i2nsf-sdn-ipsec-flow-protection >> somehow, i.e., indicating that most (if not all) of the items in the >> sad-entry are write once type of things, i.e., you can write them >> once, but you can't modify them once they have been set, and only way >> to change them is to delete the whole sad-entry and recreate it with >> new values (most likely doing it other way round, i.e., first create >> new and delete old). >> -- >> kivinen@iki.fi >=20 --Apple-Mail=_89D667A0-016F-4173-9FAD-83D32513EF46 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+Gq4AACgkQLh2DDte4 MCX5oxAAhgczaQSwpaxfccM7B25atBGY/KCRsv5/OJtun3aG7ukgvtxrjOuLiDPo jKM+am0Po2CQFKVRk23UNIyfaPr1KRYkcewGno3dNLYHFnsparvrvfbCCGXNv7yW PZKn/Mr8e/0r06VBX8ViN923RWAz/JNF+GLsKKX9W6HYgI996RRZoFDmmYucO6E0 Dx66BFHQCJ7COKAG7o7njtv/lZAZPcunaOOWIeuLx+W2TBwQ8VLcz4XvxXKOJDeS gB7WG4xtC98Ad6hec/6HCBfwOSOyiaFqvUDCAoztyFyTdPzpNTCyc8AUgwqwip15 mdfOrMGbsfV/m3bFRu2ijRrfjZ/9XqcyAsPQ69CZzMKLRkWds3LnIszTDMNWe9ha pL3qF4h/fe26q2T9VHMHmQ3gt9Ry7e558PJPXayrKJPEXn3MZKGesAiIP4Qu+IE8 qRrM9naGrR2h/nsqkkKW/F+yu+tJahuDCNvhA9aYGPk1Wcr9bIFe+o1o1Cea5xy3 7tvaCThSyJdvK3khXqPBi2UeXpKBmRr4erkrBxM+m6Lf8Nyo8ZRENIcxQorOt8Ux 3HQsEse7Xp06o32o033soNLfdJnKLvJEm35VPcoEpZtHiQUZQevDjp1NyrqVhDHB wqz/nRZNVIo/FDbRHl139CcBvZGvk5k8BGEzQOdYhjODgbfVRqY= =2RsD -----END PGP SIGNATURE----- --Apple-Mail=_89D667A0-016F-4173-9FAD-83D32513EF46-- From nobody Wed Oct 14 01:01:20 2020 Return-Path: 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 21E7B3A13FA for ; Wed, 14 Oct 2020 01:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8tWJCencFo8y for ; Wed, 14 Oct 2020 01:01:17 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DB63A13F8 for ; Wed, 14 Oct 2020 01:01:17 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id h6so2692544lfj.3 for ; Wed, 14 Oct 2020 01:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=LBIe9NSPwtyeBQbRKPuqRuGR6fxSnkbfmiOwmdeG9R0=; b=bNuz+JtomoL4UINbzDtt2H3GTe+1MYdA46U5BMxovQgfihYZCxpG7EcaRlw+6Q9uW1 NrHMD/7Vhp0Xn5Q2ahuhg6njOaiD0NCe1EJNaxS5bx0u8imZs4tbuVcAs0qXFyW0x4is VEiM0hIf37cSwLQbZrioZqaEJd3cCm2+sIdbioxK5leqp2endJUJ80HfHecHCqUpFPGy lx/3DzJUoQ6YYN+S/MmDZhrFci0Oo88EMlP0bzTScql8B83R1qsNCJhjXW3vlDjzVD6p cpdr0re6g7YH80p9zTr/svBUyYOSMjDmcXqyuLYtsgibSxaqFlWUEBFcVM9wAJbdwjKA YmeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=LBIe9NSPwtyeBQbRKPuqRuGR6fxSnkbfmiOwmdeG9R0=; b=RPMD1s4bJ7efsDiWVQejRsUvubNgIFr4rsOliJJOlVNUv78JSmS2kf7dXo2z97GIb5 +r56ABBo0n2g72amRnEOPhf1/HED/a5aXVr4FUrfPgk8gbmwo6F7jpBjfMk2fuR3thCY x/Rwlu+ard+Cci1B7zLmeJpH342yI1XBItJipD3tFrsIJBr3UcIt1tyShfbot2xLbfGQ fP58UoPUGspSlnOSt1fAueXgr1vUsOk+1rovAGzldgx6RkOEGB7zswBtPC+Npw7kiByB JLCS2foQJRKATWMumli7GRcjHvqcLeF7ySDusBrpqmxwkdjOQysPINMoDeQikUbpmUxp Gzkg== X-Gm-Message-State: AOAM5327VEuQ8mxSmkYSpRN8pALHU4YCDWVtBBoUN8zX1qejuvsO+xS+ 0zex0GKSZDifa1dvVHxD+9A= X-Google-Smtp-Source: ABdhPJyJN/48DmNl6gY6evUpc4Sr/6vr+Si57kMj4a4L/C/takU0eag+o7NUrV2db+a3ClmLsaHF+Q== X-Received: by 2002:ac2:51bb:: with SMTP id f27mr968020lfk.70.1602662475272; Wed, 14 Oct 2020 01:01:15 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id t21sm845894lfl.64.2020.10.14.01.01.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 01:01:14 -0700 (PDT) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'Tero Kivinen'" , "'Lou Berger'" , References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <56F3A6E6-EDD6-46FA-8829-EC10FD9AD058@chopps.org> In-Reply-To: <56F3A6E6-EDD6-46FA-8829-EC10FD9AD058@chopps.org> Date: Wed, 14 Oct 2020 11:01:09 +0300 Message-ID: <003b01d6a200$2d70df80$88529e80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLBR9Dg1QdoZI0c6Vo/AaLkIdpDHgLCxSxRAjbXs18B6rBqnQEamLQSAoWVN8MCQOm3xwKebyejAfAZezoCQHfUywFMuMbDAUR9UsACYJ5QqKb9O0vA Content-Language: ru Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 08:01:19 -0000 HI Chris, > Indeed, this isn't about switching a pair of SAs to IPTFS in the middle of the tunnel operation. This is only > about supporting the receipt of IPTFS as a payload in ESP. I admit, that English is not my native language :-), but the text in the draft in my reading suggests exactly what you write it is not suggesting - switching to IP-TFS in the middle of tunnel operation ("on receipt of the first IP-TFS payload"): 2.4. Zero-Conf Receive-Side Operation On The SA. Receive-side operation of IP-TFS does not require any per-SA configuration on the receiver; as such, an IP-TFS implementation SHOULD support the option of switching to IP-TFS receive-side operation on receipt of the first IP-TFS payload. If you intention was to require that all implementations SHOULD just support receiving IP-TFS packets (say, should implement IP-TFS), then the requirement is strange for me - in fact you require that all implementations support this extension. So, if you really meant some other thing, then the current text must be completely rewritten, so that it is clear for non-native readers (like me). Regards, Valery. > Zero conf (or globally config enabled) receive support of IPTFS payloads is seen by some as a real value add. > I'm not sure what the kerfuffle is all about. :) > > Thanks, > Chris. > > > On Oct 14, 2020, at 2:58 AM, Valery Smyslov wrote: > > > > Hi Tero, > > > >>> I'm not advocating ike vs ike-less, just trying to have a comprehensive > >>> solution. One example ikeless usecase is captured by the YANG model in > >>> last call: > >>> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 > >> > >> Which will require similar behavior from the IPsec part than IKE, > >> meaning you can't really change any parameters on the fly for existing > >> SAs. You can't change for example the ciphers of the existing SA, and > >> expect that to work. > > > > In fact, unlike changing e.g. cipher on the fly, that is not possible, > > because the cipher used is not present in the ESP packet, so that you > > cannot distinguish two ESP packets with different ciphers, you can distinguish > > tunnel packets from IPTFS packets on receiving side > > (by analyzing Next Header), so technically the proposed > > switching is workable. That said, I fully agree with you > > that it is a very bad idea and must be prohibited, > > at least for traditional IPsec. > > > > I care less about other use cases (I recall that authors wanted > > to use IPTFS not only for IPsec, but as more generic > > mechanism to pack several IP packets into one). So, I may leave > > with this option if it will be explicitly prohibited > > for traditional IPsec. IKE-less (l2nsf) use case is a corner case, > > I tend to agree with you that it should be prohibited > > for this case too. > > > > Regards, > > Valery. > > > >> My understanding for that is that ike-less will not change any > >> parameters of the existing SAs in the SAD, as that would definitely > >> break everything, but instead they will allocate new SPI, install new > >> SAD entry, and then remove the old SAD entry which causes the traffic > >> move to use the newly created SAD entry. > >> > >> So for that use, there is no point of having a way to turn on IPTFS in > >> the middle of SA use time, exactly as there is no need to try to > >> change algorithms of the existing SAs. If you do that kind of things, > >> you just create new SA, and delete old one. I am not sure whether this > >> should be reflected on the draft-ietf-i2nsf-sdn-ipsec-flow-protection > >> somehow, i.e., indicating that most (if not all) of the items in the > >> sad-entry are write once type of things, i.e., you can write them > >> once, but you can't modify them once they have been set, and only way > >> to change them is to delete the whole sad-entry and recreate it with > >> new values (most likely doing it other way round, i.e., first create > >> new and delete old). > >> -- > >> kivinen@iki.fi > > From nobody Wed Oct 14 01:07:51 2020 Return-Path: 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 8E7943A13E7 for ; Wed, 14 Oct 2020 01:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QV_13ROpOG1X for ; Wed, 14 Oct 2020 01:07:49 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF123A0EF3 for ; Wed, 14 Oct 2020 01:07:49 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4F65461674; Wed, 14 Oct 2020 08:07:48 +0000 (UTC) From: Christian Hopps Message-Id: <9A514314-DA80-4498-9FFA-22B8647D2D9D@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_EE3605D7-FAB9-4F77-9AED-BF57C864FBD7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 14 Oct 2020 04:07:47 -0400 In-Reply-To: <003b01d6a200$2d70df80$88529e80$@gmail.com> Cc: Christian Hopps , Tero Kivinen , Lou Berger , ipsec@ietf.org To: Valery Smyslov References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <56F3A6E6-EDD6-46FA-8829-EC10FD9AD058@chopps.org> <003b01d6a200$2d70df80$88529e80$@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 08:07:51 -0000 --Apple-Mail=_EE3605D7-FAB9-4F77-9AED-BF57C864FBD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What is intended is that an implementation can process inbound IPTFS = payloads w/o actually explicitly configuring the inbound SA to be in = "IPTFS-mode" (zero-conf). That is all. Thanks, Chris. > On Oct 14, 2020, at 4:01 AM, Valery Smyslov = wrote: >=20 > HI Chris, >=20 >> Indeed, this isn't about switching a pair of SAs to IPTFS in the = middle of the tunnel operation. This is only >> about supporting the receipt of IPTFS as a payload in ESP. >=20 > I admit, that English is not my native language :-), but the text in = the draft in my reading > suggests exactly what you write it is not suggesting - switching to = IP-TFS in the middle of tunnel operation > ("on receipt of the first IP-TFS payload"): >=20 > 2.4. Zero-Conf Receive-Side Operation On The SA. >=20 > Receive-side operation of IP-TFS does not require any per-SA > configuration on the receiver; as such, an IP-TFS implementation > SHOULD support the option of switching to IP-TFS receive-side > operation on receipt of the first IP-TFS payload. >=20 > If you intention was to require that all implementations SHOULD just = support receiving IP-TFS packets > (say, should implement IP-TFS), then the requirement is strange for me = - > in fact you require that all implementations support this extension. >=20 > So, if you really meant some other thing, then the current text > must be completely rewritten, so that it is clear for non-native = readers (like me). >=20 > Regards, > Valery. >=20 >> Zero conf (or globally config enabled) receive support of IPTFS = payloads is seen by some as a real value add. >> I'm not sure what the kerfuffle is all about. :) >>=20 >> Thanks, >> Chris. >>=20 >>> On Oct 14, 2020, at 2:58 AM, Valery Smyslov = wrote: >>>=20 >>> Hi Tero, >>>=20 >>>>> I'm not advocating ike vs ike-less, just trying to have a = comprehensive >>>>> solution. One example ikeless usecase is captured by the YANG = model in >>>>> last call: >>>>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 >>>>=20 >>>> Which will require similar behavior from the IPsec part than IKE, >>>> meaning you can't really change any parameters on the fly for = existing >>>> SAs. You can't change for example the ciphers of the existing SA, = and >>>> expect that to work. >>>=20 >>> In fact, unlike changing e.g. cipher on the fly, that is not = possible, >>> because the cipher used is not present in the ESP packet, so that = you >>> cannot distinguish two ESP packets with different ciphers, you can = distinguish >>> tunnel packets from IPTFS packets on receiving side >>> (by analyzing Next Header), so technically the proposed >>> switching is workable. That said, I fully agree with you >>> that it is a very bad idea and must be prohibited, >>> at least for traditional IPsec. >>>=20 >>> I care less about other use cases (I recall that authors wanted >>> to use IPTFS not only for IPsec, but as more generic >>> mechanism to pack several IP packets into one). So, I may leave >>> with this option if it will be explicitly prohibited >>> for traditional IPsec. IKE-less (l2nsf) use case is a corner case, >>> I tend to agree with you that it should be prohibited >>> for this case too. >>>=20 >>> Regards, >>> Valery. >>>=20 >>>> My understanding for that is that ike-less will not change any >>>> parameters of the existing SAs in the SAD, as that would definitely >>>> break everything, but instead they will allocate new SPI, install = new >>>> SAD entry, and then remove the old SAD entry which causes the = traffic >>>> move to use the newly created SAD entry. >>>>=20 >>>> So for that use, there is no point of having a way to turn on IPTFS = in >>>> the middle of SA use time, exactly as there is no need to try to >>>> change algorithms of the existing SAs. If you do that kind of = things, >>>> you just create new SA, and delete old one. I am not sure whether = this >>>> should be reflected on the = draft-ietf-i2nsf-sdn-ipsec-flow-protection >>>> somehow, i.e., indicating that most (if not all) of the items in = the >>>> sad-entry are write once type of things, i.e., you can write them >>>> once, but you can't modify them once they have been set, and only = way >>>> to change them is to delete the whole sad-entry and recreate it = with >>>> new values (most likely doing it other way round, i.e., first = create >>>> new and delete old). >>>> -- >>>> kivinen@iki.fi >>>=20 >=20 >=20 --Apple-Mail=_EE3605D7-FAB9-4F77-9AED-BF57C864FBD7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+GsdMACgkQLh2DDte4 MCUcuw//ZPxwdwu3U6HuTN9hHIoVEK60UxDY4EzyRjbTh/49UFREpwFfUO2WXjF5 fUGhFseWDGy2d7qIUjsRvKsBeFleWr0o+2GuOis2uYteeKhXBaBaYpVOaqSejTFh m3YRkY8yLv6uw1cuC/Z//2/kNobpQHcDs0qv0Cz0i8kPlUB40novYpt0LtqZhTjm WffKREB9zrkydMOjUha4OX/g9GfBny11THVFZZwY8tAVMjk8q/NKnm4A2QIr/cMu XATCrPWpHfm8YEu1+vO4+VUv/v5PlQUWBdXZdWottf7f3WB6UpTk1gPk5jlcxwEu qdewOpIEoWRO4mKXKrwLS3m3XK6LAN+8XsXyaZT8yhf+bBwViBHYFFo9u2sj9H+Z Joo0VF341S5K7lZpbdn3VFRsPgI1oaQHHLZ8Asq2ZcNu4410MpEMZmoT8khtsKQj gy+XQmgyHO3IzYRyglTAYxV3UxTFXrYiD2vp5eltVPvqmR9zBnKup6qqKpIrSmeE 9cvG2rlETzLxRLCIYOkZZAJhguwwfpY/WyT+K3tdjzj/cZyxfH/Vk2Cgi1NvU2KM iDI1sBjLE0lpZP95qiYjllU9Ibw4uTQBeRLQJ1hbWQtHNzd8S3jtxQXDLUm2g7lI neX7IhSDlQOIaBX2IwR/cc1stetxIj9faB5lsiJPbsJjHtFmHHc= =WIiU -----END PGP SIGNATURE----- --Apple-Mail=_EE3605D7-FAB9-4F77-9AED-BF57C864FBD7-- From nobody Wed Oct 14 02:55:14 2020 Return-Path: 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 D45EA3A143A for ; Wed, 14 Oct 2020 02:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 XxA2FyQmXjmy for ; Wed, 14 Oct 2020 02:55:10 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 416A83A1415 for ; Wed, 14 Oct 2020 02:55:09 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id C0E0C1B00193; Wed, 14 Oct 2020 12:55:06 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602669306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZxqSzuSxmZ5d8nPBOQO54isyZOe8l2sNShOE7BfBjXA=; b=saaE06iNXbuBkc7XnBz+rP2y3D+3dap4FXpz00du9MZfIBIMp52CNE02MaC/wvm3MVMMVh MK0z4oTKe1dM9I9iVujU8fZsDviIHxzEUT+PRDAW9g1+3GWrG78sWli5x3m2UNwCXraVU5 XikH+Ahy70LoQhnA2RKuR/F+Yh1bbnQTGcQofOvVSpStrFTvjMdmPyKPd4IS1Rvb2jvGzK jBbANM5Sth1984Z2AgThR1K+XrCBGKGnj5gaxdT/VU+TFKZqDnVeRKzJiHGEuEfXUV9aV1 ipBFvEY2+s2Hjmd0cP1smbQ4u5wTHygj54U8mXJTbuApoBMjoTH0nj+0sg2hhQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 4AA2A25C1738; Wed, 14 Oct 2020 12:55:06 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24454.51962.50262.36523@fireball.acr.fi> Date: Wed, 14 Oct 2020 12:55:06 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Lou Berger'" , , "'Christian Hopps'" In-Reply-To: <001701d6a1f7$76981240$63c836c0$@gmail.com> References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 15 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602669306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZxqSzuSxmZ5d8nPBOQO54isyZOe8l2sNShOE7BfBjXA=; b=IPeduQhRmcli9clKCCRg+4m3wYZaKu8YIoywiBeqHGuZ2wS8bH0JDiAhqg6i9vg+NSdzIz kPmSwwgjRMXZnP08d/JK5efkNqVljHo2XCcf0YKvZ+uVg9ExLnHbwqqvBT7H3hEnsUMB0U bppN+K4q1P8R1PVAmmbYPF1wrQnf6kPoghhkf2CWeGS0+tZx6a/+z3rgRHFjkLJqD5mrSO ucBPRSaGO80qtggOxe9ExdsgO1O11qJ7Fjh6PaPXuhXuknKr4I0Mq40Ohn9qV/ZyfXIOsQ NlGmO7YdzOz2bJWFpJPpLiDD1L66iJuEXmVN73/pEcuE47OeItpwQRNLUcB2Yg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1602669306; a=rsa-sha256; cv=none; b=G2JLc+McjV/4Teym0EQtUd+7/PycQ3HVjtuG94/fCLxbu5zyhxxN2LI9oa1qQ1GYasVpFW 7fTanx9tuvoFcK0dzkGIlSBGuAT0kg9q1qMKDvyFLqokIgbp8/BtpDTxJcnmW6f6iGf5rh FTrb08alRBfvtQK676Mal3//7+J9VQIRpznMqj5eLqW+FWpSwcbWCRy6Dcy/rLDtNT67AB 4jwpmnmPte4DWKbChF/AgRdIXWwBqh6imPl8qAG6Cb6UltDfb6UmkaMOA6FtXWnw/1naSd g+Hi+szxlVKRpibuIS6Eg9/X8MNPknKpA+ezFP5b/idxt2mBJw/zBMNgvDITnA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 09:55:13 -0000 Valery Smyslov writes: > Hi Tero, >=20 > > > I'm not advocating ike vs ike-less, just trying to have a compreh= ensive > > > solution.=A0 One example ikeless usecase is captured by the YANG = model in > > > last call: > > > https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-09 > >=20 > > Which will require similar behavior from the IPsec part than IKE, > > meaning you can't really change any parameters on the fly for exist= ing > > SAs. You can't change for example the ciphers of the existing SA, a= nd > > expect that to work. >=20 > In fact, unlike changing e.g. cipher on the fly, that is not > possible, because the cipher used is not present in the ESP packet, > so that you cannot distinguish two ESP packets with different > ciphers, you can distinguish tunnel packets from IPTFS packets on > receiving side (by analyzing Next Header), so technically the > proposed switching is workable. That said, I fully agree with you > that it is a very bad idea and must be prohibited, at least for > traditional IPsec. I have never understood why the IPTFS packets needs to be identified by the Next Header. We do not include cipher algorithm in the ESP packet, so that is known by the SA information. We could do exactly same for the IPTFS, i.e., if all packets inside the specific SA is always IPTFS packets, then there is no need to identify whether IPTFS is used or not in the Next Header field, and there would be no need to allocate new IP protocol number for this. If the reason we need new IP protocol number is just because they want to be able to this switching of the IPTFS on in the middle of the IPsec SA when NOT using IKE, then I think that is not very good reason for allocating new IP protocol number.=20 > I care less about other use cases (I recall that authors wanted > to use IPTFS not only for IPsec, but as more generic=20 > mechanism to pack several IP packets into one). I would like to understand what these other use cases are and how they affect the use case for IPsec. I mean if those use cases are just "we want to make generic mechanism" without any specific use cases, there is no need to think about the Early allocation of the IP protocol number. > So, I may leave with this option if it will be explicitly prohibited > for traditional IPsec. And if interoperability testing etc of the IPTFS in the IPsec use case is done using IKE, and in that case we do not need new IP protocol number, as we can know from the IPsec SA whether IPTFS is enabled or not. There is no need to know that per packet basis. And In that case IP protocol number allocation can be later, when other uses cases emerge. > IKE-less (l2nsf) use case is a corner case, I tend to agree with you > that it should be prohibited for this case too. Definitely. Actually I think the i2nfs document should probably say something about changing SAD stucture during on the fly. I would expect that most of the implementations in kernel do not really allow easy way of modifying the replay window or things like that while the SA is being used. In normal case there is no need to ever set the for example replay window, it will start from all zeros when SA is created, and automatically updated after that. Other things like sequence numbers or IV can cause serious security issues if they are modified wihtout following specific rules. With my quick check of the i2nfs draft I did not see whether it has any text saying those things are create once, and after that read only or not. I think it should have that kind of text somewhere.... --=20 kivinen@iki.fi From nobody Wed Oct 14 03:19:15 2020 Return-Path: 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 4D7143A145F for ; Wed, 14 Oct 2020 03:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 xeuqViRf0cNM for ; Wed, 14 Oct 2020 03:19:12 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 1041D3A145D for ; Wed, 14 Oct 2020 03:19:11 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id E6A9D1B0029D; Wed, 14 Oct 2020 13:19:08 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602670749; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tp9kSNzvKio6a7umKotCy1qEmIqH20ePwSxe4A3HWIY=; b=rph6pWpGk7KvRMFfKjkSsVQU6YyGY61FU25Y+dOXcqXHco8UXByxD7CLliBtcuYQqPEiqM 3ou+D2ke04gHxpLZF8jhlVL4ZE9dDqM38qZCjlWHjSg5HP+RF7Z31pIvzQOFP4cfmZXSHr vTGUZfCk4MuYCPCodeDOJ4u2mGE/5O3GjGaM+lNUsQ93YZKFW2T9xKaBFKrJj3/MzPhAX3 MviFdZTt3X2+94evtgZqwV39a8JAr++/Po6hTXusqgNynkQqIQ4mV5borXHXTt/DFGxSwR /KdVQ1I5GpkhH1/pLtoJhUZtQsnbV/n2k0mYfFKJZSzwmaKFJzLZFUnEnOZwjg== Received: by fireball.acr.fi (Postfix, from userid 15204) id 15E7725C1739; Wed, 14 Oct 2020 13:19:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24454.53404.39277.731780@fireball.acr.fi> Date: Wed, 14 Oct 2020 13:19:08 +0300 From: Tero Kivinen To: Christian Hopps Cc: Valery Smyslov , Lou Berger , ipsec@ietf.org In-Reply-To: <9A514314-DA80-4498-9FFA-22B8647D2D9D@chopps.org> References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <56F3A6E6-EDD6-46FA-8829-EC10FD9AD058@chopps.org> <003b01d6a200$2d70df80$88529e80$@gmail.com> <9A514314-DA80-4498-9FFA-22B8647D2D9D@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 21 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602670748; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tp9kSNzvKio6a7umKotCy1qEmIqH20ePwSxe4A3HWIY=; b=iFrMg98gkl0AVwjDCnFzLpS70yvDqm5O+Fb0v1WvMVsoi63OhL8u71Uxgm+JNZS1NjLL0N +ZgXPAuiQjhjrnIS3i6f0ejXRLvEC4dL+870kczc9f/GWoSo1BUJhD2KDnjdfztIY585CY XgEK8tYBlXzb7HRjM+OiX9M6lUh3mBLHDui0BJus/Ds1CJU1dEVbH0yTuso52ftc2ZL5Ji PSNWeBWb8JN29we5pkm7OArrXOMy0MCcXhVLSbmmZ6lslg0J1qVkqIq3OOC/qe5bc5qbq9 9TktI39+9xuoKlN6dIqysg0bn2JiFbIwtZaAr0MKQ4yqhP2s5TJN0uolZtYIhQ== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1602670749; a=rsa-sha256; cv=none; b=MVNTpiyTczOuoHjUkc9gMNhwsgungPYS99ksCZaudIFfFlCo4Denx2kpf4+SndMHluK0GC jVsxHhn58CO8W4VaZoW5r+X/7FiA/OR2Sfb2+Klt399rBiSfmNxX3kGmThnxP4R5XlY9hB ihKujJkKqOhw5GKw7XYyf3rbC4zPZiMei6dSoea7jYceiljTT0zIAy49xTYhDDaT0oiLhG lcTEE1Mmcb0Hi/FmCB2r6i8FW1/SyCuihxFB/SDpJNnUAoDztsWjf0HZo6JOOtpHcpWLlO hQSy+n8cbMHnpl0uZqYLZNA/lwYpuTz8OmAff9H1uto2jwvY8lKwIjAF6nQXUg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 10:19:14 -0000 Christian Hopps writes: > What is intended is that an implementation can process inbound IPTFS > payloads w/o actually explicitly configuring the inbound SA to be in > "IPTFS-mode" (zero-conf). That is all. And if IKE is used what is the use case for that? IKE allows easy way of agreeing on the set of parameters for each IPsec SA, and agreeing on the mode of the encapsulation is one thing it already does. It does negotiate whether the IPsec SA is in tunnel or transport mode, and for my view the IPTFS is just one more mode for that, i.e., something that can be negotiated when IPsec SA is created using IKE, and then that encapsulation mode is used. There is no need to know or do that per packet basis. In theory in recipient we could detect tunnel mode by looking at the next header field of the inner packet, and if we see it is IP inside the packet, then we would assume it is tunnel mode, and enable tunnel mode processing. We do not do that, we do negotiate whether the IPsec SA is tunnel or transport mode and create IPsec SA either in tunnel or in transport mode. Earlier there was also another encapsuluation mode called a Bound End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and in that case it would have been impossible to detect the mode from the incoming packet, as lots of the information needed to reconstruct the end to end IP header is stored in the SA. Anyways we do store things in the IPsec SA when we create them, we do have negotiation mechanism to agree on those parameters and we can use them, we do not need to process things per packet basis. [1] https://tools.ietf.org/html/draft-nikander-esp-beet-mode-09 -- kivinen@iki.fi From nobody Wed Oct 14 03:20:43 2020 Return-Path: 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 4F7E03A1461 for ; Wed, 14 Oct 2020 03:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CpIEYZBMslB4 for ; Wed, 14 Oct 2020 03:20:39 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 462A63A145D for ; Wed, 14 Oct 2020 03:20:39 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7C98061674; Wed, 14 Oct 2020 10:20:38 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D2AE64C0-987D-43CB-9AC6-34004CBB053D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 14 Oct 2020 06:20:37 -0400 In-Reply-To: <24454.51962.50262.36523@fireball.acr.fi> Cc: Christian Hopps , Valery Smyslov , Lou Berger , ipsec@ietf.org To: Tero Kivinen References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 10:20:41 -0000 --Apple-Mail=_D2AE64C0-987D-43CB-9AC6-34004CBB053D Content-Type: multipart/alternative; boundary="Apple-Mail=_65DD7FD7-229F-4CA0-9471-8E4350E84EC7" --Apple-Mail=_65DD7FD7-229F-4CA0-9471-8E4350E84EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I really don't understand the extreme back pressure against using ESP = the way it was designed. The next-header field is supposed to identify = the payload, it does so for every other payload ESP carries. Any other = solution to somehow infer the payload type some other way *has* to be = seen as a hack. Why do we need a hack? The fact that using a payload identifier the way ESP intended also = allows us to do things like handle receipt of said payload without extra = configuration, or use the payload outside of ESP are just benefits from = good design, they aren't indicative of doing something incorrectly, the = opposite in fact. They also shouldn't even be needed to justify using = ESP the way it was designed to be used. This is all very strange to me, this want to not use the next-header = field to, you know, identify the next header. Thanks, Chris. > On Oct 14, 2020, at 5:55 AM, Tero Kivinen wrote: >=20 > Valery Smyslov writes: >> Hi Tero, >>=20 >>>> I'm not advocating ike vs ike-less, just trying to have a = comprehensive >>>> solution. One example ikeless usecase is captured by the YANG = model in >>>> last call: >>>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 >>>=20 >>> Which will require similar behavior from the IPsec part than IKE, >>> meaning you can't really change any parameters on the fly for = existing >>> SAs. You can't change for example the ciphers of the existing SA, = and >>> expect that to work. >>=20 >> In fact, unlike changing e.g. cipher on the fly, that is not >> possible, because the cipher used is not present in the ESP packet, >> so that you cannot distinguish two ESP packets with different >> ciphers, you can distinguish tunnel packets from IPTFS packets on >> receiving side (by analyzing Next Header), so technically the >> proposed switching is workable. That said, I fully agree with you >> that it is a very bad idea and must be prohibited, at least for >> traditional IPsec. >=20 > I have never understood why the IPTFS packets needs to be identified > by the Next Header. We do not include cipher algorithm in the ESP > packet, so that is known by the SA information. We could do exactly > same for the IPTFS, i.e., if all packets inside the specific SA is > always IPTFS packets, then there is no need to identify whether IPTFS > is used or not in the Next Header field, and there would be no need to > allocate new IP protocol number for this. >=20 > If the reason we need new IP protocol number is just because they want > to be able to this switching of the IPTFS on in the middle of the > IPsec SA when NOT using IKE, then I think that is not very good reason > for allocating new IP protocol number. >=20 >> I care less about other use cases (I recall that authors wanted >> to use IPTFS not only for IPsec, but as more generic >> mechanism to pack several IP packets into one). >=20 > I would like to understand what these other use cases are and how they > affect the use case for IPsec. I mean if those use cases are just "we > want to make generic mechanism" without any specific use cases, there > is no need to think about the Early allocation of the IP protocol > number. >=20 >> So, I may leave with this option if it will be explicitly prohibited >> for traditional IPsec. >=20 > And if interoperability testing etc of the IPTFS in the IPsec use case > is done using IKE, and in that case we do not need new IP protocol > number, as we can know from the IPsec SA whether IPTFS is enabled or > not. There is no need to know that per packet basis. And In that case > IP protocol number allocation can be later, when other uses cases > emerge. >=20 >> IKE-less (l2nsf) use case is a corner case, I tend to agree with you >> that it should be prohibited for this case too. >=20 > Definitely. Actually I think the i2nfs document should probably say > something about changing SAD stucture during on the fly. I would > expect that most of the implementations in kernel do not really allow > easy way of modifying the replay window or things like that while the > SA is being used. In normal case there is no need to ever set the for > example replay window, it will start from all zeros when SA is > created, and automatically updated after that. Other things like > sequence numbers or IV can cause serious security issues if they are > modified wihtout following specific rules. >=20 > With my quick check of the i2nfs draft I did not see whether it has > any text saying those things are create once, and after that read only > or not. I think it should have that kind of text somewhere.... > -- > kivinen@iki.fi --Apple-Mail=_65DD7FD7-229F-4CA0-9471-8E4350E84EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I really don't understand the extreme back pressure against = using ESP the way it was designed. The next-header field is supposed to = identify the payload, it does so for every other payload ESP carries. = Any other solution to somehow infer the payload type some other way = *has* to be seen as a hack. Why do we need a hack?

The fact = that using a payload identifier the way ESP intended also allows us to = do things like handle receipt of said payload without extra = configuration, or use the payload outside of ESP are just benefits from = good design, they aren't indicative of doing something incorrectly, the = opposite in fact. They also shouldn't even be needed to justify using = ESP the way it was designed to be used.

This is all very strange to me, this = want to not use the next-header field to, you know, identify the next = header.

Thanks,
Chris.


On Oct 14, 2020, at 5:55 AM, Tero Kivinen <kivinen@iki.fi> = wrote:

Valery = Smyslov writes:
Hi Tero,

I'm not advocating ike vs ike-less, just trying to have a = comprehensive
solution.  One example ikeless usecase = is captured by the YANG model in
last call:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-09

Which will = require similar behavior from the IPsec part than IKE,
meaning you can't really change any parameters on the fly for = existing
SAs. You can't change for example the ciphers of = the existing SA, and
expect that to work.

In fact, unlike changing e.g. = cipher on the fly, that is not
possible, because the = cipher used is not present in the ESP packet,
so that you = cannot distinguish two ESP packets with different
ciphers, = you can distinguish tunnel packets from IPTFS packets on
receiving side (by analyzing Next Header), so technically = the
proposed switching is workable. That said, I fully = agree with you
that it is a very bad idea and must be = prohibited, at least for
traditional IPsec.

I have never understood why the IPTFS packets needs to be = identified
by the Next = Header. We do not include cipher algorithm in the ESP
packet, so = that is known by the SA information. We could do exactly
same for the = IPTFS, i.e., if all packets inside the specific SA is
always IPTFS = packets, then there is no need to identify whether IPTFS
is used or = not in the Next Header field, and there would be no need to
allocate new = IP protocol number for this.

If the reason we need new IP protocol number is just because = they want
to be able to = this switching of the IPTFS on in the middle of the
IPsec SA when = NOT using IKE, then I think that is not very good reason
for = allocating new IP protocol number. 

I = care less about other use cases (I recall that authors wanted
to use IPTFS not only for IPsec, but as more generic 
mechanism to = pack several IP packets into one).

I would like = to understand what these other use cases are and how they
affect the = use case for IPsec. I mean if those use cases are just "we
want to make = generic mechanism" without any specific use cases, there
is no need to = think about the Early allocation of the IP protocol
number.

So, I may leave with this option if = it will be explicitly prohibited
for traditional IPsec.

And if interoperability testing etc of the IPTFS in the IPsec = use case
is done using = IKE, and in that case we do not need new IP protocol
number, as we = can know from the IPsec SA whether IPTFS is enabled or
not. There is = no need to know that per packet basis. And In that case
IP protocol = number allocation can be later, when other uses cases
emerge.

IKE-less (l2nsf) use case is a corner = case, I tend to agree with you
that it should be = prohibited for this case too.

Definitely. = Actually I think the i2nfs document should probably say
something = about changing SAD stucture during on the fly. I would
expect that = most of the implementations in kernel do not really allow
easy way of = modifying the replay window or things like that while the
SA is being = used. In normal case there is no need to ever set the for
example = replay window, it will start from all zeros when SA is
created, and = automatically updated after that. Other things like
sequence = numbers or IV can cause serious security issues if they are
modified = wihtout following specific rules.

With my quick check of the i2nfs draft I did not see whether = it has
any text = saying those things are create once, and after that read only
or not. I = think it should have that kind of text somewhere....
-- 
kivinen@iki.fi

= --Apple-Mail=_65DD7FD7-229F-4CA0-9471-8E4350E84EC7-- --Apple-Mail=_D2AE64C0-987D-43CB-9AC6-34004CBB053D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+G0PUACgkQLh2DDte4 MCVA5BAAo7lJkqQzxbCXQW41qeOuA6TzeXDF5lBSOWWtYR1riJpiJVNvI+j6xbNw 8yYMOYb+KjtdNOWdIgdEeYxyY/Oi6oHsXOaE1uIHLwRsQ+z8057s78d3fkIbsBHU EHSdU8dw0VQVhYrEoPqLrszxGhm4O2MGfChuR3t5uqQ34ytTkttUiuLcPT8Xd2sQ BZzFJrJQFaiSggciOWF9cHuOQVfOKFg3+DqVCvYL1GUK5TBqsgFtIK3LdHUU3tlc phcfRhxzWcYSvc4uexrSp84+t+irzRa283Xwv7IEkmfLFGUUgYOyYN1a1NLA/ozf G6AgwjnfHHdKxmirc2yG7iL/6+65zbOssSZLjgmhO+aq+wzBdjAq2HEVTEUM+kO1 Jzg3+HuDRAoE4gbnjAoPPk00vMley2Chl4odyWJjyrj915rhxqWRSTqgUfqx+4SX roPsPpsuD42sZiE2Z7NVIcyZJWe9nhSc3zFKRY2zGVec38rCOEeKPtTTmEOZLP+T kOjIIIAOwd1mcEO2OOvCz0cmvqOgmfaYg3ml5Z3mAXUPp02z2G4TgQVy7AqzrM1t 487LsQiJLif8MNDH8TVI6OzzSdw8/ljwvbEf9JnEa7Fgn/PdmaVCULyazzNGPajI Zq5KklHwglonOhP8bsdcbeoRr48R+3qJeKkxVjB7omFp0ua8z/I= =W5Qu -----END PGP SIGNATURE----- --Apple-Mail=_D2AE64C0-987D-43CB-9AC6-34004CBB053D-- From nobody Wed Oct 14 03:24:33 2020 Return-Path: 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 1C8413A1464 for ; Wed, 14 Oct 2020 03:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 s8XmpcjyYUUu for ; Wed, 14 Oct 2020 03:24:29 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 33E163A1463 for ; Wed, 14 Oct 2020 03:24:29 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8EEA561674; Wed, 14 Oct 2020 10:24:28 +0000 (UTC) From: Christian Hopps Message-Id: <27AAF738-100F-4CD5-A498-BE8E93765343@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_9A5F94F1-B7A3-490F-AE2B-22C9DAE527C9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 14 Oct 2020 06:24:27 -0400 In-Reply-To: <24454.53404.39277.731780@fireball.acr.fi> Cc: Christian Hopps , Valery Smyslov , Lou Berger , ipsec@ietf.org To: Tero Kivinen References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <56F3A6E6-EDD6-46FA-8829-EC10FD9AD058@chopps.org> <003b01d6a200$2d70df80$88529e80$@gmail.com> <9A514314-DA80-4498-9FFA-22B8647D2D9D@chopps.org> <24454.53404.39277.731780@fireball.acr.fi> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 10:24:31 -0000 --Apple-Mail=_9A5F94F1-B7A3-490F-AE2B-22C9DAE527C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 14, 2020, at 6:19 AM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >> What is intended is that an implementation can process inbound IPTFS >> payloads w/o actually explicitly configuring the inbound SA to be in >> "IPTFS-mode" (zero-conf). That is all. >=20 > And if IKE is used what is the use case for that? The text Lou and Valery ended up with indicated this was not used in the = IKE case. > IKE allows easy way of agreeing on the set of parameters for each > IPsec SA, and agreeing on the mode of the encapsulation is one thing > it already does. It does negotiate whether the IPsec SA is in tunnel > or transport mode, and for my view the IPTFS is just one more mode for > that, i.e., something that can be negotiated when IPsec SA is created > using IKE, and then that encapsulation mode is used. There is no need > to know or do that per packet basis. >=20 > In theory in recipient we could detect tunnel mode by looking at the > next header field of the inner packet, and if we see it is IP inside > the packet, then we would assume it is tunnel mode, and enable tunnel > mode processing. We do not do that, we do negotiate whether the IPsec > SA is tunnel or transport mode and create IPsec SA either in tunnel or > in transport mode. >=20 > Earlier there was also another encapsuluation mode called a Bound > End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and > in that case it would have been impossible to detect the mode from the > incoming packet, as lots of the information needed to reconstruct the > end to end IP header is stored in the SA. >=20 > Anyways we do store things in the IPsec SA when we create them, we do > have negotiation mechanism to agree on those parameters and we can use > them, we do not need to process things per packet basis. Are you saying that the next-header field is useless then? I mean the = code I've worked on parses the next header field on a per packet basis = to handle the inner packet payload. I'm not interested in trying to = redesign ESP with IPTFS, just use it as provided. Thanks, Chris. >=20 > [1] https://tools.ietf.org/html/draft-nikander-esp-beet-mode-09 > -- > kivinen@iki.fi >=20 --Apple-Mail=_9A5F94F1-B7A3-490F-AE2B-22C9DAE527C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+G0dsACgkQLh2DDte4 MCVFDg//eMcll8EuRjXmU0DlYAKdKzMXtKAAdBZMMwpdmaZRFnAwDJKkeWyfcl3p Lc+W5dcWSVUrZxpGJ07TCzchQZuXAT0sv/zS6dbEpfODvKxjBhmjffgrz3YsHDOl tp8dbo6XkOznokssOp0WsMYAKoN9ULFJY09Yhdec2EzAtaLcfVUFm4mf9KWOjc6F 8gWhHERU66dVKFZ5TrmMxJqmfW1WSLGn5JhAQbnsOQSnI1bsLobB6BvVLnB/RQUq 396ExbqIYu8mdKOnbvRYLy7pxNkJ/7+NYySS1LkFRv9bNZbs+lH3qs0WArtwDQcX T9FxEw8F0Ersk56aU50Ntp9goL7ZtC9HGzoJ8K17qhU1K63LVxzBPn1Ae1IjdJk9 ch2QaoPyPtN4klxImHwJUrdXk9KeQ2lZDTwLe8g6nBhZXquJen2247gaeoWgzedA uxaBJ3fq+0NeZnc5P9/3p0dYfOXWrTpRgPLXJ0et90fz+BzRTlFUWpDG6eGUJksD mrQeMxZp8sGeK6yl0LS6nc7YhMjsAdYqQW+EycPzlOCnwmR6e+CxXpUVSVdVoZDO WnITqvMVaaKqu2knabAKA77CiiKTZMiVkM/vz6hvYgUUmO9Cf7QM8SxdiXoo6x1v Oy4CzfUo7/pSuKBZxTTmEmaUfbRzG6xI3VXsqhHbuVvGsEnHfN4= =aH4I -----END PGP SIGNATURE----- --Apple-Mail=_9A5F94F1-B7A3-490F-AE2B-22C9DAE527C9-- From nobody Wed Oct 14 07:51:33 2020 Return-Path: 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 8C3EF3A0E29 for ; Wed, 14 Oct 2020 07:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 mt9xwqR6ey1U for ; Wed, 14 Oct 2020 07:51:29 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 A742A3A0E45 for ; Wed, 14 Oct 2020 07:49:14 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id B10BA1E060F for ; Wed, 14 Oct 2020 08:49:12 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id Si5YkiwTadCH5Si5YkuHor; Wed, 14 Oct 2020 08:49:12 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=NdjIKVL4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=afefHYAZSVUA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=AjG9MtBHgAGiWem3SMQA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=pGLkceISAAAA:8 a=xe610qPyDcbJwOUBkC0A:9 a=NNG6SpUl1BcQgYdV:21 a=UiCQ7L4-1S4A:10:nop_mshtml_css_classes a=hTZeC7Yk6K0A:10:nop_msword_html a=frz4AuCg-hUA:10:nop_css_in_html a=_W_S_7VecoQA:10:nop_html a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=wGy0PRV8A3OE5dSkPcbcnw+yIUc1NVMCggCvRDZuiJ0=; b=ri9ox2lvVrNjKP2Rp3WcYFOIgP vmzT+BRDJmbaHkHRt2Vi9C42WaXWg7xwTl8ftjdFpw0OwbSmv7YcdV8KoP7zYUV+4XalRov0z1Z3W 0/kCIdPqIf51/SuVqHQyZx2Dd; Received: from [127.0.0.1] (port=12481 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kSi5Y-003z1P-8W; Wed, 14 Oct 2020 08:49:12 -0600 To: Valery Smyslov , 'Christian Hopps' , ipsec@ietf.org Cc: ipsecme-chairs@ietf.org References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <1b3001d6a16e$6e614030$4b23c090$@gmail.com> <2af84d55-539a-cc37-5952-731d4d86473b@labn.net> <000c01d6a1f2$fd2ef940$f78cebc0$@gmail.com> From: Lou Berger Message-ID: <4f86068b-4b1d-ffb9-90ea-094982d18a83@labn.net> Date: Wed, 14 Oct 2020 10:49:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <000c01d6a1f2$fd2ef940$f78cebc0$@gmail.com> Content-Type: multipart/alternative; boundary="------------FC9813D062175C3C4B00E3C9" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1kSi5Y-003z1P-8W X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:12481 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 14:51:32 -0000 This is a multi-part message in MIME format. --------------FC9813D062175C3C4B00E3C9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Valery.  Based on the subsequent discussions, I suspect it may be best to just drop the whole section/capability.  So much for postel's law... Lou On 10/14/2020 2:26 AM, Valery Smyslov wrote: > > Hi Lou, > > Valery, > > >    If IKE is used to negotiate using IP-TFS, then such switching > MUST NOT take place. > > I read this added line as saying you can switch from tunnel to TFS, I > think you mean that use of TFS is controlled via IKE.  How about? > >    If IKE is used to negotiate using IP-TFS, then use of >    TFS is controlled per Section 5.1. >               I think the text is still a bit ambiguous,  since > previous sentence uses a normative SHOULD >               to support switching from tunnel to IPTFS and the > proposed text doesn’t forbid this >               behavior explicitly if IKE is used. I’d like to see more > explicit language for IKE case. >               How about: >    If IKE is used to negotiate using IP-TFS, then use of >    TFS is controlled per Section 5.1, and thus the option of switching >    to IP-TFS receive-side operation on receipt of the first IP-TFS payload >    MUST NOT be used. >               Feel free to change the text keeping its sense... >               Regards, >               Valery. > > Lou > > On 10/13/2020 10:37 AM, Valery Smyslov wrote: > > Valery, > > How about this: > > OLD >    Receive-side operation of IP-TFS does not require any per-SA >    configuration on the receiver; as such, an IP-TFS implementation >    SHOULD support the option of switching to IP-TFS receive-side >    operation on receipt of the first IP-TFS payload. > > NEW >    Receive-side operation of IP-TFS does not require any per-SA >    configuration on the receiver; as such, for tunnels created >    without IKE, an IP-TFS implementation >    SHOULD support the option of switching to IP-TFS receive-side >    operation on receipt of the first IP-TFS payload for tunnels. > > I can live with MAY, but would prefer SHOULD. > > Does this work for you? > > Yes, with the following addition. > >    Receive-side operation of IP-TFS does not require any per-SA > >    configuration on the receiver; as such, for tunnels created > >    without IKE, an IP-TFS implementation > >    SHOULD support the option of switching to IP-TFS receive-side > >    operation on receipt of the first IP-TFS payload for tunnels. > >    If IKE is used to negotiate using IP-TFS, then such switching > >    MUST NOT take place. > >               With this addition I don’t mind having SHOULD for > ike-less case. > >               Regards, > >               Valery. > > Lou > > On 10/13/2020 10:06 AM, Valery Smyslov wrote: > > I can live with MAY. > > OK, but it must be negotiable in any case if you plan to use it with IKE. > > Otherwise we'll get black holes. > > > > On 10/13/2020 9:16 AM, Valery Smyslov wrote: > > If you badly need this feature, then please make it MAY and negotiable, > > so that people can ignore it. SHOULD is too strong for it, > > leaving it non-negotiable is just unacceptable, IMHO. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > --------------FC9813D062175C3C4B00E3C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks Valery.  Based on the subsequent discussions, I suspect it may be best to just drop the whole section/capability.  So much for postel's law...

Lou

On 10/14/2020 2:26 AM, Valery Smyslov wrote:

Hi Lou,

Valery,

>    If IKE is used to negotiate using IP-TFS, then such switching MUST NOT take place.

I read this added line as saying you can switch from tunnel to TFS, I think you mean that use of TFS is controlled via IKE.  How about?

   If IKE is used to negotiate using IP-TFS, then use of
   TFS is controlled per Section 5.1.
 
              I think the text is still a bit ambiguous,  since previous sentence uses a normative SHOULD
              to support switching from tunnel to IPTFS and the proposed text doesn’t forbid this
              behavior explicitly if IKE is used. I’d like to see more explicit language for IKE case.
              How about:
 
   If IKE is used to negotiate using IP-TFS, then use of
   TFS is controlled per Section 5.1, and thus the option of switching
   to IP-TFS receive-side operation on receipt of the first IP-TFS payload
   MUST NOT be used.
 
              Feel free to change the text keeping its sense...
 
              Regards,
              Valery.

Lou

On 10/13/2020 10:37 AM, Valery Smyslov wrote:

Valery,

How about this:

OLD
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload.

NEW
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, for tunnels created
   without IKE, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload for tunnels.

I can live with MAY, but would prefer SHOULD.

 

 
Does this work for you?
 
              Yes, with the following addition.
 
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, for tunnels created 
   without IKE, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload for tunnels.
   If IKE is used to negotiate using IP-TFS, then such switching
   MUST NOT take place.
 
              With this addition I don’t mind having SHOULD for ike-less case.
 
              Regards,
              Valery.
 

 

 

             
Lou
 

On 10/13/2020 10:06 AM, Valery Smyslov wrote:

I can live with MAY.
 
OK, but it must be negotiable in any case if you plan to use it with IKE.
Otherwise we'll get black holes.
 
On 10/13/2020 9:16 AM, Valery Smyslov wrote:
If you badly need this feature, then please make it MAY and negotiable,
so that people can ignore it. SHOULD is too strong for it,
leaving it non-negotiable is just unacceptable, IMHO.
 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
 



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--------------FC9813D062175C3C4B00E3C9-- From nobody Wed Oct 14 12:00:07 2020 Return-Path: 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 EBFFB3A10F7 for ; Wed, 14 Oct 2020 11:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7jhqC6Di0H6T for ; Wed, 14 Oct 2020 11:59:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAF23A1071 for ; Wed, 14 Oct 2020 11:59:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7ECE1389B6; Wed, 14 Oct 2020 15:05:04 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C1urqODtPJgp; Wed, 14 Oct 2020 15:05:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 73901389B5; Wed, 14 Oct 2020 15:05:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 429146F5; Wed, 14 Oct 2020 14:59:11 -0400 (EDT) From: Michael Richardson To: Christian Hopps , ipsec@ietf.org In-Reply-To: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 19:00:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Hopps wrote: > I really don't understand the extreme back pressure against using ESP > the way it was designed. The next-header field is supposed to identify > the payload, it does so for every other payload ESP carries. Any other > solution to somehow infer the payload type some other way *has* to be > seen as a hack. Why do we need a hack? I don't understand either. Can we just let these guys get on with their work? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+HSn4ACgkQgItw+93Q 3WVOSwf/eXms0Cpw+ATbmHrHLhUEoG4udG9K6ohnPMAYdDR/XQC+nMxdmG9DaH9g aeUMIJEYFpE/wKZ3W31306G6OK1Q/y2ZL5QTeUh0d/LdzKJmcMsT0NcmLBbWb5Ko YBcuwYxdrzKMAT04hQSCLntilz+mj455EZuYOlACScBcBqAMnGjlFjc3VJTuokgE gsRzPvR8g8nV8JrKPkdmhGHcLRDTdvSmdm9qyQty3Fl86wGP2xvigSzHWebopR7G JuaV38zNGuDxIwy4qXON7CAnN44bIazsZfav1W9EWNUvEG+WeiRzvXvYSF/fZIUo QtlrFPEoUtwOQNnyeIzt+eQcBfvpGQ== =752c -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 15 00:13:04 2020 Return-Path: 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 F11473A1323; Thu, 15 Oct 2020 00:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 KEa1359Mkzgi; Thu, 15 Oct 2020 00:12:54 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.178]) (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 B517F3A131A; Thu, 15 Oct 2020 00:12:53 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx02.puc.rediris.es with ESMTP id 09F7Cd7H003315-09F7Cd7I003315; Thu, 15 Oct 2020 09:12:39 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id AF008202AF; Thu, 15 Oct 2020 09:12:39 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8_NZFiH63X1F; Thu, 15 Oct 2020 09:12:39 +0200 (CEST) Received: from [192.168.1.33] (135.red-79-150-250.dynamicip.rima-tde.net [79.150.250.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id DF937201D7; Thu, 15 Oct 2020 09:12:33 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <1142B610-2D58-4DE5-96F7-773D02C1B42A@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_372870A4-A581-4A53-8C03-2CCC4A3A7F5C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 15 Oct 2020 09:12:32 +0200 In-Reply-To: <7C422A91-5543-41A0-B907-6AAD9F83E6DA@chopps.org> Cc: Rafa Marin-Lopez , "last-call@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "i2nsf@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "yang-doctors@ietf.org" , Lou Berger , Fernando Pereniguez-Garcia To: Christian Hopps , "Rob Wilton (rwilton)" References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> <10116C35-8FBF-4914-9846-883D2C7F7A11@chopps.org> <7C422A91-5543-41A0-B907-6AAD9F83E6DA@chopps.org> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=rafa@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM, 2:15:1:upct.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=c0sJhzBv7Ffkj7pK4oNyxSyXmgL89HH3UIdpJBJmHRE=; b=WgC4VAxmJ4208E9ukUk1v5CnfyiSuIWOXR64wSfuD9QhmQ8ep7DuwcbxEup0m5lpRoRuSFEjd4FM CpCN1az83i/ffpGflnqQ0CIOoE2vUPSck3DRO+YhLeYTmrWXO+T7YpWaglVgvBAC36iJCW//MdNV QIFQMKzaXMcKzfNtu3b552J9DfgRNRe7QB+S3Ok5UBviKtfQalfvrOQcqj/3+34c0SnAVLB/xfz8 3NHYT4PREbM6feY6ckmWMvDC2CV8vF3CB3bYQK8D694iuqC+wOsUsfTAfvTnMSbUb8wNLznx0TT4 wz0lcB5Lr+ez+V0MA7Y3+NgaUlA5x2x7m/fgpw== Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 07:12:57 -0000 --Apple-Mail=_372870A4-A581-4A53-8C03-2CCC4A3A7F5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christian (,Rob): Thanks again for this conversation. Please see our comments inline. >>=20 >> As a consequence, the resolution was to move forward with a pragmatic = approach at this point of time, by changing the names of the modules = (and prefixes) to refer to the I2NSF work. >=20 > These are 2 different things. The original discussion was about moving = the SAD and SPD from ikeless module to the common one which then would = have brought them into the IKE module, and required people just = implementing IKE to also implement the SAD and SPD parts. >=20 > In comparison this new compromise request is a tiny change, and allows = a much larger audience to reap the benefit of your work. The change is = the addition of "feature ikeless-notification" and then putting the "if = ikeless-notification" under the notifications. >=20 > This doesn't change the semantics of your module it just allows people = to re-use the ikeless module for supporting SAD and SPD w/o implementing = the notifications. >=20 > If you feel more clarity is needed for the SDN use-case then adding = the text, "To allow for greater re-use of this module, the notifications = are marked as a feature. For the SDN use case clients will expect this = feature to be implemented.=E2=80=9D We agree that this is a small change (if no other change is required). = In fact, we have tested it and we have not observed any technical = problem. The main concern is the one I mentioned to Rob: having a = feature to =E2=80=9Cactivate=E2=80=9D notifications (or not) in the = ikeless module does not fit in the context of this I-D, unless we find = out a valid use case where this feature makes sense.=20 In other words, it would be really nice if the inclusion of the text you = proposed (=E2=80=9CTo allow for greater=E2=80=A6=E2=80=9D ) had a main = text to support how this is useful in the context of this I-D. = Personally, this would make me feel more confortable.=20 Having said all this, let us inform about v09 changes to I2NSF wg and = ask about this new change in order to see if there is any objection. = Then, if there is no objection we can prepare v10 very quickly with this = additional modification. We hope this is reasonable. Best Regards. >=20 > Features are reported just as modules are in the capabilities. An SDN = client would look for both capabilities rather than just the one (along = with all the other capabilities they will be looking for to actually be = a functional YANG client). >=20 > Thanks, > Chris. >=20 >>=20 >> Best Regards. >>=20 >>>=20 >>> Thanks, >>> Chris. >>>=20 >>>>=20 >>>> Hope this helps. >>>>=20 >>>> Best Regards. >>>>=20 >>>>> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) = > escribi=C3=B3: >>>>>=20 >>>>> Hi Rafa, authors, >>>>> =20 >>>>> Just to check. >>>>> =20 >>>>> Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as a feature"? This would = seem to be a fairly cheap & easy compromise. >>>>> =20 >>>>> Thanks, >>>>> Rob >>>>> =20 >>>>> =20 >>>>> From: yang-doctors > On Behalf Of Lou Berger >>>>> Sent: 27 September 2020 15:26 >>>>> To: Christian Hopps >; Martin Bj=C3=B6rklund > >>>>> Cc: Robert Wilton >; i2nsf@ietf.org = ; Gabriel Lopez >; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org = ; = ipsec@ietf.org ; last-call@ietf.org = ; Rafa Marin-Lopez >; yang-doctors@ietf.org = >>>>> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] = Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>>>> =20 >>>>> This is a sub-optimal compromise b/c all IPsec have SA databases = even ones running IKE -- i.e., SA databases are common whether exposed = in YANG or not -- but if it can move it forward perhaps good enough. >>>>>=20 >>>>>=20 >>>>> Speaking as an interested party, I hope that some compromise / = good enough solution is followed in the -09 version of this draft. >>>>> Lou >>>>>=20 >>>>> On 9/23/2020 7:20 AM, Christian Hopps wrote: >>>>> =20 >>>>>=20 >>>>>=20 >>>>> On Sep 23, 2020, at 6:58 AM, Martin Bj=C3=B6rklund = > wrote: >>>>> =20 >>>>> Hi, >>>>>=20 >>>>> Christian Hopps > = wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> But I would like to check: My understanding is that the changes = that >>>>> Chris is proposing are pretty small. I.e. move the SA structure = under >>>>> ipsec-common, and put it under a YANG feature. Are you sure that = it >>>>> is impractical to accommodate this change which would allow a = single >>>>> ipsec module to be shared and extended via YANG augmentations? >>>>>=20 >>>>>=20 >>>>> In the context of our I-D, if we move SAD structure to = ipsec-common, >>>>> what we are meaning is that IPsec SA configuration data (setting >>>>> values to the SAD structure) are common to the IKE case and the >>>>> IKE-less cases, which are not. It is confusing. >>>>>=20 >>>>> Something defined in a common module but marked as a feature does = not >>>>> imply that that feature has to be implemented by an importing >>>>> module. This is not confusing to YANG implementers or users I >>>>> think. If we are just talking about document flow here, then a >>>>> sentence saying "the SAD feature is not required to implement IKE >>>>> functionality" is quite enough to clear that up I think. >>>>>=20 >>>>> Another alternative could be to move these containers to another >>>>> (new) module. >>>>> =20 >>>>> It may also be enough to mark the notifications in the ikeless = module as a feature I suppose. That is the actual thing I think non-SDN = implementations would want to omit. The module name "ikeless" is not = great in this case, but perhaps workable. >>>>>=20 >>>>>=20 >>>>> This is a sub-optimal compromise b/c all IPsec have SA databases = even ones running IKE -- i.e., SA databases are common whether exposed = in YANG or not -- but if it can move it forward perhaps good enough. >>>>>=20 >>>>>=20 >>>>> I'm definitely concerned about IETF process and real world = usability here. These modules are basically workable for ipsec I think, = they could be used by operators today. If we restart the entire process = to redo this work for the more generic IPsec case it will probably be = years before they are finished and in the field. This new work can be = started, but why not have something usable in the meantime? >>>>> =20 >>>>> Thanks, >>>>> Chris. >>>>> =20 >>>>>=20 >>>>>=20 >>>>> /martin >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Chris. >>>>>=20 >>>>>=20 >>>>> Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is >>>>> not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and IKE-less. = Again, it seems >>>>> confusing. In the IKE case, the SDN/I2NSF controller does not >>>>> configure the SAD at all but the IKE implementation in the NSF. In = our >>>>> opinion, in order to properly add this IPsec SA operational state = to >>>>> the IKE case we should include operational data about the IPsec = SAs >>>>> (config false) to the ietf-ipsec-ike. Alternatively, we have = certain >>>>> operational data (ro) in the SAD structure in the IKE-less case. = If >>>>> only those are moved to the common part should be ok but we think = it >>>>> does not solve the problem. >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> last-call mailing list >>>>> last-call@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/last-call = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec = _____________________________= __________________ >>>>> I2nsf mailing list >>>>> I2nsf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2nsf = >>>> ------------------------------------------------------- >>>> Rafa Marin-Lopez, PhD >>>> Dept. Information and Communications Engineering (DIIC) >>>> Faculty of Computer Science-University of Murcia >>>> 30100 Murcia - Spain >>>> Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = >>>> ------------------------------------------------------- >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec = >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf = >> ------------------------------------------------------- >> Rafa Marin-Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_372870A4-A581-4A53-8C03-2CCC4A3A7F5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Christian (,Rob):

Thanks again for this conversation. Please see our comments = inline.


As a consequence, the resolution was to = move forward with a pragmatic approach at this point of time, by = changing the names of the modules (and prefixes) to refer to the I2NSF = work.

These are 2 different things. The = original discussion was about moving the SAD and SPD from ikeless module = to the common one which then would have brought them into the IKE = module, and required people just implementing IKE to also implement the = SAD and SPD parts.

In comparison this new compromise request is a tiny change, = and allows a much larger audience to reap the benefit of your work. The = change is the addition of "feature ikeless-notification" and then = putting the "if ikeless-notification" under the = notifications.

This doesn't change the semantics of = your module it just allows people to re-use the ikeless module for = supporting SAD and SPD w/o implementing the notifications.

If you feel more clarity = is needed for the SDN use-case then adding the text, "To allow for = greater re-use of this module, the notifications are marked as a = feature. For the SDN use case clients will expect this feature to be = implemented.=E2=80=9D

We agree that this is a small change (if no = other change is required). In fact, we have tested it and we have not = observed any technical problem. The main concern is the one I mentioned = to Rob: having a feature to =E2=80=9Cactivate=E2=80=9D notifications (or = not) in the ikeless module does not fit in the context of this I-D, = unless we find out a valid use case where this feature makes = sense. 

In other words, it = would be really nice if the inclusion of the text you proposed (=E2=80=9CT= o allow for greater=E2=80=A6=E2=80=9D ) had a main text to support how = this is useful in the context of this I-D. Personally, this would make = me feel more confortable. 

Having said all this, let us inform about = v09 changes to I2NSF wg and ask about this new change in order to see if = there is any objection. Then, if there is no objection we can prepare = v10 very quickly with this additional modification.

We hope this is reasonable.

Best Regards.

Features are reported just as modules are in the = capabilities. An SDN client would look for both capabilities rather than = just the one (along with all the other capabilities they will be looking = for to actually be a functional YANG client).

Thanks,
Chris.


Best = Regards.


Thanks,
Chris.


Hope this helps.

Best Regards.

El 12 = oct 2020, a las 18:01, Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> = escribi=C3=B3:

Hi Rafa, authors,
 
Just to check.
 
Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as = a feature"?  This would seem to be a fairly cheap & easy = compromise.
 
Thanks,
Rob
 
 
From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf = Of Lou Berger
Sent: 27 September 2020 15:26
To: Christian Hopps <chopps@chopps.org>; = Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton=3D40cisco.com@dmarc.ietf.org>; i2nsf@ietf.org; Gabriel = Lopez <gabilm@um.es>; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; = Rafa Marin-Lopez <rafa@um.es>; yang-doctors@ietf.org
Subject: Re: [yang-doctors] [IPsec] = [Last-Call] [I2nsf] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
 
This is a = sub-optimal compromise b/c all IPsec have SA databases even ones running = IKE -- i.e., SA databases are common whether exposed in YANG or not -- = but if it can move it forward perhaps good enough.


Speaking as an = interested party, I hope that some compromise / good enough solution is = followed in the -09 version of  this draft.

Lou

On 9/23/2020 7:20 AM, Christian Hopps = wrote:
 


On Sep 23, = 2020, at 6:58 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> wrote:
 
Hi,

Christian Hopps = <chopps@chopps.org> wrote:




On Sep = 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es> wrote:




But I would like to = check: My understanding is that the changes that
Chris is = proposing are pretty small.  I.e. move the SA structure under
ipsec-common, and put it under a YANG feature.  Are you = sure that it
is impractical to accommodate this change = which would allow a single
ipsec module to be shared and = extended via YANG augmentations?


In the context of = our I-D, if we move SAD structure to ipsec-common,
what we = are meaning is that IPsec SA configuration data (setting
values to the SAD structure) are common to the IKE case and = the
IKE-less cases, which are not. It is confusing.

Something defined in a common = module but marked as a feature does not
imply that that = feature has to be implemented by an importing
module. This = is not confusing to YANG implementers or users I
think. If = we are just talking about document flow here, then a
sentence saying "the SAD feature is not required to implement = IKE
functionality" is quite enough to clear that up I = think.

Another alternative could be to = move these containers to another
(new) module.
 
It may also be enough to mark the = notifications in the ikeless module as a feature I suppose. That is the = actual thing I think non-SDN implementations would want to omit. The = module name "ikeless" is not great in this case, but perhaps = workable.


This is a sub-optimal compromise b/c all = IPsec have SA databases even ones running IKE -- i.e., SA databases are = common whether exposed in YANG or not -- but if it can move it forward = perhaps good enough.


I'm definitely concerned about IETF = process and real world usability here. These modules are basically = workable for ipsec I think, they could be used by operators today. If we = restart the entire process to redo this work for the more generic IPsec = case it will probably be years before they are finished and in the = field. This new work can be started, but why not have something usable = in the meantime?
 
Thanks,
Chris.
 


/martin





Thanks,
Chris.


Moreover, the usage of feature means that, after = all, this =E2=80=9Ccommon=E2=80=9D is
not =E2=80=9Ccommon=E2= =80=9D to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does = not
configure the SAD at all but the IKE implementation in = the NSF. In our
opinion, in order to properly add this = IPsec SA operational state to
the IKE case we should = include operational data about the IPsec SAs
(config = false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less = case. If
only those are moved to the common part should be = ok but we think it
does not solve the problem.

 
-- 
last-call = mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_372870A4-A581-4A53-8C03-2CCC4A3A7F5C-- From nobody Thu Oct 15 03:48:41 2020 Return-Path: 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 9C7A73A1370; Thu, 15 Oct 2020 03:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DePdojSIs790; Thu, 15 Oct 2020 03:48:31 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3CE3A11D1; Thu, 15 Oct 2020 03:48:30 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 624F26166F; Thu, 15 Oct 2020 10:48:27 +0000 (UTC) From: Christian Hopps Message-Id: <0492AF3E-7A7D-4853-84CE-C13155F3E4D9@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_71DD0E65-CAB8-4BA2-A065-0E5B1AC62BF0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 15 Oct 2020 06:48:26 -0400 In-Reply-To: <1142B610-2D58-4DE5-96F7-773D02C1B42A@um.es> Cc: Christian Hopps , "Rob Wilton (rwilton)" , "last-call@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "i2nsf@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "yang-doctors@ietf.org" , Lou Berger , Fernando Pereniguez-Garcia To: Rafa Marin-Lopez References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> <10116C35-8FBF-4914-9846-883D2C7F7A11@chopps.org> <7C422A91-5543-41A0-B907-6AAD9F83E6DA@chopps.org> <1142B610-2D58-4DE5-96F7-773D02C1B42A@um.es> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 10:48:34 -0000 --Apple-Mail=_71DD0E65-CAB8-4BA2-A065-0E5B1AC62BF0 Content-Type: multipart/alternative; boundary="Apple-Mail=_90E89900-8AF2-4D6D-A86C-349952FD86D1" --Apple-Mail=_90E89900-8AF2-4D6D-A86C-349952FD86D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is great news, Thanks! IMO (Rob feel free to chime in here :) I don't think you need to say = anything more about the feature in your document (other than what was = already mentioned). This is the standard "outside the scope of this = document" kind of thing. It's enough to put that text that says they are = marked as a feature for greater re-usability, but SDN clients will = expect the feature to be implemented. FWIW, When talking about YANG features I'd use the turn of phrase "to = indicate whether notifications are implemented by the server" rather = than 'to "activate" notifications'. They don't get turned on or off, = they are either implemented or not. You could swap "implemented" with = "supported" too here with the same meaning. Thanks, Chris. > On Oct 15, 2020, at 3:12 AM, Rafa Marin-Lopez wrote: >=20 > Hi Christian (,Rob): >=20 > Thanks again for this conversation. Please see our comments inline. >=20 >>>=20 >>> As a consequence, the resolution was to move forward with a = pragmatic approach at this point of time, by changing the names of the = modules (and prefixes) to refer to the I2NSF work. >>=20 >> These are 2 different things. The original discussion was about = moving the SAD and SPD from ikeless module to the common one which then = would have brought them into the IKE module, and required people just = implementing IKE to also implement the SAD and SPD parts. >>=20 >> In comparison this new compromise request is a tiny change, and = allows a much larger audience to reap the benefit of your work. The = change is the addition of "feature ikeless-notification" and then = putting the "if ikeless-notification" under the notifications. >>=20 >> This doesn't change the semantics of your module it just allows = people to re-use the ikeless module for supporting SAD and SPD w/o = implementing the notifications. >>=20 >> If you feel more clarity is needed for the SDN use-case then adding = the text, "To allow for greater re-use of this module, the notifications = are marked as a feature. For the SDN use case clients will expect this = feature to be implemented.=E2=80=9D >=20 > We agree that this is a small change (if no other change is required). = In fact, we have tested it and we have not observed any technical = problem. The main concern is the one I mentioned to Rob: having a = feature to =E2=80=9Cactivate=E2=80=9D notifications (or not) in the = ikeless module does not fit in the context of this I-D, unless we find = out a valid use case where this feature makes sense. >=20 > In other words, it would be really nice if the inclusion of the text = you proposed (=E2=80=9CTo allow for greater=E2=80=A6=E2=80=9D ) had a = main text to support how this is useful in the context of this I-D. = Personally, this would make me feel more confortable. >=20 > Having said all this, let us inform about v09 changes to I2NSF wg and = ask about this new change in order to see if there is any objection. = Then, if there is no objection we can prepare v10 very quickly with this = additional modification. >=20 > We hope this is reasonable. >=20 > Best Regards. >>=20 >> Features are reported just as modules are in the capabilities. An SDN = client would look for both capabilities rather than just the one (along = with all the other capabilities they will be looking for to actually be = a functional YANG client). >>=20 >> Thanks, >> Chris. >>=20 >>>=20 >>> Best Regards. >>>=20 >>>>=20 >>>> Thanks, >>>> Chris. >>>>=20 >>>>>=20 >>>>> Hope this helps. >>>>>=20 >>>>> Best Regards. >>>>>=20 >>>>>> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) = > escribi=C3=B3: >>>>>>=20 >>>>>> Hi Rafa, authors, >>>>>>=20 >>>>>> Just to check. >>>>>>=20 >>>>>> Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as a feature"? This would = seem to be a fairly cheap & easy compromise. >>>>>>=20 >>>>>> Thanks, >>>>>> Rob >>>>>>=20 >>>>>>=20 >>>>>> From: yang-doctors > On Behalf Of Lou Berger >>>>>> Sent: 27 September 2020 15:26 >>>>>> To: Christian Hopps >; Martin Bj=C3=B6rklund > >>>>>> Cc: Robert Wilton >; i2nsf@ietf.org = ; Gabriel Lopez >; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org = ; = ipsec@ietf.org ; last-call@ietf.org = ; Rafa Marin-Lopez >; yang-doctors@ietf.org = >>>>>> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] = Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>>>>>=20 >>>>>> This is a sub-optimal compromise b/c all IPsec have SA databases = even ones running IKE -- i.e., SA databases are common whether exposed = in YANG or not -- but if it can move it forward perhaps good enough. >>>>>>=20 >>>>>>=20 >>>>>> Speaking as an interested party, I hope that some compromise / = good enough solution is followed in the -09 version of this draft. >>>>>> Lou >>>>>>=20 >>>>>> On 9/23/2020 7:20 AM, Christian Hopps wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Sep 23, 2020, at 6:58 AM, Martin Bj=C3=B6rklund = > wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Christian Hopps > = wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez > wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> But I would like to check: My understanding is that the changes = that >>>>>> Chris is proposing are pretty small. I.e. move the SA structure = under >>>>>> ipsec-common, and put it under a YANG feature. Are you sure that = it >>>>>> is impractical to accommodate this change which would allow a = single >>>>>> ipsec module to be shared and extended via YANG augmentations? >>>>>>=20 >>>>>>=20 >>>>>> In the context of our I-D, if we move SAD structure to = ipsec-common, >>>>>> what we are meaning is that IPsec SA configuration data (setting >>>>>> values to the SAD structure) are common to the IKE case and the >>>>>> IKE-less cases, which are not. It is confusing. >>>>>>=20 >>>>>> Something defined in a common module but marked as a feature does = not >>>>>> imply that that feature has to be implemented by an importing >>>>>> module. This is not confusing to YANG implementers or users I >>>>>> think. If we are just talking about document flow here, then a >>>>>> sentence saying "the SAD feature is not required to implement IKE >>>>>> functionality" is quite enough to clear that up I think. >>>>>>=20 >>>>>> Another alternative could be to move these containers to another >>>>>> (new) module. >>>>>>=20 >>>>>> It may also be enough to mark the notifications in the ikeless = module as a feature I suppose. That is the actual thing I think non-SDN = implementations would want to omit. The module name "ikeless" is not = great in this case, but perhaps workable. >>>>>>=20 >>>>>>=20 >>>>>> This is a sub-optimal compromise b/c all IPsec have SA databases = even ones running IKE -- i.e., SA databases are common whether exposed = in YANG or not -- but if it can move it forward perhaps good enough. >>>>>>=20 >>>>>>=20 >>>>>> I'm definitely concerned about IETF process and real world = usability here. These modules are basically workable for ipsec I think, = they could be used by operators today. If we restart the entire process = to redo this work for the more generic IPsec case it will probably be = years before they are finished and in the field. This new work can be = started, but why not have something usable in the meantime? >>>>>>=20 >>>>>> Thanks, >>>>>> Chris. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> /martin >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Chris. >>>>>>=20 >>>>>>=20 >>>>>> Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is >>>>>> not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and IKE-less. = Again, it seems >>>>>> confusing. In the IKE case, the SDN/I2NSF controller does not >>>>>> configure the SAD at all but the IKE implementation in the NSF. = In our >>>>>> opinion, in order to properly add this IPsec SA operational state = to >>>>>> the IKE case we should include operational data about the IPsec = SAs >>>>>> (config false) to the ietf-ipsec-ike. Alternatively, we have = certain >>>>>> operational data (ro) in the SAD structure in the IKE-less case. = If >>>>>> only those are moved to the common part should be ok but we think = it >>>>>> does not solve the problem. >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> last-call mailing list >>>>>> last-call@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/last-call = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> IPsec mailing list >>>>>> IPsec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipsec = _____________________________= __________________ >>>>>> I2nsf mailing list >>>>>> I2nsf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2nsf = >>>>> ------------------------------------------------------- >>>>> Rafa Marin-Lopez, PhD >>>>> Dept. Information and Communications Engineering (DIIC) >>>>> Faculty of Computer Science-University of Murcia >>>>> 30100 Murcia - Spain >>>>> Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = >>>>> ------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec = >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2nsf = >>> ------------------------------------------------------- >>> Rafa Marin-Lopez, PhD >>> Dept. Information and Communications Engineering (DIIC) >>> Faculty of Computer Science-University of Murcia >>> 30100 Murcia - Spain >>> Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = >>> ------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec = >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = > ------------------------------------------------------- > Rafa Marin-Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail:=C2=A0rafa@um.es = > ------------------------------------------------------- --Apple-Mail=_90E89900-8AF2-4D6D-A86C-349952FD86D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is great news, Thanks!

IMO (Rob feel free to chime in here :) I don't think you need = to say anything more about the feature in your document (other than what = was already mentioned). This is the standard "outside the scope of this = document" kind of thing. It's enough to put that text that says they are = marked as a feature for greater re-usability, but SDN clients will = expect the feature to be implemented.

FWIW, When talking about YANG features = I'd use the turn of phrase "to indicate whether notifications are = implemented by the server" rather than 'to "activate" notifications'. = They don't get turned on or off, they are either implemented or not. You = could swap "implemented" with "supported" too here with the same = meaning.

Thanks,
Chris.

On Oct = 15, 2020, at 3:12 AM, Rafa Marin-Lopez <rafa@um.es> wrote:

Hi Christian (,Rob):

Thanks again for this conversation. Please see = our comments inline.


As a consequence, the resolution was to move forward with a = pragmatic approach at this point of time, by changing the names of the = modules (and prefixes) to refer to the I2NSF = work.

These are 2 different things. The = original discussion was about moving the SAD and SPD from ikeless module = to the common one which then would have brought them into the IKE = module, and required people just implementing IKE to also implement the = SAD and SPD parts.

In comparison this new compromise request is a tiny change, = and allows a much larger audience to reap the benefit of your work. The = change is the addition of "feature ikeless-notification" and then = putting the "if ikeless-notification" under the = notifications.

This doesn't change the semantics of your module it just = allows people to re-use the ikeless module for supporting SAD and SPD = w/o implementing the notifications.

If you feel more clarity is needed for = the SDN use-case then adding the text, "To allow for greater re-use of = this module, the notifications are marked as a feature. For the SDN use = case clients will expect this feature to be = implemented.=E2=80=9D

We agree that this is a = small change (if no other change is required). In fact, we have tested = it and we have not observed any technical problem. The main concern is = the one I mentioned to Rob: having a feature to =E2=80=9Cactivate=E2=80=9D= notifications (or not) in the ikeless module does not fit in the = context of this I-D, unless we find out a valid use case where this = feature makes sense. 

In other words, it would be really nice if the inclusion of = the text you proposed (=E2=80=9CTo allow for greater=E2=80=A6=E2=80=9D ) = had a main text to support how this is useful in the context of this = I-D. Personally, this would make me feel more = confortable. 

Having said all this, let us inform about v09 changes to = I2NSF wg and ask about this new change in order to see if there is any = objection. Then, if there is no objection we can prepare v10 very = quickly with this additional modification.

We hope this is reasonable.

Best = Regards.

Features are reported just as modules are in the = capabilities. An SDN client would look for both capabilities rather than = just the one (along with all the other capabilities they will be looking = for to actually be a functional YANG client).

Thanks,
Chris.


Best Regards.


Thanks,
Chris.


Hope this helps.

Best Regards.

El 12 = oct 2020, a las 18:01, Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> = escribi=C3=B3:

Hi Rafa, authors,
 
Just to check.
 
Has there been any closure on the suggestion from Chris on = =E2=80=9Cnotifications in the ikeless module as = a feature"?  This would seem to be a fairly cheap & easy = compromise.
 
Thanks,
Rob
 
 
From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf = Of Lou Berger
Sent: 27 September 2020 15:26
To: Christian Hopps <chopps@chopps.org>; = Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton=3D40cisco.com@dmarc.ietf.org>; i2nsf@ietf.org; Gabriel = Lopez <gabilm@um.es>; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; = Rafa Marin-Lopez <rafa@um.es>; yang-doctors@ietf.org
Subject: Re: [yang-doctors] [IPsec] = [Last-Call] [I2nsf] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
 
This is a = sub-optimal compromise b/c all IPsec have SA databases even ones running = IKE -- i.e., SA databases are common whether exposed in YANG or not -- = but if it can move it forward perhaps good enough.


Speaking as an = interested party, I hope that some compromise / good enough solution is = followed in the -09 version of  this draft.

Lou

On 9/23/2020 7:20 AM, Christian Hopps = wrote:
 


On Sep 23, = 2020, at 6:58 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> wrote:
 
Hi,

Christian Hopps = <chopps@chopps.org> wrote:




On Sep = 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es> wrote:




But I would like to = check: My understanding is that the changes that
Chris is = proposing are pretty small.  I.e. move the SA structure under
ipsec-common, and put it under a YANG feature.  Are you = sure that it
is impractical to accommodate this change = which would allow a single
ipsec module to be shared and = extended via YANG augmentations?


In the context of = our I-D, if we move SAD structure to ipsec-common,
what we = are meaning is that IPsec SA configuration data (setting
values to the SAD structure) are common to the IKE case and = the
IKE-less cases, which are not. It is confusing.

Something defined in a common = module but marked as a feature does not
imply that that = feature has to be implemented by an importing
module. This = is not confusing to YANG implementers or users I
think. If = we are just talking about document flow here, then a
sentence saying "the SAD feature is not required to implement = IKE
functionality" is quite enough to clear that up I = think.

Another alternative could be to = move these containers to another
(new) module.
 
It may also be enough to mark the = notifications in the ikeless module as a feature I suppose. That is the = actual thing I think non-SDN implementations would want to omit. The = module name "ikeless" is not great in this case, but perhaps = workable.


This is a sub-optimal compromise b/c all = IPsec have SA databases even ones running IKE -- i.e., SA databases are = common whether exposed in YANG or not -- but if it can move it forward = perhaps good enough.


I'm definitely concerned about IETF = process and real world usability here. These modules are basically = workable for ipsec I think, they could be used by operators today. If we = restart the entire process to redo this work for the more generic IPsec = case it will probably be years before they are finished and in the = field. This new work can be started, but why not have something usable = in the meantime?
 
Thanks,
Chris.
 


/martin





Thanks,
Chris.


Moreover, the usage of feature means that, after = all, this =E2=80=9Ccommon=E2=80=9D is
not =E2=80=9Ccommon=E2= =80=9D to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does = not
configure the SAD at all but the IKE implementation in = the NSF. In our
opinion, in order to properly add this = IPsec SA operational state to
the IKE case we should = include operational data about the IPsec SAs
(config = false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less = case. If
only those are moved to the common part should be = ok but we think it
does not solve the problem.

 
-- 
last-call = mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 = Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------

= --Apple-Mail=_90E89900-8AF2-4D6D-A86C-349952FD86D1-- --Apple-Mail=_71DD0E65-CAB8-4BA2-A065-0E5B1AC62BF0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+IKPoACgkQLh2DDte4 MCUR6w//V4PS6XwYL/4I23q5Fx7hiUrwZ6LM6nSNixSQk43znrF2PjS1/14ChyhD PsevSjG+TPyeOPItJOX0XuXebTkaUYKpXJlKwailJS5+5wuQjHBSQfgajHJsVqb0 kJARqaIeUN2/Q3kggUFcNGnQ/7jX0BoGYZPCul0ZYlt2qpLwYpzb6TA/yUlT927s V1Cmb3LTYx5maBkCL08gH6ZPkfIRKL0Bp9fBMW5qXJ2Kjnms0Y96enmzlfygrhQ3 LGxBsWYywiqSCAucGDYyk/92MIRenSEBCtNkc0lUP1G/A1H0bID9y0PDetsNaCI8 0vsIxyhknr9JqNYlkj/82s5UHUaFFQM4lfRGPQLQCHC8acSn4HbHL023gthI9bN5 BeJH0wlTX87v6LsIOub7FjlhA7AS55CfmnFbmZQJbBVGdooI6wBaMHaT0koDpEcq z8ATxLmG7wVzJkhSQIaNrDqDdHkCLlPqtGexJW4eA2Y3X4TXZysYm81sKNbsoXhw l2Uu/Xcy/MhWEMUaDLkQQCvz87k20VMOf474c25v+TDJTztePgAcsZ5CtmLFM1tp ZpsBTGo7l3QkPTGLGgG9XWXjXJB+8enjwgnWL/uXze4jWE0KoL1++3rMbnyLLj5Z emJTxic2l/rBOH5jghS6H7+thNltE6AyYuY8hUvD2R9XvbWJ5Iw= =Tt+h -----END PGP SIGNATURE----- --Apple-Mail=_71DD0E65-CAB8-4BA2-A065-0E5B1AC62BF0-- From nobody Thu Oct 15 13:06:13 2020 Return-Path: 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 4D4D53A12E2 for ; Thu, 15 Oct 2020 13:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 o0T0ch_CWb9x for ; Thu, 15 Oct 2020 13:06:10 -0700 (PDT) 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 E68873A1125 for ; Thu, 15 Oct 2020 13:06:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CC0f72g9NzFBx; Thu, 15 Oct 2020 22:06:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1602792367; bh=iMqnrln/JeSuyFbiwXLkyckfHUQBYJq8bIARz39/aig=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=J8oummvGrk6YS71Wxl0bwklrdsQ2EKEY0el90x/NdUH6RGGuIFspArMpXZ+DBxUFx 1J9l0ym5OyTWz4WJXv+XzhO43vll6pGLMkRY/6qohTmj/YA8ebVrDXqyUWp4A25Rxy lFQ5q8IieGPhvqkqprWJlh7bIR6oNy46txelgbdg= 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 3eNYmFCpwf7r; Thu, 15 Oct 2020 22:06:05 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 15 Oct 2020 22:06:05 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 06D9C6029B99; Thu, 15 Oct 2020 16:06:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F2A4D8A8; Thu, 15 Oct 2020 16:06:03 -0400 (EDT) Date: Thu, 15 Oct 2020 16:06:03 -0400 (EDT) From: Paul Wouters To: Christian Hopps cc: Tero Kivinen , ipsec@ietf.org, Valery Smyslov , Lou Berger In-Reply-To: Message-ID: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:06:11 -0000 On Wed, 14 Oct 2020, Christian Hopps wrote: > I really don't understand the extreme back pressure against using ESP the way it was designed. The next-header field is supposed to identify the payload, it does so for every other > payload ESP carries. Any other solution to somehow infer the payload type some other way *has* to be seen as a hack. Why do we need a hack? > > The fact that using a payload identifier the way ESP intended also allows us to do things like handle receipt of said payload without extra configuration, or use the payload outside > of ESP are just benefits from good design, they aren't indicative of doing something incorrectly, the opposite in fact. They also shouldn't even be needed to justify using ESP the > way it was designed to be used. > > This is all very strange to me, this want to not use the next-header field to, you know, identify the next header. I see it as a useful feature that I can "enable" IPTFS on my existing IPsec connection dynamically. Perhaps to avoid always sending traffic when I have none, and mostly wanting my decoy traffic when I am doing things (like typing over ssh, sending an email, etc) I don't see how this would happen "automatically". It would be a user invoked event. Based on that, userland has to somehow trigger to kernel to switch from regular ESP to IPTFS. We would need to define that (eg via Netlink or PF_KEY). But why not use a NOTIFY with a REKEY event to USE_IPTFS ? No need for new PF_KEY/netlink messages, no new userland <-> kernel signaling. Just use existing implemented IKE/IPsec protocols. So I think I agree with Valery (and Tero). It is not really about what the ESP packet format can or cannot do, but using existing channels for on-the-fly reconfiguration. It would work the same as if you wanted to switch a transport mode to tunnel mode or IPCOMP, rekey with(out) USE_TRANSPORT or USE_IPCOMP. Paul From nobody Thu Oct 15 13:06:58 2020 Return-Path: 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 67C593A133F for ; Thu, 15 Oct 2020 13:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 OkY-ISTRcsTx for ; Thu, 15 Oct 2020 13:06:54 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 AD1063A1125 for ; Thu, 15 Oct 2020 13:06:53 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id B1ACA20305; Thu, 15 Oct 2020 23:06:50 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1602792410; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UDuBzqsw8Jv9UwJdxqTtAu26YgaLDrLdcc8XwJvFIkc=; b=PFAp51BxjhQyly4Eoy5TaR/3Zk/aU2z0HvdtCUaKQOFxdVYlEIkTVN2VV0QSzL9VmXiTQd Uq/bRPHX/hUy1EJqXWk81zDBEve39VAYZUA43MYPAb47mZBOKyxtlCXBaisPyTShOmJMH4 0CAqYggvyYhoeQAarKaN0wcPq6wY3OY= Received: by fireball.acr.fi (Postfix, from userid 15204) id B4ABE25C0E1C; Thu, 15 Oct 2020 23:06:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24456.43991.701332.956314@fireball.acr.fi> Date: Thu, 15 Oct 2020 23:06:47 +0300 From: Tero Kivinen To: Christian Hopps Cc: Valery Smyslov , Lou Berger , ipsec@ietf.org In-Reply-To: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 37 min X-Total-Time: 63 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1602792410; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UDuBzqsw8Jv9UwJdxqTtAu26YgaLDrLdcc8XwJvFIkc=; b=DVdYVqDIQjiyyhPCasYC6zS3HUmtCtU2E+YyjHYpn8+YIm6BwGY/Bpqdn35P95sHXKiM9L 8cuLCYOf7lAO5M9Iag3FjQwCpKg3agL/M3RdhG+XJAj4OFC38uTqnsSEcdWSKI9ZIPVy3s p+cKN6/Xyr8TWqRbYF/S3ASUv/xXtC8= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1602792410; a=rsa-sha256; cv=none; b=KZd64p1wNmMReI20O0GYz3m/LIMk7/jizbLBJ3xTdedUmOf5Q8mYfFA4R4/Or8NDGlZJEU 1jCSMyyuwXU66XPZDznn/hwN6kxBK601rhCv2rN/86AEQfGoPvhDb2yyqttZn0may5NLoq llGwonCeWJhhBBiga/aPJf3gvaAThgM= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:06:57 -0000 Christian Hopps writes: > I really don't understand the extreme back pressure against using > ESP the way it was designed. The next-header field is supposed to > identify the payload, it does so for every other payload ESP > carries. Any other solution to somehow infer the payload type some > other way *has* to be seen as a hack. Why do we need a hack? Because the next-header field identifies the protocol DEFINED ELSEWHERE that ESP moves around. If we want to make modifications to the TCP protocol, and want to allocate new Protocol Number for it, we do not that in IPsecME WG even when that new version of TCP could be transmitted over IPsec also. When ESPv3 (RFC4303) added new features like support for combined mode algorithms we did not allocate new protocol number for that. We decided that we use IKE to identify whether Child SA negotiates anything that requires ESPv3, and if so then ESPv3 packet format is used, otherwise ESPv2 (RFC2406) is used. So the basic idea is that IPsec and ESP is transporting protocols defined elsewhere. That does not mean that content of the ESP protocol can't change, we "own" the ESP format, so we can change it in any ways we seem needed, and we can negotiate things using IKE to specify the format specific Child SA is using. Now if you are trying to define completely new protocol for generic IP use, and because it can also be used in the IPsec, you want to standarize that in the IPsecME WG, I do not think that belongs to the IPsecME charter. If this protocol is really going to be general use encapsulation protocol then it needs to be specified somewhere else (most likely in different Area than security). If this is not general use, but just optimization where we can put multiple IP packets inside one ESP packet to provide traffic flow security, then we can negotiate that in IKE, and we do not need extra protocol number for it, and we can do it here. I am still unclear which one of those protocols you are trying to define? > The fact that using a payload identifier the way ESP intended also > allows us to do things like handle receipt of said payload without > extra configuration, or use the payload outside of ESP are just > benefits from good design, they aren't indicative of doing something > incorrectly, the opposite in fact. They also shouldn't even be > needed to justify using ESP the way it was designed to be used. So then this belongs to different area, as it does not have any real connection to IPsec, it just one of the protocols we can encapsulate in ESP. Also now when I actually checked you draft, I noticed that it has some congestion control things in it too, and that is something that do require very careful checking by other areas. > This is all very strange to me, this want to not use the next-header > field to, you know, identify the next header. As I said that is fine by me if it is protocol defined outside the IPsecME. I just do not think it belongs to the IPsecME to define new internet protocol encapsulating multiple IP packets in, and fragmenting them, and doing congestion control on them. Our main charter says: Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. meaning we work for ESP and IKEv2, not for making new generic IP protocols. Also the TFC section of charter says: The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. Which I did understood that we still work by modifying the ESP protocol and that we do not define new generic protocols for encapsulating IP packets and transport that inside ESP (which would not need any changes to the ESP or IKE, as we already have a way of negotiating the traffic selectors for any IP protocol we want to tranport inside ESP). Of course there would be some security implications for such protocol as you would need to specify exit tunnel checks for those packets coming out from the new protocol, which is why I think it is better done by modifying ESP. -- kivinen@iki.fi From nobody Thu Oct 15 13:12:47 2020 Return-Path: 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 716293A1343 for ; Thu, 15 Oct 2020 13:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uN2vxrK_EXH2 for ; Thu, 15 Oct 2020 13:12:41 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 03BC23A133A for ; Thu, 15 Oct 2020 13:12:40 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 6D1DA61676; Thu, 15 Oct 2020 20:12:38 +0000 (UTC) From: Christian Hopps Message-Id: <801025DB-8496-49E3-B628-2CE1F4EF8F53@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_7E6D459D-F491-40A9-BA85-4335A30764C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 15 Oct 2020 16:12:37 -0400 In-Reply-To: Cc: Christian Hopps , Tero Kivinen , ipsec@ietf.org, Valery Smyslov , Lou Berger To: Paul Wouters References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:12:45 -0000 --Apple-Mail=_7E6D459D-F491-40A9-BA85-4335A30764C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Paul, My comment was only about using the next header field in ESP to identify = the ESP payload. I believe we've already agreed to remove the zero-conf = section as too controversial. Tero, is suggesting that we should not use the next header field at all. = That is what I don't understand. Thanks, Chris. > On Oct 15, 2020, at 4:06 PM, Paul Wouters wrote: >=20 > On Wed, 14 Oct 2020, Christian Hopps wrote: >=20 >> I really don't understand the extreme back pressure against using ESP = the way it was designed. The next-header field is supposed to identify = the payload, it does so for every other >> payload ESP carries. Any other solution to somehow infer the payload = type some other way *has* to be seen as a hack. Why do we need a hack? >> The fact that using a payload identifier the way ESP intended also = allows us to do things like handle receipt of said payload without extra = configuration, or use the payload outside >> of ESP are just benefits from good design, they aren't indicative of = doing something incorrectly, the opposite in fact. They also shouldn't = even be needed to justify using ESP the >> way it was designed to be used. >> This is all very strange to me, this want to not use the next-header = field to, you know, identify the next header. >=20 > I see it as a useful feature that I can "enable" IPTFS on my existing > IPsec connection dynamically. Perhaps to avoid always sending traffic > when I have none, and mostly wanting my decoy traffic when I am doing > things (like typing over ssh, sending an email, etc) >=20 > I don't see how this would happen "automatically". It would be a user > invoked event. >=20 > Based on that, userland has to somehow trigger to kernel to switch = from > regular ESP to IPTFS. We would need to define that (eg via Netlink or > PF_KEY). >=20 > But why not use a NOTIFY with a REKEY event to USE_IPTFS ? No need for > new PF_KEY/netlink messages, no new userland <-> kernel signaling. = Just > use existing implemented IKE/IPsec protocols. >=20 > So I think I agree with Valery (and Tero). It is not really about what > the ESP packet format can or cannot do, but using existing channels = for > on-the-fly reconfiguration. It would work the same as if you wanted to > switch a transport mode to tunnel mode or IPCOMP, rekey with(out) > USE_TRANSPORT or USE_IPCOMP. >=20 > Paul >=20 --Apple-Mail=_7E6D459D-F491-40A9-BA85-4335A30764C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+IrTUACgkQLh2DDte4 MCUmPBAAhz7iOPkWVjK7lILfPB5vcI+eRQKGl70Y1msLjRzlH+dHtedneIXECGwP Vu4iO/GjgZsjlfhE/8DCMdsmj9k0d2BCLGAeDH8p583AsOu52sJKOpExt5DVReCc x4ZeZUzDePlM8rgPeSbWit7dzUqahNJG4/hq7euJj6hQOTzdU48lMbA/bhq2oHhj ysN0p+zQeUoCOgTTFl10rIbU7UT7nDyA6lqaVoeoD8BP1CwtMdO+aCZCKMSlATFT czgupqVmFxMlgbPrSZsBzTnt5fHbZC8MrDd9NizKybILaJyW2TxlLUopqPUdofwx daqssqBPF5LcUErd3i1LciDKl+vuJujcfnFGO/cS6Qc9c0lBFIfboCc+/8KIhT7N Sx38fNJvOIseibcuRMesDNKGZQARm8q1tIvkYtz9EJdHNghG2bU+jvEyU8X6P/n/ w/h7SanPqgH6sB5GY/YMfvxImCkPMLjPC/skrcNiLhKqQkTzkLUIU+dLN6KW3R6A 7rDh2IrHHmv8VwYgQMjf5Ul2wNafE6aGJK5ZVuqV/SMiWdNg/mEmpDsDbNqMwIa7 LkKQMvl2T0WRn/FVDpErM60xn0U728E4wEl1gmHLidqsybtJLjuOFiN979P7yMtZ pAmRK0u+eiZM7tYaxL+Js7t0zKys/XWhyYZKOQH/ZwGnRJAm0js= =x+uS -----END PGP SIGNATURE----- --Apple-Mail=_7E6D459D-F491-40A9-BA85-4335A30764C4-- From nobody Thu Oct 15 13:29:17 2020 Return-Path: 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 044463A084D for ; Thu, 15 Oct 2020 13:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 3OBUy2WGni6U for ; Thu, 15 Oct 2020 13:29:06 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 589EF3A0879 for ; Thu, 15 Oct 2020 13:29:04 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A579E61676; Thu, 15 Oct 2020 20:29:03 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E4734495-9295-423F-9B97-9651610913DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 15 Oct 2020 16:29:02 -0400 In-Reply-To: <24456.43991.701332.956314@fireball.acr.fi> Cc: Christian Hopps , Valery Smyslov , Lou Berger , ipsec@ietf.org To: Tero Kivinen References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> <24456.43991.701332.956314@fireball.acr.fi> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:29:15 -0000 --Apple-Mail=_E4734495-9295-423F-9B97-9651610913DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tero, We are defining the payload in this document, the payload is meant for = ESP. ESP has a payload identifier why can't we use it? It feels like the = clean KISS solution to me. Yes, we are doing IKE negotiation, but using = the designed for payload identifier also allows the payload to be = identified in non-IKE scenarios (packet captures, error logging, etc..), = therefor it's not just KISS it's also more *robust* and thus I believe a = better design. I think your main objection is over actually making an IP protocol = number allocation. If that's what it is then let's focus on that point. = It may be easier to make progress that way. For example we could switch to our backup solution and re-use an = existing IP protocol number which would never be carried in ESP (e.g., = IPv5). I feel it's a bit less elegant, but still workable, and leaves us = with the KISS/more robust outcome. Thanks, Chris. > On Oct 15, 2020, at 4:06 PM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >> I really don't understand the extreme back pressure against using >> ESP the way it was designed. The next-header field is supposed to >> identify the payload, it does so for every other payload ESP >> carries. Any other solution to somehow infer the payload type some >> other way *has* to be seen as a hack. Why do we need a hack? >=20 > Because the next-header field identifies the protocol DEFINED > ELSEWHERE that ESP moves around. >=20 > If we want to make modifications to the TCP protocol, and want to > allocate new Protocol Number for it, we do not that in IPsecME WG even > when that new version of TCP could be transmitted over IPsec also. >=20 > When ESPv3 (RFC4303) added new features like support for combined mode > algorithms we did not allocate new protocol number for that. We > decided that we use IKE to identify whether Child SA negotiates > anything that requires ESPv3, and if so then ESPv3 packet format is > used, otherwise ESPv2 (RFC2406) is used. >=20 > So the basic idea is that IPsec and ESP is transporting protocols > defined elsewhere. That does not mean that content of the ESP protocol > can't change, we "own" the ESP format, so we can change it in any ways > we seem needed, and we can negotiate things using IKE to specify the > format specific Child SA is using. >=20 > Now if you are trying to define completely new protocol for generic IP > use, and because it can also be used in the IPsec, you want to > standarize that in the IPsecME WG, I do not think that belongs to the > IPsecME charter. If this protocol is really going to be general use > encapsulation protocol then it needs to be specified somewhere else > (most likely in different Area than security). >=20 > If this is not general use, but just optimization where we can put > multiple IP packets inside one ESP packet to provide traffic flow > security, then we can negotiate that in IKE, and we do not need extra > protocol number for it, and we can do it here. >=20 > I am still unclear which one of those protocols you are trying to > define? >=20 >> The fact that using a payload identifier the way ESP intended also >> allows us to do things like handle receipt of said payload without >> extra configuration, or use the payload outside of ESP are just >> benefits from good design, they aren't indicative of doing something >> incorrectly, the opposite in fact. They also shouldn't even be >> needed to justify using ESP the way it was designed to be used. >=20 > So then this belongs to different area, as it does not have any real > connection to IPsec, it just one of the protocols we can encapsulate > in ESP. >=20 > Also now when I actually checked you draft, I noticed that it has some > congestion control things in it too, and that is something that do > require very careful checking by other areas. >=20 >> This is all very strange to me, this want to not use the next-header >> field to, you know, identify the next header. >=20 > As I said that is fine by me if it is protocol defined outside the > IPsecME. I just do not think it belongs to the IPsecME to define new > internet protocol encapsulating multiple IP packets in, and > fragmenting them, and doing congestion control on them. >=20 > Our main charter says: >=20 > Its purpose is to maintain the IPsec standard and to > facilitate discussion of clarifications, improvements, and > extensions to IPsec, mostly to ESP and IKEv2. >=20 > meaning we work for ESP and IKEv2, not for making new generic IP > protocols. Also the TFC section of charter says: >=20 > The demand for Traffic Flow Confidentiality has been > increasing in the user community, but the current method > defined in RFC4303 (adding null padding to each ESP payload) > is very inefficient in its use of network resources. The > working group will develop an alternative TFC solution that > uses network resources more efficiently. >=20 > Which I did understood that we still work by modifying the ESP > protocol and that we do not define new generic protocols for > encapsulating IP packets and transport that inside ESP (which would > not need any changes to the ESP or IKE, as we already have a way of > negotiating the traffic selectors for any IP protocol we want to > tranport inside ESP). >=20 > Of course there would be some security implications for such protocol > as you would need to specify exit tunnel checks for those packets > coming out from the new protocol, which is why I think it is better > done by modifying ESP. > -- > kivinen@iki.fi >=20 --Apple-Mail=_E4734495-9295-423F-9B97-9651610913DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+IsQ4ACgkQLh2DDte4 MCWb3g/+NWwFhDo5eUG/H63WEiz2x7I49l9UpFA/AjwCUqhzdr+l/kmBW8RfiBiO oyHyqail2KkXxoIb8VGjUzxTS6o5PBkLIF6MlmGQ1uC3gcTiUhf8coa1kntHcvyw jMaub8CWxT4oRdVDEyexjfkVFp9RR1O3YDZrua75d152l/dJrx6kL9xlB6K95VVw vDdbzEmU4iUIofDV5o3pydIBK7cILOzOmC3OoxD4zzlH5TZNxVf9DfySE1tUc/gc 4tRB2OY/oGuoX6RicoMCl1Fgz0MLCtYQbC7bUOI3ufwF40NoePPdxl9N8GQIK6oA wtvqSpFLULem9HesXXfEKyjfKrg9c8An7Jq3w89qlwEBQJU/+hMEW5cowlK0OHDf RhrucRMzoOV8QGMVv90H7b/e786t86b+2HdsJyQmut77aZFP1vJmYH+TIliTGLYr Cdg01Y0drWzdriXQyF9RlPdpPFc9PMX6D9vlRpje1GzQtTR9itHAToQ+raraZ3il aTdMoh+Xvgvz+cYbl9TaupjA3HO2x5Qh5z2cDMLnX8bhKVJ2dGHaFonwxBRJ79oN j/pSE03cAe7D6zA1pvM4tTkoenz1EYwJQyOWXpqLcLsAuC66Lo5MhJcRMz9LWibb YwZabHl+e0HcG+KDjHGBNrXN/AzsvlZFjMZ5T0LHdL4IMKRfqBU= =XSaP -----END PGP SIGNATURE----- --Apple-Mail=_E4734495-9295-423F-9B97-9651610913DB-- From nobody Thu Oct 15 13:31:13 2020 Return-Path: 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 AB7D33A010A for ; Thu, 15 Oct 2020 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 Uhm3xSSTGQ3i for ; Thu, 15 Oct 2020 13:31:09 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 813133A0114 for ; Thu, 15 Oct 2020 13:31:09 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 8A4C320305; Thu, 15 Oct 2020 23:31:07 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1602793867; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o48F+k0plwwEj1Np0n9rVR6mwwdNS+ZTYsAE0TD54oA=; b=cftVY+mf7R69uOZ9MNig0J8FmDViqE//8B8v998fSsK1iETkflm+/aTtyyQZ1r2r9y9Ipz iLb51wmClDaZ0G4+CIQzcJxp9GNTS4D1bzVwtD1fXUOlGEW3o94P8N/YRST5rQGyzSsN5K 1PMA+J6l+IVA32y/F/7db1v8+cy6byU= Received: by fireball.acr.fi (Postfix, from userid 15204) id 42B2225C0E38; Thu, 15 Oct 2020 23:31:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24456.45451.227215.902031@fireball.acr.fi> Date: Thu, 15 Oct 2020 23:31:07 +0300 From: Tero Kivinen To: Christian Hopps Cc: Valery Smyslov , Lou Berger , ipsec@ietf.org In-Reply-To: <27AAF738-100F-4CD5-A498-BE8E93765343@chopps.org> References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <56F3A6E6-EDD6-46FA-8829-EC10FD9AD058@chopps.org> <003b01d6a200$2d70df80$88529e80$@gmail.com> <9A514314-DA80-4498-9FFA-22B8647D2D9D@chopps.org> <24454.53404.39277.731780@fireball.acr.fi> <27AAF738-100F-4CD5-A498-BE8E93765343@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 23 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1602793867; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o48F+k0plwwEj1Np0n9rVR6mwwdNS+ZTYsAE0TD54oA=; b=dPUpGUiSjzlF8Jtt/87eo0h8o7Lq+hT+81+CRaPWzC5wbwfNv3ojCvsEw3WKXDTlcsIHXQ A6bjf0LI9Bowf2aA6yuS7u1KHy01BnzqD+w8YiUJYEu5EhMqsuE6mDrh2zfKN5wITW9tDS 5JJ0Xost48HMvLMpRDshOK71RHB99mA= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1602793867; a=rsa-sha256; cv=none; b=vN87inCpL87SPC7PsxUdklI7aHlFU8uZKkISlPa53/EFvRw7MtcsUd2F4+LsrY85oO+koP 2tfTUJIzoGB6b6lTKGWHqpp/CFhwyJwb7lvAQ/FbquBMwp60S93/cqFdBuE4tqJlQX3S1H XpDEmP1CE0ViBL+tzYXpasB6NpZ203c= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:31:13 -0000 Christian Hopps writes: > > Earlier there was also another encapsuluation mode called a Bound > > End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and > > in that case it would have been impossible to detect the mode from the > > incoming packet, as lots of the information needed to reconstruct the > > end to end IP header is stored in the SA. > > > > Anyways we do store things in the IPsec SA when we create them, we do > > have negotiation mechanism to agree on those parameters and we can use > > them, we do not need to process things per packet basis. > > Are you saying that the next-header field is useless then? Nope. It is needed for transport mode, and also for tunnel mode, where there are few possible values for it (4, 41, 59). > I mean the code I've worked on parses the next header field on a per > packet basis to handle the inner packet payload. In tunnel mode they most likely drop everything else than IP in IP, right? Or do they really start processing TCP packets inside tunnel mode SA? > I'm not interested in trying to redesign ESP with IPTFS, just use it > as provided. So if you want to define new version of ip in ip that allows encapsulating multiple ip packets inside one packet, then that should not be done in the IPsecME WG. IPv4 tunneling (protocol 4) was there long before IPsec, the IPv6 tunneling (protocol 41) was done by ipng wg etc. Neither one of those are done in the IPsec WG, but ESP are using them as they are useful things to do. -- kivinen@iki.fi From nobody Thu Oct 15 13:48:38 2020 Return-Path: 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 504D83A03F4 for ; Thu, 15 Oct 2020 13:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 3d34426UkR71 for ; Thu, 15 Oct 2020 13:48:35 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 F143F3A03F5 for ; Thu, 15 Oct 2020 13:48:34 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 2A47F2059A; Thu, 15 Oct 2020 23:48:32 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1602794912; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BFZJnJEiPX8JDXt3TjHSkTAzCyoROn/DT9RcBR6g6F0=; b=wuc8/zotLKz6ZQUkit4T037wiXD33cHkBNzXAfcfvliBHhNn13HujC53PRFJORWprVa+lC zT+nAx5fsITWBv5kmDmmeVcBotmzpypHoilfpaf/0ln997vMNc5AZr2hls9sNW8EzRZLtX N6OsM+OK5GuAOMO2iYB930PYhCyt6Qc= Received: by fireball.acr.fi (Postfix, from userid 15204) id D617D25C0E58; Thu, 15 Oct 2020 23:48:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24456.46495.840733.468384@fireball.acr.fi> Date: Thu, 15 Oct 2020 23:48:31 +0300 From: Tero Kivinen To: Christian Hopps Cc: Valery Smyslov , Lou Berger , ipsec@ietf.org In-Reply-To: References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> <24456.43991.701332.956314@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1602794912; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BFZJnJEiPX8JDXt3TjHSkTAzCyoROn/DT9RcBR6g6F0=; b=UrbrTwvTETcXsLflY71KdRFO3fNYxLkoigLENszlMNrDYLBpATaKYLwo4e/naegwVIoJLO N9WYMiV5kq8UkQ6hC/yvjTt4KkZJT5By4GZJB8dRPsJzo2yB9ykJKq2qgadZgD8iLbXYmg t7Y3fQSvUSYIb7ubxD8+G9qmqWww0FE= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1602794912; a=rsa-sha256; cv=none; b=W39lb7YN2strpXkvA3OaT7rxB8LqxBg1nkKA8WKj4kyw4trUJWCe1ixZ7Hz0QgExB668DO 7Wtm+TcboRyadJMUdQWGgNR8MuKrF/hMhByZfwiFCekiHRrSy7LAZWrTNlOWTXKGoNJkOL joTnoyjMOL3nfMBrqab6Cd3F6q9ZobA= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:48:37 -0000 Christian Hopps writes: > We are defining the payload in this document, the payload is meant > for ESP. ESP has a payload identifier why can't we use it? If that is only possible value the next-header field can have as all packets of the Child SA which has been negotiated with USE_IPTFS then what is the point of allocating number that is not needed. You can simply say that next payload field will be transmitted as 0, and ignored on the recipient as you already know the format packet inside ESP because it was negotiated in the IKE. > It feels like the clean KISS solution to me. Yes, we are doing IKE > negotiation, but using the designed for payload identifier also > allows the payload to be identified in non-IKE scenarios (packet > captures, error logging, etc..), therefor it's not just KISS it's > also more *robust* and thus I believe a better design. So you want to allocate completely new protocol number from the 8-bit registry, just so that you can print it out in the error logs and auditing, instead of putting (use_ipftf ? "iptfs" : protocol number)? Packet captures does not really help as ESP content is encrypted, and most implementations do not really allow easy way of printing out the traffic keys for wireshark etc use, and anyways wireshark has this decode as XXX option where you can force it to decode it with whatever protocol you think is inside, regardless whether there is protocol number matching. > I think your main objection is over actually making an IP protocol > number allocation. Actually doing early allocation. > If that's what it is then let's focus on that point. It may be > easier to make progress that way. I need to justify why the WG thinks we need this done now, and why this is going to be useful, and why this can't be done in other ways. If I myself think it would be easier to do this by just negotiating it in IKE, I have hard time convincing others. > For example we could switch to our backup solution and re-use an > existing IP protocol number which would never be carried in ESP > (e.g., IPv5). I feel it's a bit less elegant, but still workable, > and leaves us with the KISS/more robust outcome. I do not think there is IP protocol number for IPv5, but if you really want to have protocol number, why not use 253 that is reserved for experimientation and testing. This allows you to do your testing now, and you can write your draft saying that as all payloads inside the ESP will be iptfs packets if USE_IPFTF is negotiated in the IKE, then next-header field is ignored on the recipient, and sent out as 253 (or 0, or whatever, as it is always ignored on the recipient). -- kivinen@iki.fi From nobody Thu Oct 15 14:20:52 2020 Return-Path: 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 C90C03A07F5 for ; Thu, 15 Oct 2020 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 SlZekAiLuNwV for ; Thu, 15 Oct 2020 14:20:49 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6B24E3A07F0 for ; Thu, 15 Oct 2020 14:20:49 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A75F861676; Thu, 15 Oct 2020 21:20:48 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1412626A-914C-4587-9CA2-3428A55BCE2F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 15 Oct 2020 17:20:47 -0400 In-Reply-To: <24456.46495.840733.468384@fireball.acr.fi> Cc: Christian Hopps , Valery Smyslov , Lou Berger , ipsec@ietf.org To: Tero Kivinen References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> <24456.43991.701332.956314@fireball.acr.fi> <24456.46495.840733.468384@fireball.acr.fi> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 21:20:51 -0000 --Apple-Mail=_1412626A-914C-4587-9CA2-3428A55BCE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 15, 2020, at 4:48 PM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >> We are defining the payload in this document, the payload is meant >> for ESP. ESP has a payload identifier why can't we use it? >=20 > If that is only possible value the next-header field can have as all > packets of the Child SA which has been negotiated with USE_IPTFS then > what is the point of allocating number that is not needed. You can > simply say that next payload field will be transmitted as 0, and > ignored on the recipient as you already know the format packet inside > ESP because it was negotiated in the IKE. >=20 >> It feels like the clean KISS solution to me. Yes, we are doing IKE >> negotiation, but using the designed for payload identifier also >> allows the payload to be identified in non-IKE scenarios (packet >> captures, error logging, etc..), therefor it's not just KISS it's >> also more *robust* and thus I believe a better design. >=20 > So you want to allocate completely new protocol number from the 8-bit > registry, just so that you can print it out in the error logs and > auditing, instead of putting (use_ipftf ? "iptfs" : protocol number)? >=20 > Packet captures does not really help as ESP content is encrypted, and > most implementations do not really allow easy way of printing out the > traffic keys for wireshark etc use, and anyways wireshark has this > decode as XXX option where you can force it to decode it with whatever > protocol you think is inside, regardless whether there is protocol > number matching. These are just examples, they fall out of relying on as little state as = possible to help debug things. One could have the correct decryption key = but not have all the correct configuration in a non-IKE scenario, ... In any case it's always better to rely on less state where one can. It = is almost always more robust. I don't think this is a controversial = statement. >> I think your main objection is over actually making an IP protocol >> number allocation. >=20 > Actually doing early allocation. >=20 >> If that's what it is then let's focus on that point. It may be >> easier to make progress that way. >=20 > I need to justify why the WG thinks we need this done now, and why > this is going to be useful, and why this can't be done in other ways. >=20 > If I myself think it would be easier to do this by just negotiating it > in IKE, I have hard time convincing others. Ok good, so let's consider re-using an existing number then. >=20 >> For example we could switch to our backup solution and re-use an >> existing IP protocol number which would never be carried in ESP >> (e.g., IPv5). I feel it's a bit less elegant, but still workable, >> and leaves us with the KISS/more robust outcome. >=20 > I do not think there is IP protocol number for IPv5, but if you really > want to have protocol number, why not use 253 that is reserved for > experimientation and testing. There is it's officially called "Internet Stream Protocol". Lou could = speak more about that I guess. > This allows you to do your testing now, and you can write your draft > saying that as all payloads inside the ESP will be iptfs packets if > USE_IPFTF is negotiated in the IKE, then next-header field is ignored > on the recipient, and sent out as 253 (or 0, or whatever, as it is > always ignored on the recipient). I still believe an identifier is important for the robust aspects I = mentioned above (less state dependent payload identification, aids in = packet captures, error logging/mis-configuration identification, yes = even zero-configuration receive support which doesn't have to be in the = document to still be a feature people want and could be given then). Additionally, as mentioned previously, not all users of IPsec utilize = IKE. Thanks, Chris. > -- > kivinen@iki.fi >=20 --Apple-Mail=_1412626A-914C-4587-9CA2-3428A55BCE2F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+IvS8ACgkQLh2DDte4 MCVYWQ//eb/M3hoJqpZn16eE101242/AHVNIDa9Ioteu8DesPTuz5iY5eJX5PrGL SjS6k+3mLIW5YLsKN4vkEjvzEhIYgT+ARUp8tTZKuUck/jSpmIwWVTSpftvkn+xh R6BFsHANy6RIhG3SAXbbYS+cAyAtMaj/NfeJY/A2bR2KoOEZSOa0H4HiND0slzQF GiRnkx29PHrlC4EOG/ZynLlye5J8fmZ+6Ym4gzo0Jz+6P5lOSrTzRw/GY1QW5agX HyHuPlQ04EL5Swt+cdi8sp+0KV1l+hMxKnSNRCPA1O8gFdIoG4TRNRFN/UDXieHH rMET3dm6jjDc9vejL/IPBe4XBSyNhb2i825c+SK4FHPk8ib+bR4RxJQNx9aWk9Mp Q90tkR764J+QnQEHH4iEAFA0IY8Ys91Us1MFcUYL+v1szaYuXBeoUwEYerYX5WAB /vkBWXqEY2RZdrXLARABlKUVhhhFmZFuBIOJDks60szobYxfjAecf/LpBuBql4Vy 6xK56ReFUlu/GVadbt3k0Zk+qk1OSNCSMl2snLOe8qEEs1ws7+28ya+5lSdTsIpA lfimMmoJbAD9rLvrwJDQFJb7XNfVjE9NzcZB7vjtmYinknZeUckP6PQrPKxmiozI DbYq2acycbq/HUaxaihYL0/ciaA21PIEuWHNLwwhhq2Vm/qARWs= =EhDp -----END PGP SIGNATURE----- --Apple-Mail=_1412626A-914C-4587-9CA2-3428A55BCE2F-- From nobody Fri Oct 16 01:20:12 2020 Return-Path: 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 A10D63A0DEF; Fri, 16 Oct 2020 01:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 TUr1DF2iDyfV; Fri, 16 Oct 2020 01:19:56 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.177]) (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 1F3203A0DDA; Fri, 16 Oct 2020 01:19:55 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by mx02.puc.rediris.es with ESMTP id 09G8Jrii027967-09G8Jrij027967; Fri, 16 Oct 2020 10:19:53 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id E0F5420040; Fri, 16 Oct 2020 10:19:53 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U5ZseB_1jcLm; Fri, 16 Oct 2020 10:19:53 +0200 (CEST) Received: from [192.168.1.33] (135.red-79-150-250.dynamicip.rima-tde.net [79.150.250.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 0E0631FF41; Fri, 16 Oct 2020 10:19:51 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_70C4207B-C17E-40FE-A432-F907BCC6A079" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 16 Oct 2020 10:19:50 +0200 In-Reply-To: <160252655236.514.5675626677635075934@ietfa.amsl.com> Cc: Rafa Marin-Lopez , ipsec@ietf.org, yang-doctors@ietf.org, last-call@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org To: i2nsf@ietf.org References: <160252655236.514.5675626677635075934@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.167, helo=xenon41.um.es, mailFrom=rafa@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.167 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=bEQuieDtiSROx5aMushaXJBL+yWOJV/k9x4j8cKPLiw=; b=w8xJ6ULp9a/hXZByfS4nnohMv1+VAiBIQ4GnihikOOyEQL7mq4VkrrMw9CWw9Ur19YcWEOZg2Y6H ufAD6VvOD1V3+PhI2jRlpz8aQvrySuNF89wj8dHRoYMMXyXtIJvVePvtfXOknldJ2Ys8ld9fWh4b xFNQk+ZYo2ZgwNJaL8coU7Pl8uU5P2+FO4YocfFk+n7+9m/WpPgWJkDRsaExExEpqvN6+IPzADUW PIrFMn605Tyi9V16Z2SOzbRIpSApRBwXPbOcIbNWQFD9iBZNTHPEv+F4jw/gRr9jGvA+4vrNB2AH vrA2buIKQInnKwqaZfaKzaOCzatdugenDV/Zow== Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 08:20:03 -0000 --Apple-Mail=_70C4207B-C17E-40FE-A432-F907BCC6A079 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all: Recently we submitted v09. We would like to summarize the status: - We have applied all the comments we received so far (except one, see = below). In particular, we would like to highlight that we have renamed = the modules as a consequence of some comments. In particular: ietf-ipsec-common =E2=80=94> ietf-i2nsf-ikec ietf-ipsec-ike =E2=80=94> ietf-i2nsf-ike ietf-ipsec-ikeless -> ietf-i2nsf-ikeless - Moreover we made a minor change. We realized that encryption = algorithms should also have a key-length. For example, it is not enough = to say the algorithm is AES-CBC without specifying the key-length (e.g. = 128 bits).=20 - Regarding the pending comment, as you may have followed in the mailing = list, it has been proposed to add a feature ikeless-notification and the = corresponding if ikeless-notification in each notification to indicate = whether notifications are implemented by the NSF. The goal here is to = ensure broader applicability of the ikeless module. If there is no = objection, we can include this feature adding a description about the = motivation behind this and prepare v10 very quickly. "To ensure broader applicability of this module, the notifications are = marked as a feature. For the implementation of ikeless case, the NSF is = expected to implement this feature."; The result would be (in tree format): notifications: +---n sadb-acquire {ikeless-notification}? | +--ro ipsec-policy-name string | +--ro traffic-selector | +--ro local-subnet inet:ip-prefix | +--ro remote-subnet inet:ip-prefix | +--ro inner-protocol? ipsec-inner-protocol | +--ro local-ports* [start end] | | +--ro start inet:port-number | | +--ro end inet:port-number | +--ro remote-ports* [start end] | +--ro start inet:port-number | +--ro end inet:port-number +---n sadb-expire {ikeless-notification}? | +--ro ipsec-sa-name string | +--ro soft-lifetime-expire? boolean | +--ro lifetime-current | +--ro time? uint32 | +--ro bytes? uint32 | +--ro packets? uint32 | +--ro idle? uint32 +---n sadb-seq-overflow {ikeless-notification}? | +--ro ipsec-sa-name string +---n sadb-bad-spi {ikeless-notification}? +--ro spi uint32 Best Regards. =20 > El 12 oct 2020, a las 20:15, internet-drafts@ietf.org escribi=C3=B3: >=20 >=20 > A new version of I-D, = draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt > has been successfully submitted by Rafa Marin-Lopez and posted to the > IETF repository. >=20 > Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection > Revision: 09 > Title: Software-Defined Networking (SDN)-based IPsec = Flow Protection > Document date: 2020-10-12 > Group: i2nsf > Pages: 92 > URL: = https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection= -09.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection > Htmlized: = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-09 >=20 > Abstract: > This document describes how to provide IPsec-based flow protection > (integrity and confidentiality) by means of an Interface to Network > Security Function (I2NSF) controller. It considers two main well- > known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- > host. The service described in this document allows the > configuration and monitoring of IPsec Security Associations (SAs) > from a I2NSF Controller to one or several flow-based Network = Security > Functions (NSFs) that rely on IPsec to protect data traffic. >=20 > The document focuses on the I2NSF NSF-facing interface by providing > YANG data models for configuring the IPsec databases (SPD, SAD, PAD) > and IKEv2. This allows IPsec SA establishment with minimal > intervention by the network administrator. It does not define any > new protocol. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_70C4207B-C17E-40FE-A432-F907BCC6A079 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = all:

Recently we = submitted v09. We would like to summarize the status:

- We have applied all = the comments we received so far (except one, see below). In particular, = we would like to highlight that we have renamed the modules as a = consequence of some comments. In particular:

ietf-ipsec-common =E2=80=94> = ietf-i2nsf-ikec
ietf-ipsec-ike =E2=80=94> = ietf-i2nsf-ike
ietf-ipsec-ikeless -> = ietf-i2nsf-ikeless

- Moreover we made a minor change. We realized that = encryption algorithms should also have a key-length. For example, it is = not enough to say the algorithm is AES-CBC without specifying the = key-length (e.g. 128 bits). 

- Regarding the pending comment, as you = may have followed in the mailing list, it has been proposed to add a = feature ikeless-notification and the corresponding if ikeless-notification in each notification to indicate whether notifications are implemented by the = NSF. The goal here = is to ensure broader applicability of the ikeless = module. If there is no objection, we can include this = feature adding a description about the motivation behind this and = prepare v10 very quickly.

"To ensure broader applicability of this module, the = notifications are marked as a feature. For the implementation of ikeless = case, the NSF is expected to implement this feature.";

The = result would be (in tree format):

notifications:
  =   +---n sadb-acquire {ikeless-notification}?
  =   |  +--ro ipsec-policy-name    string
    |  +--ro traffic-selector
    |     +--ro local-subnet   =    inet:ip-prefix
    |   =   +--ro remote-subnet     inet:ip-prefix
    |     +--ro inner-protocol?   = ipsec-inner-protocol
    |     = +--ro local-ports* [start end]
    | =     |  +--ro start   =  inet:port-number
    |   =   |  +--ro end      inet:port-number
    |     +--ro remote-ports* [start = end]
    |       =  +--ro start    inet:port-number
    |        +--ro end   =    inet:port-number
    +---n = sadb-expire {ikeless-notification}?
    |  +--ro ipsec-sa-name     =       string
    | =  +--ro soft-lifetime-expire?   boolean
    |  +--ro lifetime-current
    |     +--ro time?     =  uint32
    |     +--ro = bytes?     uint32
    |   =   +--ro packets?   uint32
    | =     +--ro idle?      uint32
    +---n sadb-seq-overflow {ikeless-notification}?
  =   |  +--ro ipsec-sa-name    string
    +---n sadb-bad-spi {ikeless-notification}?
  =      +--ro spi   =  uint32


Best= Regards.  

El 12 oct 2020, a las 20:15, internet-drafts@ietf.org escribi=C3=B3:


A new version of I-D, = draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt
has been = successfully submitted by Rafa Marin-Lopez and posted to the
IETF repository.

Name: = draft-ietf-i2nsf-sdn-ipsec-flow-protection
Revision: 09
Title: = Software-Defined Networking (SDN)-based IPsec Flow Protection
Document date: 2020-10-12
Group:= = i2nsf
Pages: 92
URL: =            https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow= -protection-09.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection
Htmlized: =       https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-09
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-09

Abstract:
  This document describes how to provide = IPsec-based flow protection
  (integrity and = confidentiality) by means of an Interface to Network
=   Security Function (I2NSF) controller.  It considers two = main well-
  known scenarios in IPsec: (i) = gateway-to-gateway and (ii) host-to-
  host. =  The service described in this document allows the
=   configuration and monitoring of IPsec Security Associations = (SAs)
  from a I2NSF Controller to one or = several flow-based Network Security
  Functions = (NSFs) that rely on IPsec to protect data traffic.

  The document focuses on the I2NSF NSF-facing = interface by providing
  YANG data models for = configuring the IPsec databases (SPD, SAD, PAD)
=   and IKEv2.  This allows IPsec SA establishment with = minimal
  intervention by the network = administrator.  It does not define any
=   new protocol.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat



-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_70C4207B-C17E-40FE-A432-F907BCC6A079-- From nobody Fri Oct 16 06:35:55 2020 Return-Path: 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 C15C53A0F5E for ; Fri, 16 Oct 2020 06:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 Z6aasV4Qk5IF for ; Fri, 16 Oct 2020 06:35:51 -0700 (PDT) Received: from slmp-550-48.slc.westdc.net (unknown [174.127.108.195]) (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 5962F3A0FD9 for ; Fri, 16 Oct 2020 06:35:43 -0700 (PDT) Received: from pool-100-15-105-234.washdc.fios.verizon.net ([100.15.105.234]:43634 helo=fs2.dc.labn.net) by slmp-550-48.slc.westdc.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kTPtV-00A56y-82; Fri, 16 Oct 2020 07:35:41 -0600 To: Christian Hopps , Tero Kivinen Cc: Valery Smyslov , ipsec@ietf.org References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> <24456.43991.701332.956314@fireball.acr.fi> <24456.46495.840733.468384@fireball.acr.fi> From: Lou Berger Message-ID: <07d4cee7-c127-1825-143f-86684a80a9c0@labn.net> Date: Fri, 16 Oct 2020 09:35:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E46F5B3C80D50140D1496126" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - slmp-550-48.slc.westdc.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: slmp-550-48.slc.westdc.net: authenticated_id: lberger@labn.net X-Authenticated-Sender: slmp-550-48.slc.westdc.net: lberger@labn.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 13:35:54 -0000 This is a multi-part message in MIME format. --------------E46F5B3C80D50140D1496126 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/15/20 5:20 PM, Christian Hopps wrote: >> I do not think there is IP protocol number for IPv5, but if you really >> want to have protocol number, why not use 253 that is reserved for >> experimientation and testing. > There is it's officially called "Internet Stream Protocol". Lou could speak more about that I guess. > not that it's critical -- protocol number 5 is both assigned and historic.  I'm happy to support it's reuse as co-editor/author of the final version of IPv5, RFC1819. Lou PS my unicast mail is broken, but I'm reading the list --------------E46F5B3C80D50140D1496126 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


On 10/15/20 5:20 PM, Christian Hopps wrote:
I do not think there is IP protocol number for IPv5, but if you really
want to have protocol number, why not use 253 that is reserved for
experimientation and testing.

There is it's officially called "Internet Stream Protocol". Lou could speak more about that I guess.

not that it's critical -- protocol number 5 is both assigned and historic.  I'm happy to support it's reuse as co-editor/author of the final version of IPv5, RFC1819.

Lou

PS my unicast mail is broken, but I'm reading the list

--------------E46F5B3C80D50140D1496126-- From nobody Fri Oct 16 15:55:15 2020 Return-Path: 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 2445E3A07C3; Fri, 16 Oct 2020 15:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 vBbO_vF2tnLM; Fri, 16 Oct 2020 15:55:11 -0700 (PDT) Received: from slmp-550-48.slc.westdc.net (unknown [174.127.108.195]) (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 0C5363A07BD; Fri, 16 Oct 2020 15:55:10 -0700 (PDT) Received: from pool-100-15-105-234.washdc.fios.verizon.net ([100.15.105.234]:61284 helo=[11.5.0.121]) by slmp-550-48.slc.westdc.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kTYcv-00Bivr-1y; Fri, 16 Oct 2020 16:55:09 -0600 To: Rafa Marin-Lopez , i2nsf@ietf.org Cc: ipsec@ietf.org, yang-doctors@ietf.org, last-call@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org References: <160252655236.514.5675626677635075934@ietfa.amsl.com> From: Lou Berger Message-ID: <0df078b7-14b6-1262-4cfa-4d1429ef945c@labn.net> Date: Fri, 16 Oct 2020 18:55:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - slmp-550-48.slc.westdc.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: slmp-550-48.slc.westdc.net: authenticated_id: lberger@labn.net X-Authenticated-Sender: slmp-550-48.slc.westdc.net: lberger@labn.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 22:55:13 -0000 On 10/16/2020 4:19 AM, Rafa Marin-Lopez wrote: > If there is no objection, we can include this feature adding a > description about the motivation behind this and prepare v10 very quickly. Thank you for this. I think it would be a really helpful change -- and I support it. Lou (as contributor with multiple hats) On 10/16/2020 4:19 AM, Rafa Marin-Lopez wrote: > Dear all: > > Recently we submitted v09. We would like to summarize the status: > > - We have applied all the comments we received so far (except one, see > below). In particular, we would like to highlight that we have renamed > the modules as a consequence of some comments. In particular: > > ietf-ipsec-common —> ietf-i2nsf-ikec > ietf-ipsec-ike —> ietf-i2nsf-ike > ietf-ipsec-ikeless -> ietf-i2nsf-ikeless > > - Moreover we made a minor change. We realized that encryption > algorithms should also have a key-length. For example, it is not enough > to say the algorithm is AES-CBC without specifying the key-length (e.g. > 128 bits). > > - Regarding the pending comment, as you may have followed in the mailing > list, it has been proposed to add a feature *ikeless-notification* and > the corresponding *if ikeless-notification* in each notification to > indicate whether notifications are implemented by the NSF. The goal here > is to ensure broader applicability of the ikeless module. If there is no > objection, we can include this feature adding a description about the > motivation behind this and prepare v10 very quickly. > > "To ensure broader applicability of this module, the notifications are > marked as a feature. For the implementation of ikeless case, the NSF is > expected to implement this feature."; > > The result would be (in tree format): > > notifications: >     +---n sadb-acquire *{ikeless-notification}*? >     |  +--ro ipsec-policy-name    string >     |  +--ro traffic-selector >     |     +--ro local-subnet      inet:ip-prefix >     |     +--ro remote-subnet     inet:ip-prefix >     |     +--ro inner-protocol?   ipsec-inner-protocol >     |     +--ro local-ports* [start end] >     |     |  +--ro start    inet:port-number >     |     |  +--ro end      inet:port-number >     |     +--ro remote-ports* [start end] >     |        +--ro start    inet:port-number >     |        +--ro end      inet:port-number >     +---n sadb-expire *{ikeless-notification}*? >     |  +--ro ipsec-sa-name           string >     |  +--ro soft-lifetime-expire?   boolean >     |  +--ro lifetime-current >     |     +--ro time?      uint32 >     |     +--ro bytes?     uint32 >     |     +--ro packets?   uint32 >     |     +--ro idle?      uint32 >     +---n sadb-seq-overflow *{ikeless-notification}*? >     |  +--ro ipsec-sa-name    string >     +---n sadb-bad-spi *{ikeless-notification}*? >        +--ro spi    uint32 > > > Best Regards. > >> El 12 oct 2020, a las 20:15, internet-drafts@ietf.org >> escribió: >> >> >> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt >> has been successfully submitted by Rafa Marin-Lopez and posted to the >> IETF repository. >> >> Name:draft-ietf-i2nsf-sdn-ipsec-flow-protection >> Revision:09 >> Title:Software-Defined Networking (SDN)-based IPsec Flow Protection >> Document date:2020-10-12 >> Group:i2nsf >> Pages:92 >> URL: >> https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 >> >> Abstract: >>   This document describes how to provide IPsec-based flow protection >>   (integrity and confidentiality) by means of an Interface to Network >>   Security Function (I2NSF) controller.  It considers two main well- >>   known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- >>   host.  The service described in this document allows the >>   configuration and monitoring of IPsec Security Associations (SAs) >>   from a I2NSF Controller to one or several flow-based Network Security >>   Functions (NSFs) that rely on IPsec to protect data traffic. >> >>   The document focuses on the I2NSF NSF-facing interface by providing >>   YANG data models for configuring the IPsec databases (SPD, SAD, PAD) >>   and IKEv2.  This allows IPsec SA establishment with minimal >>   intervention by the network administrator.  It does not define any >>   new protocol. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> >> > > ------------------------------------------------------- > Rafa Marin-Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > > > > From nobody Sat Oct 17 10:03:34 2020 Return-Path: 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 839933A11F4 for ; Sat, 17 Oct 2020 10:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 IaJEXgaE3w8o for ; Sat, 17 Oct 2020 10:03:30 -0700 (PDT) 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 925B23A0FBD for ; Sat, 17 Oct 2020 10:03:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CD8VR2Xv8zFVP for ; Sat, 17 Oct 2020 19:03:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1602954207; bh=sLKwflKsZ/4eoyIsU9c/XSlPNtN+DU7hxhaYNc93VoQ=; h=Date:From:To:Subject; b=flIHrjI0pUnHuX3zedGvTyjAUxXvmqYK1ckVYWV4NF74NbDizE+Wi1Xl4jSdlAU60 DvBnlDJFFkuFxrOqmoqTZPrm6m1R6p+Oe8mNJFfMIcsyl6f+nsVe65R4v8/yo+8m+C tVLg7CDITIrygApopZqO4NNdNWLsbc/tRYbdPcOs= 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 r3orhGHbXlzl for ; Sat, 17 Oct 2020 19:03:26 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sat, 17 Oct 2020 19:03:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5B0446029B99; Sat, 17 Oct 2020 13:03:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 52BD68A8 for ; Sat, 17 Oct 2020 13:03:24 -0400 (EDT) Date: Sat, 17 Oct 2020 13:03:24 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] libreswan-ciso interoperability issue with IKEv2 Notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 17:03:33 -0000 Yesterday we ran into an interoperability issue with Cisco. Libreswan split out the Notify Protocol ID values from the Delete Protocol ID values and Proposal Protocol ID values. While these "registries" are basically the same, they are subtly different. We basically changed it like this: -extern enum_names ikev2_sec_proto_id_names; +extern enum_names ikev2_proposal_protocol_id_names; /* 1=IKE SA, 2=AH, 3=ESP */ +extern enum_names ikev2_delete_protocol_id_names; /* 1=IKE SA, 2=AH, 3=ESP */ +extern enum_names ikev2_notify_protocol_id_names; /* NONE=0, 2=AH, 3=ESP; NOT IKE! */ Note that Notify payloads cannot have Protocol ID set to 1. However, this is what Cisco is sending. Libreswan incorrectly did not ignore this, resulting in these two bugs causing an interop failure. We have fixed our code to handle this, but it would be good if Cisco fixed their bug as well, and for other implementations to have a look if they perhaps made a similar mistake. Paul From nobody Tue Oct 20 12:56:48 2020 Return-Path: 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 8F50E3A138C; Tue, 20 Oct 2020 12:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 utVc4pFekOnr; Tue, 20 Oct 2020 12:56:38 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 444173A1350; Tue, 20 Oct 2020 12:56:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09KJuSvK024383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2020 15:56:33 -0400 Date: Tue, 20 Oct 2020 12:56:28 -0700 From: Benjamin Kaduk To: draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org Cc: ipsec@ietf.org Message-ID: <20201020195628.GP39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 19:56:46 -0000 Hi Med, Not a whole lot to comment on here, but probably we should publish a new revisionn to tidy things up before asking for IETF LC. Thanks, Ben %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% We use the term "dual-stack" several times but it is not defined explicitly. While this is certainly a common and fairly well-known concept, perhaps we should drop an "IPv6/IPv4" in somewhere (or add a reference? I'm not sure what reference would be good, offhand). There seem to be a few places where we use the phrase "status type" without preceding "notification"; would it make sense to normalize the language around "notification status type"? Section 3 Section 3.15.4 of [RFC7296] defines a generic notification error type that is related to a failure to handle an address assignment request. That error type does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. INTERNAL_ADDRESS_FAILURE is a catch- all error type when an address-related issue is encountered by an IKEv2 responder. INTERNAL_ADDRESS_FAILURE does not provide sufficient hints to the IKEv2 initiator to adjust its behavior. I feel like we might also want to mention that (per 7296), "[t]he responder sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned", and in many of the indicated use cases, the responder can successfully assign *one* address, just not the full requested set, so INTERNAL_ADDRESS_FAILURE is explicitly not useful. Section 5 If the initiator is dual-stack, it MUST include both address families in its request (absent explicit policy/configuration otherwise). By "both address families" we mean "both the IP6_ALLOWED and IP4_ALLOWED notification status types"? Or are we talking about something else, like a configuration payload? It is perhaps surprising that we only impose the requirement for the initiator to send these notifications specifically on dual-stack initiators; a generic protocol update might typically impose a requirement to always send your capabilities, whether dual-stack or single-stack. In particular, the table seems to imply that the initiator will still send something to indicate the requested AF in the single-requested-AF case (which need not be dual-stack); is this something other than IP_ALLOWED? If the initiator only receives one single notification IP4_ALLOWED or IP6_ALLOWED from the responder, the initiator MUST NOT send a request for an alternate address family not supported by the responder. What is the scope of this "MUST NOT"? Other CREATE_CHILD_SA on the same parent IKE SA? Ever to the same responder? If a dual-stack initiator requests only an IPv6 prefix (or an IPv4 address) but only receives IP4_ALLOWED (or IP6_ALLOWED) notification status type from the responder, the initiator MUST send a request for IPv4 address(es) (or IPv6 prefix(es)). [related to the earlier comment about only requiring dual-stack initiators to send, at the start of the section we said that a dual-stack initiator MUST include both address families...] Section 6 I think a phrasing like "since the IPv4/IPv6 capabilities of a node are readily determined from the traffic it generates, this document does not introduce any new security considerations compared to the ones described in [RFC7296], which continue to apply" might be more conventional. (I don't object to the current phrasing, though.) From nobody Wed Oct 21 01:28:46 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB48C3A1371; Wed, 21 Oct 2020 01:28:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <160326892466.847.15037511394116891305@ietfa.amsl.com> Date: Wed, 21 Oct 2020 01:28:44 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 08:28:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IKEv2 Notification Status Types for IPv4/IPv6 Coexistence Author : Mohamed Boucadair Filename : draft-ietf-ipsecme-ipv6-ipv4-codes-05.txt Pages : 7 Date : 2020-10-21 Abstract: This document specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence. This document updates RFC7296. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-05 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ipv6-ipv4-codes-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ipv6-ipv4-codes-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 21 01:31:13 2020 Return-Path: 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 6B0DC3A137A; Wed, 21 Oct 2020 01:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 1jn6u4Mf4toB; Wed, 21 Oct 2020 01:31:07 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D859E3A1378; Wed, 21 Oct 2020 01:31:06 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4CGNxP1WnCz8yMB; Wed, 21 Oct 2020 10:31:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603269065; bh=8EEgKPAS/fA/NpSYromf3RsXTC+TQqZYneBkxk+Si3g=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FhK0p5Y2bppkwEAxr+l0a+/ZHg5patfP8zCb69Vz9U1j1cSNL8oEXjadrXObJwD0U kXvjlqSW8JchXAwgpL5iYzOBDIEtGJ9S/SfyzoBbpZyrsK4+q5+jj8ASVD24zvJElX 4/j4qlLjCmYDJNMer0HLH7sdWQLichX6CuPe3Cdd8TZFnkcqCTtFF/dRGniyM2gY/o a6CGuBGr9qb7hJ/3eZlyb630Cun781zqMJ0rqiVtHaliWDkEz8hJYrtTpfPdR+YDtn LO+f1MHDyZwLnHaQizHoCxn793RSFzfXAHrkeCqmTEj34vCti7ytGeZJm1ieZZuyMZ JkbgpmVOAZjIA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4CGNxP0LM3z1xpZ; Wed, 21 Oct 2020 10:31:05 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org" CC: "ipsec@ietf.org" Thread-Topic: AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04 Thread-Index: AQHWpxsmM6h8wTGDt0OBCAF0O7EDDamhml9Q Date: Wed, 21 Oct 2020 08:31:04 +0000 Message-ID: <29839_1603269065_5F8FF1C9_29839_37_11_787AE7BB302AE849A7480A190F8B9330315642A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20201020195628.GP39170@kduck.mit.edu> In-Reply-To: <20201020195628.GP39170@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 08:31:12 -0000 Hi Ben,=20 Thank you for the review. An updated version is available at: https://tools.ietf.org/html/draft-ietf-= ipsecme-ipv6-ipv4-codes-05.=20=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mardi 20 octobre 2020 21:56 > =C0=A0: draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org > Cc=A0: ipsec@ietf.org > Objet=A0: AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04 >=20 > Hi Med, >=20 > Not a whole lot to comment on here, but probably we should publish a > new revisionn to tidy things up before asking for IETF LC. >=20 > Thanks, >=20 > Ben >=20 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > % >=20 > We use the term "dual-stack" several times but it is not defined > explicitly. While this is certainly a common and fairly well-known > concept, perhaps we should drop an "IPv6/IPv4" in somewhere (or add > a reference? I'm not sure what reference would be good, offhand). [Med] Added text to explain this.=20 >=20 > There seem to be a few places where we use the phrase "status type" > without preceding "notification"; would it make sense to normalize > the language around "notification status type"? [Med] Agree. Fixed.=20 >=20 > Section 3 >=20 > Section 3.15.4 of [RFC7296] defines a generic notification error > type > that is related to a failure to handle an address assignment > request. > That error type does not explicitly allow an initiator to > determine > why a given address family is not assigned, nor whether it should > try > using another address family. INTERNAL_ADDRESS_FAILURE is a > catch- > all error type when an address-related issue is encountered by an > IKEv2 responder. >=20 > INTERNAL_ADDRESS_FAILURE does not provide sufficient hints to the > IKEv2 initiator to adjust its behavior. >=20 > I feel like we might also want to mention that (per 7296), "[t]he > responder sends INTERNAL_ADDRESS_FAILURE only if no addresses can be > assigned", and in many of the indicated use cases, the responder can > successfully assign *one* address, just not the full requested set, > so INTERNAL_ADDRESS_FAILURE is explicitly not useful. >=20 [Med] Tweaked that part to include the text you quoted. The explanation tex= t covers this case as well. > Section 5 >=20 > If the initiator is dual-stack, it MUST include both address > families > in its request (absent explicit policy/configuration otherwise). >=20 > By "both address families" we mean "both the IP6_ALLOWED and > IP4_ALLOWED notification status types"? Or are we talking about > something else, like a configuration payload? [Med] This is typically INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS attri= butes. The attributes are not listed as I would like to cover (the experime= ntal attribute) INTERNAL_IP6_PREFIX (or future attributes to achieve the sa= me functionality). Updated the text to point to Section 3.15 of 7296.=20=20 >=20 > It is perhaps surprising that we only impose the requirement for the > initiator to send these notifications specifically on dual-stack > initiators; a generic protocol update might typically impose a > requirement to always send your capabilities, whether dual-stack or > single-stack. [Med] These notifications are not sent by the initiator. The default behavi= our for a dual-stack initiator is to request both IPv4 and IPv6 connectivit= y. This behaviour can be restricted by policy. In such case, the initiator = will only request the connectivity that adheres to its local policy (e.g., = IPv6-only). In particular, the table seems to imply that the > initiator will still send something to indicate the requested AF in > the single-requested-AF case (which need not be dual-stack); is this > something other than IP_ALLOWED? [Med] Yes. This is inferred from the INTERNAL_* attributes listed above. Ad= ded NEW text to make this clear.=20 >=20 > If the initiator only receives one single notification > IP4_ALLOWED or > IP6_ALLOWED from the responder, the initiator MUST NOT send a > request > for an alternate address family not supported by the responder. >=20 > What is the scope of this "MUST NOT"? Other CREATE_CHILD_SA on the > same parent IKE SA? [Med] Yes. Made this change: s/request/subsequent request.=20 Ever to the same responder? >=20 > If a dual-stack initiator requests only an IPv6 prefix (or an > IPv4 > address) but only receives IP4_ALLOWED (or IP6_ALLOWED) > notification > status type from the responder, the initiator MUST send a request > for > IPv4 address(es) (or IPv6 prefix(es)). >=20 > [related to the earlier comment about only requiring dual-stack > initiators to send, at the start of the section we said that a dual- > stack initiator MUST include both address families...] [Med] This is about covering the case where a policy is provided and the de= fault behaviour is not followed.=20 >=20 > Section 6 >=20 > I think a phrasing like "since the IPv4/IPv6 capabilities of a node > are readily determined from the traffic it generates, this document > does not introduce any new security considerations compared to the > ones described in [RFC7296], which continue to apply" might be more > conventional. (I don't object to the current phrasing, though.) [Med] I prefer yours. Fixed. Thanks.=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 21 02:35:56 2020 Return-Path: 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 2326E3A14D0 for ; Wed, 21 Oct 2020 02:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 wlFSFdiiJLXv for ; Wed, 21 Oct 2020 02:35:53 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (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 DF3953A14CD for ; Wed, 21 Oct 2020 02:35:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eOeM8SPqZnPKIFFbJi6j9IAnRhftZLjdf9aR4373gAKAertcT5mev9uXTGxNCO+IZwPeG/pPYlrU+dBQnIKINQmmcXMOk6tZMzRwOvVz07k39/jk/AsK8+8r5EwAsgBWJhOajpycO85QLfvBhr5sTa9hkC2zuT3k2VNzfa6XFu2P4oXnGM2sKpvd6MYqTr9q4sebAFxsu3iI5NA8ccm3lQUVG6Kp50qZakR/19eZS7QlzQ8T06pR1Er/Xpp/VkMRDr+u6+fKw9u4WEKpF116GSKpIaTzTeErLLmOD0cClJWJnolLZHEh+QHEAS7zqBM6n3C1Ec6Wq3pnznUhz5/nWw== 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=jsSk+tEhIbDSzHMAMlWkVamU3eTMiXdxIZqIGFIY4kk=; b=aXyw0db3rtxCBJ/IG11YUmSxFk1VNTNvPpSSg++81L8aIZwplV6WgeUDEnx0gaVTFe1ihblYbPGKVR1nXfcWx/9eindqETt2KCFpl5rz0dAxqwOwuPlzG27DRwbkvNXGf6h0eNtMRTTLqhO3XSBczSq0uriv5Wy6/kGtD/yy1DZ4QIMPdscTPosAOc6ptTt8f0g66sT4dpddcyxbBY6JiPUwDBIDaiK3ToVrh3Fii/txxwkiW9bhmb8g870Ab8ZUCEDTkkWd4gc0RqhmsyZw/UnZerSRUi5QFLqZzCBttRz4L3mA8TZlgShmY870sQCF6LP79vjJUqQR/GXWDbptDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jsSk+tEhIbDSzHMAMlWkVamU3eTMiXdxIZqIGFIY4kk=; b=aXrKCN+0sd3KEQAtssTJENZf2RkXBKgs73VGwh9Y/cLKNgkyBIkTGpbKvk5ZkYR0ft9BDlxPtHxh7M4H7dEvNnfyeH+dJq4itu48C76eUatwjDL97tXtLEzZb423ryG7R82e46lWFn1S0k3laFUessv14qsm5Nu+w2llr3Mw4oA= Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (2603:10a6:20b:17::24) by AM6PR07MB5464.eurprd07.prod.outlook.com (2603:10a6:20b:84::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.15; Wed, 21 Oct 2020 09:35:48 +0000 Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::951:a4c3:7f39:e39c]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::951:a4c3:7f39:e39c%5]) with mapi id 15.20.3499.015; Wed, 21 Oct 2020 09:35:48 +0000 From: John Mattsson To: "ipsec@ietf.org" Thread-Topic: Comments on draft-corcoran-cnsa-ipsec-profile-01 Thread-Index: AQHWp42PuLrF7E5u00ynrc2Fc53HCg== Date: Wed, 21 Oct 2020 09:35:48 +0000 Message-ID: <4057D736-29E9-4059-B273-8B62A7067A15@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0158c9d-6b44-47a5-6474-08d875a4b1a8 x-ms-traffictypediagnostic: AM6PR07MB5464: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LNmkizZskiY22zqipd+LFlzOMFBYY754ivLH7t6V82ajAEoYKxIGqNk4vsTPg3ijv0GwXIWi9yMyFPgTXnlMyc9BxOKB9csJASx442TGmRROn66pPLfjgAHBjhMqDzB+xzZbL9PrfPkTzBCRJaQP/1C05vDjvbBX/je59mXst2mNicYOXYHJJar1jpVOpEv8fO44v6N0bywMhCTnHVZmryor/TDsfjfiPNs7vRn5A5V40XwU8DsnT9HnmwhvAE8opGGMZI1p5T2noyCn/YdDut3x0FoiGQSGJpKOnSgIWZi9GPtPbEl8o3nvPoXTE5fB8CPSeOf6Gnvf58OYSP1lrWX3at7UX+Ue4Se2+naM/jLi96iQ5K4gjLFKGlSDsB1/SEbknXFq01vU9X0wa9X+tXV1A8OnH67x60rC8LKf7aXtw3eIqITlICWOE3tdZOn13uy8P1VMA9OCcbZog+PCTQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(39860400002)(136003)(346002)(6486002)(83080400002)(71200400001)(36756003)(8676002)(83380400001)(26005)(6916009)(478600001)(2616005)(6512007)(186003)(66556008)(44832011)(5660300002)(66476007)(64756008)(33656002)(2906002)(6506007)(86362001)(66446008)(316002)(76116006)(91956017)(8936002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: zeNWAHu0rIWjBQCFQPSmSnTNnwmtLmQmZ/BfKkN01z6EoyBR1GpWvcufFPtp6NsOQIKoxNHWZpSF9Hk3EL0uR2rZ2+drLiAns7fB9lZS3+4OW59RdIa4euwMPoMPXRxgysUoI/hs86U4/FOEvb4bb4RXZPJZjozxSTBGa0S6uwhBgQwccAgfMusrlZvoofbhEf7/gjP4EF8yZfdJe6Uo8saJuXGSof+WeKOAH1VfRpEehurthPL1gN8HwWsz8RLUJW7r1KCH97ie03ir8dPQW7fx0w8Y36QAYv5PmXsIw5O6Vc0CKLhoB7l0FBNZB/4etbKKZuyEZTBBp3Lxh4OmduBRSU7QEO2RnJCZuu2BUVjhv16MWI2MLuhhdj3f7RSnbb3nRfGyUHbNuVQLhxBpHyKfOu721iJjggUnEv7zESzx6s16Z7DqnGO2ls0s7AC/vatSEIs45oRizspOj7AtS5DMiFSMNEbfvtg/MBdl4Aq0OHw1pik6N32JjOx++uW448lJjdTMLZQmjVVVsuPiywvbErATW20VXNmYqNoeSP0B1XAWNHenA6HwZLaLGpXvAI63JuXQKrk7XoD3fwqFgA++s57Wg+xvvxqEG8Ps6Jbr+NX8IumywXvybBRBfR1ymZ18DpE+XqBLxy+b4ge9jg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7C801136D0406E49A26147632B8EBF94@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB4584.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0158c9d-6b44-47a5-6474-08d875a4b1a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 09:35:48.8394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LomZDi5DniO1qb7h+egjfUbMQ+KZAAp2acG/RsVB/fUfl5QOyfCwxk+ceyQ4NOCdqSm6PiU8on1W/7yAioi6QRVWJfrntBbOmSsgzdcSDHM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5464 Archived-At: Subject: [IPsec] Comments on draft-corcoran-cnsa-ipsec-profile-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 09:35:55 -0000 SGksDQoNClRoYW5rcyBmb3IgcHJvZHVjaW5nIHRoaXMgYW5kIHRoZSBvdGhlciBJRVRGIGRvY3Vt ZW50cyBwcm9maWxpbmcgdGhlIENOU0Egc3VpdGUuIEkgdGhpbmsgaXQgaXMgdmVyeSBnb29kIHRv IGhhdmUgc3RyaWN0IHByb2ZpbGVzIHNwZWNpZmllZCBmb3IgYSBoaWdoIHNlY3VyaXR5IGxldmVs Lg0KDQogICAiVGhlIGFwcHJvdmVkIENOU0EgaGFzaCBmdW5jdGlvbiBmb3IgYWxsIHB1cnBvc2Vz IGlzIFNIQS0zODQsIGFzDQogICBkZWZpbmVkIGluIFtGSVBTMTgwXS4gIEhvd2V2ZXIsIFNIQS01 MTIgaXMgcmVjb21tZW5kZWQgZm9yIFBSRg0KICAgaW5zdGVhZCBvZiBTSEEtMzg0IGR1ZSB0byBh dmFpbGFiaWxpdHkuICBTZWUgU2VjdGlvbiA4IGJlbG93LiINCg0KICAgIlRoZSBuYW1lZCBVSSBz dWl0ZXMgdXNlIFNIQS01MTIgZm9yIFBSRiBzaW5jZSBTSEEtMzg0IGlzIG5vdCBsaXN0ZWQNCiAg IGFtb25nIHJlcXVpcmVkIFBSRiBvciBpbnRlZ3JpdHkgYWxnb3JpdGhtcyBpbiBbUkZDODI0N10s IHRoZSBzZWN1cml0eQ0KICAgbGV2ZWwgaXMgY29tcGFyYWJsZSwgYW5kIHRoZSBkaWZmZXJlbmNl IGluIHBlcmZvcm1hbmNlIGlzIG5lZ2xpZ2libGUuDQogICBIb3dldmVyLCBTSEEtMzg0IGlzIHRo ZSBvZmZpY2lhbCBDTlNBIGFsZ29yaXRobSBmb3IgY29tcHV0aW5nIGENCiAgIGNvbmRlbnNlZCBy ZXByZXNlbnRhdGlvbiBvZiBpbmZvcm1hdGlvbi4gIFRoZXJlZm9yZSwgU0hBLTM4NA0KICAgaW1w bGVtZW50YXRpb25zIGZvciBQUkYgb3IgaW50ZWdyaXR5IE1BWSBiZSB1c2VkLiIgDQoNClRoZSB3 b3JkaW5nIG1ha2VzIGl0IHNvdW5kIGxpa2UgU0hBLTUxMiBpcyByZWNvbW1lbmRlZCBvdmVyIFNI QS0zODQgd2hlbiBib3RoIGFyZSBhdmFpbGFibGUuIElzIHRoYXQgdGhlIGludGVudGlvbj8NCg0K SXMgaXQgY29ycmVjdCB0aGF0IFNIQS0zODQgaXMgc2lnbmlmaWNhbnRseSBsZXNzIGF2YWlsYWJs ZSB0aGFuIFNIQS01MTI/IFdoaWxlIHRoaXMgaXMgZGVmaW5pdGx5IGNvcnJlY3QgZm9yIFNTSCAo aHR0cHM6Ly9zc2gtY29tcGFyaXNvbi5xdWVuZGkuZGUvKSwgdGhlIElLRXYyIGltcGxlbWVudGF0 aW9ucyBJIGhhdmUgc2VlbiBpbXBsZW1lbnRzIGJvdGguIDNHUFAgVFMgMzMuMjEwIGhhcyBmb3Ig YSBsb25nIHRlcm0gcmVjb21tZW5kZWQgc3VwcG9ydCBvZiBTSEEtMzg0LCBvbmUgcmVhc29uIGJl aW5nIGFsaWdubWVudCB3aXRoIFN1aXRlIEIgYW5kIENOU0EuIElmIHRoZXJlIGlzIGEgYmlnIGRp ZmZlcmVuY2UgaW4gYXZhaWxhYmlsaXR5LCAzR1BQIG1pZ2h0IG5lZWQgdG8gdXBkYXRlIGl0J3Mg cHJvZmlsZS4NCg0KQ2hlZXJzLA0KSm9obg0KDQo= From nobody Wed Oct 21 10:07:15 2020 Return-Path: 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 929773A1281; Wed, 21 Oct 2020 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 sBGNI7SkbjoW; Wed, 21 Oct 2020 10:07:04 -0700 (PDT) Received: from mx01.puc.rediris.es (outbound6mad.lav.puc.rediris.es [130.206.19.149]) (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 707713A1265; Wed, 21 Oct 2020 10:07:04 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by mx01.puc.rediris.es with ESMTP id 09LH72iS005106-09LH72iT005106; Wed, 21 Oct 2020 19:07:02 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 07EE02121A; Wed, 21 Oct 2020 19:07:02 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QkE2SWtmSIUE; Wed, 21 Oct 2020 19:07:01 +0200 (CEST) Received: from [192.168.1.33] (135.red-79-150-250.dynamicip.rima-tde.net [79.150.250.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 004FC21219; Wed, 21 Oct 2020 19:06:58 +0200 (CEST) From: Rafa Marin-Lopez Content-Type: multipart/alternative; boundary="Apple-Mail=_71772B42-ED03-4C23-A8E2-7783B42728D0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 21 Oct 2020 19:06:57 +0200 References: <160328822041.23859.7847794438066881847@ietfa.amsl.com> Cc: Rafa Marin-Lopez , yang-doctors@ietf.org, ipsec@ietf.org, last-call@ietf.org, Gabriel Lopez , Fernando Pereniguez-Garcia To: i2nsf@ietf.org Message-Id: <684BB5B4-F54D-40D6-885E-3F8114DE33C3@um.es> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.167, helo=xenon41.um.es, mailFrom=rafa@um.es Authentication-Results: mx01.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.167 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM, 2:15:1:upct.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:content-type:mime-version:subject:date:references:cc:to:message-id; bh=wuRO1LHehRAZiC9LAQ3VcubTJq5au9CVs04jerKw/1w=; b=CGAaIR1Hv7ke9ThvVLMSUdNmzDdRG61JYB+y00tVgWyQtGKOe+uWdpFpCrYg22KB+V6mmAdcaMJm ypoaRq0rbIr9Ea5i+tAEYAoXUFHObswAqjqq38wU7WwTYqwoecviUSNvezsLUMNnGCbx1DfI0b14 Mbjx+gqsKTIqXEybXs7+uIveuRHpEzO8LG9L+qeqwk8Rjd/9e/13dOHJuWDhtrQlxd7gKCShsLqb lZ9UvUW4fKmYKoh/sEbdujNsx51NM/m+c/mHUiu00fI+VzDHQmYi4Bd5affqI7anShjw3tc3z6cz ITAFStO2/lknJTZPg0jXRvoX1WWamn8TFWvqIw== Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 17:07:07 -0000 --Apple-Mail=_71772B42-ED03-4C23-A8E2-7783B42728D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all: We have just submitted -10 with the changes we mentioned in our previous = e-mail about version -09. Now we have a feature ikeless-connection and if-feature = ikeless-notification in the notifications we have in ikeless module, so = that we ensure broader applicability of this module, as we already = explained in our previous e-mail.=20 Best Regards. > Inicio del mensaje reenviado: >=20 > De: internet-drafts@ietf.org > Asunto: New Version Notification for = draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt > Fecha: 21 de octubre de 2020, 15:50:20 CEST > Para: "Gabriel Lopez-Millan" , "Rafa Marin-Lopez" = , "Rafael Lopez" , "Fernando Pereniguez-Garcia" = >=20 >=20 > A new version of I-D, = draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt > has been successfully submitted by Rafa Marin-Lopez and posted to the > IETF repository. >=20 > Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection > Revision: 10 > Title: Software-Defined Networking (SDN)-based IPsec = Flow Protection > Document date: 2020-10-21 > Group: i2nsf > Pages: 92 > URL: = https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection= -10.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection > Htmlized: = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-10 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-10 >=20 > Abstract: > This document describes how to provide IPsec-based flow protection > (integrity and confidentiality) by means of an Interface to Network > Security Function (I2NSF) controller. It considers two main well- > known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- > host. The service described in this document allows the > configuration and monitoring of IPsec Security Associations (SAs) > from a I2NSF Controller to one or several flow-based Network = Security > Functions (NSFs) that rely on IPsec to protect data traffic. >=20 > The document focuses on the I2NSF NSF-facing interface by providing > YANG data models for configuring the IPsec databases (SPD, SAD, PAD) > and IKEv2. This allows IPsec SA establishment with minimal > intervention by the network administrator. It does not define any > new protocol. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_71772B42-ED03-4C23-A8E2-7783B42728D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all:

We have just = submitted -10 with the changes we mentioned in our previous e-mail about = version -09.

Now= we have a feature ikeless-connection and if-feature = ikeless-notification in the notifications we have in ikeless module, so = that we ensure broader applicability of this module, as we already = explained in our previous e-mail. 

Best Regards.


Inicio del mensaje reenviado:

De: = internet-drafts@ietf.org
Asunto: = New Version = Notification for = draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt
Fecha: = 21 de octubre de 2020, 15:50:20 = CEST
Para: = "Gabriel Lopez-Millan" <gabilm@um.es>, "Rafa = Marin-Lopez" <rafa@um.es>, "Rafael Lopez" <rafa@um.es>, "Fernando = Pereniguez-Garcia" <fernando.pereniguez@cud.upct.es>

A new version of I-D, = draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt
has been = successfully submitted by Rafa Marin-Lopez and posted to the
IETF repository.

Name: = draft-ietf-i2nsf-sdn-ipsec-flow-protection
Revision: 10
Title: = Software-Defined Networking (SDN)-based IPsec Flow Protection
Document date: 2020-10-21
Group:= = i2nsf
Pages: 92
URL: =            https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow= -protection-10.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection
Htmlized: =       https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-10
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-10

Abstract:
  This document describes how to provide = IPsec-based flow protection
  (integrity and = confidentiality) by means of an Interface to Network
=   Security Function (I2NSF) controller.  It considers two = main well-
  known scenarios in IPsec: (i) = gateway-to-gateway and (ii) host-to-
  host. =  The service described in this document allows the
=   configuration and monitoring of IPsec Security Associations = (SAs)
  from a I2NSF Controller to one or = several flow-based Network Security
  Functions = (NSFs) that rely on IPsec to protect data traffic.

  The document focuses on the I2NSF NSF-facing = interface by providing
  YANG data models for = configuring the IPsec databases (SPD, SAD, PAD)
=   and IKEv2.  This allows IPsec SA establishment with = minimal
  intervention by the network = administrator.  It does not define any
=   new protocol.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat



-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_71772B42-ED03-4C23-A8E2-7783B42728D0-- From nobody Thu Oct 22 10:39:13 2020 Return-Path: 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 1F4253A09DF; Thu, 22 Oct 2020 10:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 xEV4GoxmC7gX; Thu, 22 Oct 2020 10:39:09 -0700 (PDT) Received: from mx01.puc.rediris.es (outbound4mad.lav.puc.rediris.es [130.206.19.145]) (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 17BA33A09CD; Thu, 22 Oct 2020 10:39:08 -0700 (PDT) Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by mx01.puc.rediris.es with ESMTP id 09MHd6b9032242-09MHd6bA032242; Thu, 22 Oct 2020 19:39:06 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id 91F1824F52; Thu, 22 Oct 2020 19:39:06 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Zp55wxfglAge; Thu, 22 Oct 2020 19:39:06 +0200 (CEST) Received: from [192.168.1.33] (135.red-79-150-250.dynamicip.rima-tde.net [79.150.250.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon43.um.es (Postfix) with ESMTPSA id AC12C24F43; Thu, 22 Oct 2020 19:39:03 +0200 (CEST) From: Rafa Marin-Lopez Content-Type: multipart/alternative; boundary="Apple-Mail=_EFEC2F4A-0BF7-418B-9A9A-7040280BE044" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 22 Oct 2020 19:39:02 +0200 References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> Cc: Rafa Marin-Lopez , Gabriel Lopez , Fernando Pereniguez-Garcia , ipsec@ietf.org, last-call@ietf.org, yang-doctors@ietf.org To: i2nsf@ietf.org Message-Id: X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.170, helo=xenon43.um.es, mailFrom=rafa@um.es Authentication-Results: mx01.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.170 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM, 2:15:1:upct.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:content-type:mime-version:subject:date:references:cc:to:message-id; bh=JXTrcbYCIhgi+BJc2/XH/o3OwqeCgof+ncrWhZoF7K0=; b=tXbJSztExe4h2taWFOMPGaX450ZTowkeIlE63nM5qsTn60Jl7WHA2RzvO3JQXZCEpWE6c5jT9pRI +87Le19k05n96FlJBCqYi3G4HXTv5HW8e+CgQ8YHQaU/F1zWZwaj/rF5qkTRUrR0ksoFUpl0Ncsw QoZ1DQLTcq4hbKN1fNYbiJyXKSlsBMoy6hHw4cyCK7Nnk1vEW8kUqAOZJ+RbPxcGCfaG1loHNsub OyNvCWSzgmEb4c0K1PuAW2dN9ee7gYAJdu/lLdNwRdHmcSXpa4feeD220LEgNC+TUCpNNguUD4Au edDbUlA+zeHsei3D7CaNyZqxnokTeUbNZ8cnSg== Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 17:39:11 -0000 --Apple-Mail=_EFEC2F4A-0BF7-418B-9A9A-7040280BE044 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all: After receiving a suggestion to make things clearer in the feature = ikeless-notification description, we have just uploaded a new version = -11 with a minor change to add the following text: feature ikeless-notification {=20 description=20 "This feature indicates that the server supports generating notifications in the ikeless module. =20 To ensure broader applicability of this module,=20 the notifications are marked as a feature.=20 For the implementation of ikeless case,=20 the NSF is expected to implement this=20 feature."; }=20 Best Regards. > Inicio del mensaje reenviado: >=20 > De: internet-drafts@ietf.org > Asunto: New Version Notification for = draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt > Fecha: 22 de octubre de 2020, 15:32:50 CEST > Para: "Fernando Pereniguez-Garcia" , = "Rafael Lopez" , "Gabriel Lopez-Millan" , = "Rafa Marin-Lopez" >=20 >=20 > A new version of I-D, = draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt > has been successfully submitted by Rafa Marin-Lopez and posted to the > IETF repository. >=20 > Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection > Revision: 11 > Title: Software-Defined Networking (SDN)-based IPsec = Flow Protection > Document date: 2020-10-22 > Group: i2nsf > Pages: 92 > URL: = https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection= -11.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection > Htmlized: = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-11 >=20 > Abstract: > This document describes how to provide IPsec-based flow protection > (integrity and confidentiality) by means of an Interface to Network > Security Function (I2NSF) controller. It considers two main well- > known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- > host. The service described in this document allows the > configuration and monitoring of IPsec Security Associations (SAs) > from a I2NSF Controller to one or several flow-based Network = Security > Functions (NSFs) that rely on IPsec to protect data traffic. >=20 > The document focuses on the I2NSF NSF-facing interface by providing > YANG data models for configuring the IPsec databases (SPD, SAD, PAD) > and IKEv2. This allows IPsec SA establishment with minimal > intervention by the network administrator. It does not define any > new protocol. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_EFEC2F4A-0BF7-418B-9A9A-7040280BE044 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all:

After receiving = a suggestion to make things clearer in the feature ikeless-notification = description, we have just uploaded a new version -11 with a minor change = to add the following text:

feature ikeless-notification = { 
            = description 
        =         "This feature indicates that = the server supports
    =             generating notifications in = the ikeless module.
        =         
    =             To ensure broader = applicability of this module, 
    =             the notifications are marked = as a feature. 
        =         For the implementation of ikeless = case, 
          =       the NSF is expected to implement = this 
          =       feature.";
    =     } 

Best Regards.

Inicio = del mensaje reenviado:

De: internet-drafts@ietf.org
Asunto: = New Version = Notification for = draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
Fecha: = 22 de octubre de 2020, 15:32:50 = CEST
Para: = "Fernando Pereniguez-Garcia" = <fernando.pereniguez@cud.upct.es>, "Rafael Lopez" = <rafa@um.es>, = "Gabriel Lopez-Millan" <gabilm@um.es>, "Rafa Marin-Lopez" <rafa@um.es>

A new version of I-D, = draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
has been = successfully submitted by Rafa Marin-Lopez and posted to the
IETF repository.

Name: = draft-ietf-i2nsf-sdn-ipsec-flow-protection
Revision: 11
Title: = Software-Defined Networking (SDN)-based IPsec Flow Protection
Document date: 2020-10-22
Group:= = i2nsf
Pages: 92
URL: =            https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow= -protection-11.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection
Htmlized: =       https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-11
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-11

Abstract:
  This document describes how to provide = IPsec-based flow protection
  (integrity and = confidentiality) by means of an Interface to Network
=   Security Function (I2NSF) controller.  It considers two = main well-
  known scenarios in IPsec: (i) = gateway-to-gateway and (ii) host-to-
  host. =  The service described in this document allows the
=   configuration and monitoring of IPsec Security Associations = (SAs)
  from a I2NSF Controller to one or = several flow-based Network Security
  Functions = (NSFs) that rely on IPsec to protect data traffic.

  The document focuses on the I2NSF NSF-facing = interface by providing
  YANG data models for = configuring the IPsec databases (SPD, SAD, PAD)
=   and IKEv2.  This allows IPsec SA establishment with = minimal
  intervention by the network = administrator.  It does not define any
=   new protocol.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat



-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_EFEC2F4A-0BF7-418B-9A9A-7040280BE044-- From nobody Fri Oct 23 14:18:49 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ECB3A1183; Fri, 23 Oct 2020 14:15:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348775142.5087.11734323133009678567@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:51 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 109 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:55 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (2:00 requested) Tuesday, 17 November 2020, Session III 1600-1800 Room Name: Room 6 size: 506 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tls acme Technology Overlap: cfrg People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Oct 28 19:49:31 2020 Return-Path: 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 692383A0975; Wed, 28 Oct 2020 19:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NVmGsZrQ9dzQ; Wed, 28 Oct 2020 19:49:28 -0700 (PDT) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211313A0969; Wed, 28 Oct 2020 19:49:28 -0700 (PDT) Received: by mail-vk1-xa2d.google.com with SMTP id k125so385773vka.11; Wed, 28 Oct 2020 19:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sruJXpzaeu5Gm29mz4gUEGcFTVmjlsXsZSgjPuQiQL8=; b=FPv+1kkKlRE6TluPJBYwYe+r8Q+ZlvaV0Eqt/VCJS7vmb8vzmHqdMCH2yqCC7i0zch MJKH3Ec5qJgZsrLVwyulLlBE2iu6UN9NfveDEDuWe53QmltpOJ7EDRCBYyywTC4zSijm wIWjuaTKn4TkN68zU+B5R5jVq9sYWZ+UErXYTY4f7fY/9Whyo1vKtRcWPlHAzUjTSKLM wp7rJNe6f7so5/6JwS0vgckySDY5P2rlNi/Px+uyqD76NeuACKdxOIukl2nger7OiY+O i50cdaAKsnCok7N41ZpdsZvWEyBcpP1NCMQZdjzgUfQGxX7WQ3XGC7b1Gr820f/hSbDV 9H7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sruJXpzaeu5Gm29mz4gUEGcFTVmjlsXsZSgjPuQiQL8=; b=LXz0xwaxbbTpOZBNJFicXqvS2k8EvZwJXdrTYLLwIQgTFIuwd3Ld7BhvLQV4sKeQxW y/jEPPYY1UWriznIMcmS6T44J96h38gZrBgLnlHur3guLJyr1vevpjnbebOLhl2fQMS5 EScjq3GVjBrhiG6ivYQEqwy/PQRrqpqdJ0KTap+gLybdaa23p07uBhqw+SVc3leSxDBy tr1BtQlALOPoL/d0EwQBMpyA8bPdZnXZqeVbvH/7dFo2XuJGOSj9iz3q8AMrV2tjdhW0 FI5BWZ2uMkgAcui3wOAPldzmoJBbltWAHkzG/k/eQRZObpuDYvCgK7EcJDEMqyYwxvtV aGbA== X-Gm-Message-State: AOAM531ZR6dGECNWnA5cdq/zEWuhpBF3G+KLr1JBt8nXE2Oc7pxdJTjm u5j0sEaB2t7tNQF0ClPYc02Bec33lL2ZTwMwDck= X-Google-Smtp-Source: ABdhPJwfLXt8jJ2L2S2bR00wntjrLO+4PRHd52tc0xhB4BPzutS+iXHwe07BT0LmGHrepa0lwpAzphQerNpIo38NaD4= X-Received: by 2002:a1f:4189:: with SMTP id o131mr1834695vka.6.1603939766917; Wed, 28 Oct 2020 19:49:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Wed, 28 Oct 2020 22:49:15 -0400 Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: "ipsec@ietf.org" , lwip@ietf.org Content-Type: multipart/alternative; boundary="0000000000000c5d3905b2c6543f" Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 02:49:30 -0000 --0000000000000c5d3905b2c6543f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Scott, Thank you very much for the review. The review was extremely useful and I believe the text has been updated accordingly. Please find below more details on the updates. Yours, Daniel On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) wrote: > Comments: > > > > - I have issues with the draft=E2=80=99s emphasis on fixed SPI values.= One > reason for the SPI value is to handle key updates cleanly; during the > transition, the SPI can be used to indicate whether the packet was > encrypted with the previous set of key or the new ones. As we really = don=E2=80=99t > want to discourage rekeying I would suggest that, instead of talking s= o > much about fixed SPIs, you instead address how to do nonrandom SPIs (f= or > example, by having the top 3 bytes of the inbound SPI being the SAD en= try, > and the lower byte being the rekey index). > > Thanks, the use of a fixed SPI is an extreme case, we may have focused a bit too much. We now provide more generic text where the number of SPIs could be limited but not necessarily limited to 1. We also include the ability to handle rekey to be considered when limiting the number of SPIs. I found this idea very nice thanks! In addition, to the SPI section we also re-inforced the need to manage the keys in the security consideration section and the necessity to rekey. Here is the current text: SPI section has been updated as follows: """ However, for some constrained nodes, generating and handling 32 bit random SPI may consume too much resource, in which case SPI can be generated using predictable functions or end up in a using a subset of the possible values for SPI. In fact, the SPI does not necessarily need to be randomly generated. A node provisioned with keys by a third party - e.g. that does not generate them - and that uses a transform that does not needs random data may not have such random generators. However, non random SPI and restricting their possible values MAY lead to privacy and security concerns. As a result, this alternative should be considered for devices that would be strongly impacted by the generation of a random SPI and after understanding the privacy and security impact of generating non random SPI. When a constrained node limits the number of possible SPIs this limit should both consider the number of inbound SAs - possibly per IP addresses - as well as the ability for the node to rekey. SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the SAD entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. """ The security consideration has been updated as follows: """ The security of a communication provided by ESP is closely related to the security associated to the management of that key. This usually include mechanisms to prevent a nonce to repeat for example. When a node is provisioned with a session key that is used across reboot, the implementer MUST ensure that the mechanisms put in place remain valid across reboot as well. It is RECOMMENDED to use ESP in conjunction of key management protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 [RFC7815]. Such mechanisms are responsible to negotiate fresh session keys as well as prevent a session key being use beyond its life time. When such mechanisms cannot be implemented and the session key is, for example, provisioned, the nodes SHOULD ensure that keys are not used beyond their life time and that the appropriated use of the key remains across reboots. When a node generates its key or when random value such as nonces are generated, the random generation MUST follow [RFC4086]. """ > > - > - =E2=80=9CValues 0-255 SHOULD NOT be used.=E2=80=9D; shouldn=E2=80=99= t that be MUST NOT? Can > you think of an advantage a device might have for using a SPI in that > region? > > We mentioned SHOULD NOT in order to preserve the future usage - if ever these values would be allocated. MUST NOT seems more appropriated and we did not have any other reasons for a SHOULD NOT. This has been changed into the new version. > > - > > The use of fix SPI MUST NOT be considered as a way to avoid strong random > generators. Such generator will be required in order to provide strong > cryptographic protection=E2=80=9D; actually, if the IPsec implementation = doesn=E2=80=99t > actually generate its own keys (that is, it relies on an external service > to provide them), and the transform itself doesn=E2=80=99t require random= data (CBC > can be implemented securely without one), then the IPsec implementation > doesn=E2=80=99t actually need an CSPRNG. > The current text presented it in another way. The former text seems to explain that random was necessary for the generation of SPI. The current text has been updated to explain that we may have nodes without random generators. I am wondering how the IV is generated with CBC without random generator. > > - SN based on clocks; one issue that is not addressed is that standard > receivers are tuned for an increment of one-per-packet; if the sender = uses > increments significantly larger than that, and packets are reordered, = the > receiver is more likely to reject valid packets because they fell outs= ide > the window. > > We have added this. As suggested by Valery, we also added some text regarding ESN in the case clock is being used for SN. > > - > - One issue you do not address (but I believe you should) is the fact > that some cryptographical transforms are more resilient for key reuse = (e.g. > because you use a fixed key, and don=E2=80=99t change it after a reboo= t) than > others. In particular, both GCM and ChaCha20-Poly1305 have real probl= ems > when that happens, and should be avoided. > > This is correct we added some text and recommended that in these cases AES-GCN-SIV may be used. The following text has been added in the Cryptographic suite section. """ 2. Resilience to nonce re-use: Some transforms -including AES-GCM - are very sensitive to nonce collision with a given key. While the generation of the nonce may prevent such collision during a session, the mechanisms are unlikely to provide such protection across reboot. This causes an issue for devices that are configured with a key. When the key is likely to be re-used across reboots, it is RECOMMENDED to consider transforms that are nonce misuse resistant such as AES-GCM-SIV for example[RFC8452] """ > > - > > > Typos: > > - a random SPI may consume to much -> too much > - fix SPI -> fixed SPI > - can be alleviate -> can be alleviated > - algorythm -> algorithm > - > > fixed > > - > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --=20 Daniel Migault Ericsson --0000000000000c5d3905b2c6543f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Scott,=C2=A0

Thank you ve= ry much for the review. The review was extremely useful and I believe=C2=A0= the text has been updated accordingly. Please find below=C2=A0more details = on the updates.

Yours,=C2=A0
Daniel

On Sun, Jul = 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:

Comments:

=C2=A0

  • I have issues with the draft=E2=80=99s emphas= is on fixed SPI values.=C2=A0 One reason for the SPI value is to handle key= updates cleanly; during the transition, the SPI can be used to indicate whether the packet was encrypted with the previous set of key or the new o= nes.=C2=A0 As we really don=E2=80=99t want to discourage rekeying I would s= uggest that, instead of talking so much about fixed SPIs, you instead addre= ss how to do nonrandom SPIs (for example, by having the top 3 bytes of the inbound SPI being the SAD entry, and the low= er byte being the rekey index).
<= mglt>
Thanks, the use of a fixed SPI is an extreme case, we ma= y have focused a bit too much. We now provide more generic text where the n= umber of SPIs could be=C2=A0 limited but not necessarily limited to 1. We a= lso include the ability to handle rekey to be considered when limiting the = number of SPIs. I found=C2=A0this idea very nice thanks!
In addit= ion, to the SPI section we also re-inforced the need to manage the keys in = the security=C2=A0consideration section and the necessity to rekey. Here is= the current text:

SPI section has been updated as= follows:

"""
=C2=A0 Howe= ver, for some constrained nodes, generating and handling 32 bit
= =C2=A0 =C2=A0random SPI may consume too much resource, in which case SPI ca= n be
=C2=A0 =C2=A0generated using predictable functions or end up in a u= sing a subset
=C2=A0 =C2=A0of the possible values for SPI.=C2=A0 In fact= , the SPI does not
=C2=A0 =C2=A0necessarily need to be randomly generate= d.=C2=A0 A node provisioned with
=C2=A0 =C2=A0keys by a third party - e.= g. that does not generate them - and that
=C2=A0 =C2=A0uses a transform = that does not needs random data may not have such
=C2=A0 =C2=A0random ge= nerators.=C2=A0 However, non random SPI and restricting their
=C2=A0 =C2= =A0possible values MAY lead to privacy and security concerns.=C2=A0 As a=C2=A0 =C2=A0result, this alternative should be considered for devices tha= t would
=C2=A0 =C2=A0be strongly impacted by the generation of a random = SPI and after
=C2=A0 =C2=A0understanding the privacy and security impact= of generating non
=C2=A0 =C2=A0random SPI.

=C2=A0 =C2=A0When a c= onstrained node limits the number of possible SPIs this limit
=C2=A0 =C2= =A0should both consider the number of inbound SAs - possibly per IP
=C2= =A0 =C2=A0addresses - as well as the ability for the node to rekey.=C2=A0 S= PI can
=C2=A0 =C2=A0typically be used to pr= oceed to clean key update and the SPI value
=C2=A0 =C2=A0may be used to = indicate which key is being used.=C2=A0 This can typically
=C2=A0 =C2=A0= be implemented by a SPI being encoded with the SAD entry on a subset
=C2= =A0 =C2=A0of bytes (for example 3 bytes), while the remaining byte is left = to
=C2=A0 =C2=A0indicate the rekey index.
"""
The security consideration has been updated as follows:

"""
=C2=A0 The security of a communicatio= n provided by ESP is closely related to
=C2=A0 =C2=A0the security associ= ated to the management of that key.=C2=A0 This usually
=C2=A0 =C2=A0incl= ude mechanisms to prevent a nonce to repeat for example.=C2=A0 When a
= =C2=A0 =C2=A0node is provisioned with a session key that is used across reb= oot,
=C2=A0 =C2=A0the implementer MUST ensure that the mechanisms put in= place remain
=C2=A0 =C2=A0valid across reboot as well.

=C2=A0 = =C2=A0It is RECOMMENDED to use ESP in conjunction of key management
=C2= =A0 =C2=A0protocols such as for example IKEv2 [RFC7296] or minimal IKEv2=C2=A0 =C2=A0[RFC7815].=C2=A0 Such mechanisms are responsible to negotiate= fresh
=C2=A0 =C2=A0session keys as well as prevent a session key being = use beyond its
=C2=A0 =C2=A0life time.=C2=A0 When such mechanisms cannot= be implemented and the
=C2=A0 =C2=A0session key is, for example, provis= ioned, the nodes SHOULD ensure
=C2=A0 =C2=A0that keys are not used beyon= d their life time and that the
=C2=A0 =C2=A0appropriated use of the key = remains across reboots.

=C2=A0 =C2=A0When a node generates its key o= r when random value such as nonces are
=C2=A0 =C2=A0generated, the rando= m generation MUST follow [RFC4086].
"""
<= div>
</mglt>=C2=A0
  • =E2=80=9CValues 0-255 SHO= ULD NOT be used.=E2=80=9D; shouldn=E2=80=99t that be MUST NOT?=C2=A0 Can you think of an advantag= e a device might have for using a SPI in that region?
<mglt>

We mentioned SHOULD NOT in order to preserve the future u=
sage - 
if ever these values would be allo=
cated. MUST NOT seems more appropriated and we did not have 
any other reasons for a SHOULD NOT. This has been change=
d into 
the new version.

</mglt>=C2=A0
  • <= /u>

The use of fix SPI MUST NOT be considered as a way to avoid st= rong random generators.=C2=A0 Such generator will be required in order to provide strong cryptographic protec= tion=E2=80=9D; actually, if the IPsec implementation doesn=E2=80=99t actually generat= e its own keys (that is, it relies on an external service to provide them),= and the transform itself doesn=E2=80=99t require random data (CBC can be implemented securely without one), then the IPsec implementati= on doesn=E2=80=99t actually need an CSPRNG.

<mglt>
The current text presented it in another wa= y. The former text seems to explain that random was necessary for the gener= ation of SPI. The current text has been updated to explain that we may have= nodes without random generators.=C2=A0

I am wonde= ring how the IV is generated with CBC without random generator.=C2=A0
=
</mglt>=C2=A0

  • SN based on clocks; one issue that is not add= ressed is that standard receivers are tuned for an increment of one-per-pac= ket; if the sender uses increments significantly larger than that, and packets are reordered, the receiver is more likely to reject val= id packets because they fell outside the window.
<mglt>
We have added this. As suggested by Val= ery, we also added some text regarding ESN in the case clock is being used = for SN.
</mglt>=C2=A0
  • One issue you do not address (but I believe you should) is the fa= ct that some cryptographical transforms are more resilient for key reuse (e= .g. because you use a fixed key, and don=E2=80=99t change it after a reboot) than others.=C2=A0 In particular, both GCM and C= haCha20-Poly1305 have real problems when that happens, and should be avoide= d.
<mglt>
This is correct = we added some text and recommended that in these cases AES-GCN-SIV may be u= sed.=C2=A0

The following text has been added in th= e Cryptographic suite section.
"""
=C2= =A02.=C2=A0 Resilience to nonce re-use: Some transforms -including AES-GCM = -
=C2=A0 =C2=A0 =C2=A0 =C2=A0are very sensitive to nonce collision with = a given key.=C2=A0 While
=C2=A0 =C2=A0 =C2=A0 =C2=A0the generation of th= e nonce may prevent such collision during a
=C2=A0 =C2=A0 =C2=A0 =C2=A0s= ession, the mechanisms are unlikely to provide such protection
=C2=A0 = =C2=A0 =C2=A0 =C2=A0across reboot.=C2=A0 This causes an issue for devices t= hat are
=C2=A0 =C2=A0 =C2=A0 =C2=A0configured with a key.=C2=A0 When the= key is likely to be re-used
=C2=A0 =C2=A0 =C2=A0 =C2=A0across re= boots, it is RECOMMENDED to consider transforms that are
=C2=A0 =C2=A0 = =C2=A0 =C2=A0nonce misuse resistant such as AES-GCM-SIV for example[RFC8452= ]
"""
</mglt>=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
  • =C2=A0
=C2=A0

<= /p>

Typos:

  • a random SPI may consume to much -> too mu= ch
  • fix SPI -> fixed SPI<= u>
  • can be alleviate -> can = be alleviated
  • algorythm -&g= t; algorithm
  • =C2=A0<= /li>
<mglt>
fixed
</mglt>=C2=A0
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--
Daniel Migault
Ericsson
--0000000000000c5d3905b2c6543f-- From nobody Wed Oct 28 19:49:56 2020 Return-Path: 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 85D993A0AB5; Wed, 28 Oct 2020 19:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Rh3vt3Gc7RLz; Wed, 28 Oct 2020 19:49:39 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927E43A0A4F; Wed, 28 Oct 2020 19:49:37 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id d19so709706vso.10; Wed, 28 Oct 2020 19:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dmF6LfAELIjPMa5cN+B2yRQC0FO55sCmalSsgzVfZG4=; b=OFjq0fm0Pxt691AkpXNRPV4LNbT/pfOqNopmYZrIFlTEK2zjLudgmuXi+NfLL/Z/iF sZpc7/BqtnyYjzen75+Q/aXeVr38doPyPrX3uRp8klfNv7FQ3GUfTgpG6YF6ZfOweNPJ OJHRmJCBM1F3iTe9UehSPjq8K0vuNDvoOhSoqeLG1QPUxsdqljswAuReAiS2QZ5uP9ug cTGb03mJjmdx3fceQlkvctsOBlZ2N71klFrZmrZQeuVK3oH0FbbXKwj2McfiOho78xsX 6I+adKcbqSkSEVXVG+iWVcMBC3TEz8E2IqqAYQr0QDb/Kd7vVkhdzID/8IAy4IA57wwA zVlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dmF6LfAELIjPMa5cN+B2yRQC0FO55sCmalSsgzVfZG4=; b=TqnTQSyxqZ956w0JksERIKan9TgLJ1z8AjBcJpO9UgJLzd9Jef7YOE6wGwizxfpzye laNPTXxkk2xoQJp9KwyX+fpWdlvw2vmlxmmdCENHjXd1kTec2mM6115QawLjFFM5QGun eaBybWj+i5qYlSrhUzIkSSeoYA/ysEevKy023FNjqwKC6oH6gFOsOmQNlfJTUndLadxm 1cylN/1oMp4XmZDPL+yJMgk3QybvSt8ZAXTFELypPZl1y622Pk3UWJVK3rDCcOWpP00e rba+V07Hqw/OozOy/mQpituMZ1V9kCbQ9OmQ7EAuvJN81CKU3/dNvJ6bMA6PspVkbkle N8Lw== X-Gm-Message-State: AOAM533c1m5+5U7qJ3H6GoKCcZXaYAgWlUWiRgcJyJPYtwfhPrSMhjD6 E97dJgaYi4VB0XJb2LrvhXQjCR38Eht1+ZJwywuFDQms1aFhew== X-Google-Smtp-Source: ABdhPJyrcrZt3corghA8WlkQceWlT3iEev2z5Smjdnmvxi7M48LGhE8ALaRt3KqdV3oTBYeBu6J+pshPugBr7MVTDA0= X-Received: by 2002:a67:b405:: with SMTP id x5mr1606926vsl.4.1603939776496; Wed, 28 Oct 2020 19:49:36 -0700 (PDT) MIME-Version: 1.0 References: <060501d5a9da$b8552490$28ff6db0$@gmail.com> In-Reply-To: <060501d5a9da$b8552490$28ff6db0$@gmail.com> From: Daniel Migault Date: Wed, 28 Oct 2020 22:49:25 -0400 Message-ID: To: Valery Smyslov Cc: Tobias Guggemos , lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="0000000000009e886a05b2c65413" Archived-At: Subject: Re: [IPsec] Review of draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 02:49:49 -0000 --0000000000009e886a05b2c65413 Content-Type: text/plain; charset="UTF-8" Hi Valery, Thank you very much for the review. Your review was very helpful to improve the draft and we believe the new version has taken the reviews into account. Please find a more detailed description of the updates led by your reviews. Yours, Daniel On Tue, Dec 3, 2019 at 8:08 AM Valery Smyslov wrote: > Hi, > > I reviewed draft-ietf-lwig-minimal-esp-00. In general I think that the > document > provides useful guidelines on how ESP can be implemented on constrained > devices. > > General comment: the draft uses RFC2119 requirement language in several > places, > and it is not always clear whether it is just a repetition of the RFC4301 > requirements > or a new requirement imposed by this document. In general, I think it's > better not to include > the existing RFC4301/4303 requirements in the draft or make it absolutely > clear that these are not > new requirements if you need to mention them (adding a reference to a > corresponding section > in the RFCs). > We initially took this text as an editorial choice to quote or refer to useful original text. I understand it brings some confusion - unless we read it very carefully. I am tempted to agree that it might be clearer now that we removed the quoted text. In fact it is just commented so it would be easy to move back, if that would raise any concerns. > > Another general comment: sections 3-7 discuss how the corresponding ESP > packet fields > can be tweaked to deal with low resource devices. I think that for the > sake of clarity > the suggested measures must be summarized in each of these sections. > Currently > these sections contain quite a lot of discussion and no clear conclusions > what > is OK to do and in what situations. I think document will be more clear if > such > conclusions are put at the end of each section (currently some advises are > spread > over them). > > We tried to clarify the text. One difficulty is that recommendations can easily change over the use cases. For section 3, we mentioned that tweak applies to constraint devices for which handling 32 bit random SPI would cause an issue. I think that is now clearer. We also re-order some of the paragraphs so the discussion of a specific use cases remains localized. For section 4 we mentioned the SN that has an always increasing source may take advantage of it. We clarified that other recommendations concern all devices. For section 5 - 6 - 7 seems relatively generic. If you believe we could improve this, feel free to let us know. > > Specific comments: > > Section 3. > > When fix SPI are used, > it is RECOMMENDED the constraint node has as many SPI values as ESP > session per host IP address, and that SA lookup includes the IP > addresses. > > This is probably wrong if we take into considerations that SA may be > rekeyed. > Some words should be added either prohibiting rekeying ESP SAs in this case > or discussing that in case of rekey one will consume additional SPI values > for in fact the same SA. > > I agree. We now clearly mention that the number of SPI a peer needs to handle depends on the number of session and the rekying of these SA. We also moved the discussion of fixed SPIs to something more generic in order to provide more generic guidances. We reinforced also the need to rekey - and managed the keys in the security consideration section. SPI section has been updated as follows: """ However, for some constrained nodes, generating and handling 32 bit random SPI may consume too much resource, in which case SPI can be generated using predictable functions or end up in a using a subset of the possible values for SPI. In fact, the SPI does not necessarily need to be randomly generated. A node provisioned with keys by a third party - e.g. that does not generate them - and that uses a transform that does not needs random data may not have such random generators. However, non random SPI and restricting their possible values MAY lead to privacy and security concerns. As a result, this alternative should be considered for devices that would be strongly impacted by the generation of a random SPI and after understanding the privacy and security impact of generating non random SPI. When a constrained node limits the number of possible SPIs this limit should both consider the number of inbound SAs - possibly per IP addresses - as well as the ability for the node to rekey. SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the SAD entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. """ The security consideration has been updated as follows: """ The security of a communication provided by ESP is closely related to the security associated to the management of that key. This usually include mechanisms to prevent a nonce to repeat for example. When a node is provisioned with a session key that is used across reboot, the implementer MUST ensure that the mechanisms put in place remain valid across reboot as well. It is RECOMMENDED to use ESP in conjunction of key management protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 [RFC7815]. Such mechanisms are responsible to negotiate fresh session keys as well as prevent a session key being use beyond its life time. When such mechanisms cannot be implemented and the session key is, for example, provisioned, the nodes SHOULD ensure that keys are not used beyond their life time and that the appropriated use of the key remains across reboots. When a node generates its key or when random value such as nonces are generated, the random generation MUST follow [RFC4086]. """ > When used indoor, the privacy information is stored in the encrypted > data and as such does not leak privacy. > > I cannot parse this :-) > > Not entirely sure what was the initial intent, but the current text mentions that privacy implication should also consider the exposure of the communication. Typically, an indoor sensor with local IP address may leak little privacy sensitive information with its SPI. Though this is not entirely no information. The current text is now: """ These devices, due to there limitations, are expected to provide limited information and how the use of non random SPI impacts privacy requires further analysis. Typically temperature sensors, wind sensors, used outdoor do not leak privacy sensitive information. When used indoor, privacy leakage outside the local network may be limited. """ > Such packet will not be rejected due to an SPI mismatch, but instead > after the signature check which requires more resource and thus make > DoS more efficient, especially for devices powered by batteries. > > I think this a very good argument against fixed (predictable) SPIs. > In fact, after reading through this section it seems to me that the > conclusion must be - predictable (fixed) SPIs SHOULD NOT be used. > > The current text does not mention fixed SPI anymore, but considers SPIs that are non randomly generated. We also clarify the text to say. Generate randomly the SPI when you can. Only if you really cannot consider the alternative. The reason I would not like to have SHOULD NOT is that it is still better to have IPsec with non randomly generated SPIs than no security. That said, we do not want to encourage non randomly generated SPIs. Values 0-255 SHOULD NOT be used. > > I believe these values MUST NOT be used with IPsec ESP, no? > Why "SHOULD NOT"? The values from this range are reserved > for other protocols utilizing ESP (e.g. SPI (1) was used in SKIP). > > This has been changed as well. Originally we had SHOULD NOT as not to prevent future usage with the reserved values. We set it to MUST NOT. > Section 4. > > I see no discussion regarding using ESN. I think there is generally no > point > to use ESN for constrained devices, but it can be useful if clock is used > to generate (E)SN, as suggested in the draft. In this case 64-bit numbers > can make sure that no two packets will be sent with the same ESN > (provided the clock has high resolution). > > This is correct that the former version did not provide indications on the use of ESN. This has been added in the new version. It is hard to recommend one or the other but what we would like is to emphasize is that incrementing the life time of the session with ESN is generally a bad idea and that providing a rekey mechanism is probably a better option. here is the text we come to: """ SN can be encoded over 32 bits or 64 bits - known as Extended Sequence Number (ESN). As per [RFC4303], the support ESN is not Migault & Guggemos Expires May 1, 2021 [Page 6] ^L Internet-Draft Minimal ESP October 2020 mandatory. The determination of the use of ESN is based on the largest possible value a SN can take over a session. When SN is incremented for each packet, the number of packets sent over the life time of a session may be considered. However, when the SN is incremented differently - such as when time is used - the maximum value SN needs to be considered instead. Note that the limit of messages being sent is primary determined by the security associated to the key rather than the SN. The security of the key used to encrypt decreases with the each message being sent and a node MUST ensure the limit is not reached - even though the SN would permit it. In a constrained environment, it is likely that the implementation of a rekey mechanism is preferred over the use of ESN. """ > Section 5. > > The purpose of padding is to respect the 32 bit alignment of ESP. > > It is not an accurate statement, the padding is also used when encryption > transform requires the input to be a multiple of some number of bytes. > Many modern transforms (based on GCM, CCM, CTR modes) don't have such > a requirement, but some (e.g. based on CBC mode) do have. > > Correct. We fixed with the following text: """ The purpose of padding is to respect the 32 bit alignment of ESP or block size expected by an encryption transform - such as AES-CBC for example. """ > Section 6. > > For interoperability, it is RECOMMENDED a minimal ESP > implementation discards dummy packets. > > I'm puzzled by this sentence. What else can the receiver do with dummy > packets other than discard? RFC4303 leaves him only this option :-) > > Your are correct. My main concern when writing these lines was that the implementation handled properly the dummy packets. In a word, do not get upset by them. One case I am thinking of is when ESP is used in transport mode an IP communication believes a dummy packet should be discarded rather than sent to the next transport layer. In tunnel mode things seem different as the next header is likely an IP header in which case everything else should be discarded. > > Nits: > Throughout the text: > s/fix SPI/fixed SPI > Actually we removed the fixed SPI. > s/constraint node/constrained node > s/algorythm/algorithm > fixed > > Section 2: > > s/IPsec suite protocol/IPsec protocol suite > > fixed > Section 3: > > However, for some constraint nodes, generating a random SPI may > consume to much resource, in which case SPI can be generated using > predictable functions or even a fix value. > > s/to/too > > fixed > When a constraint node uses fix value for SPIs, it imposes some > limitations on the number of inbound SA. This limitation can be > alleviate by how the SA look up is performed. When fix SPI are used, > it is RECOMMENDED the constraint node has as many SPI values as ESP > session per host IP address, and that SA lookup includes the IP > addresses. > > s/alleviate/alleviated > s/RECOMMENDED the/RECOMMENDED that the > > More specifically, traffic pattern MAY leak sufficient information in > itself. In other words, privacy leakage is a complex and the use of > random SPI is unlikely to be sufficient. > > s/MAY/may > > In addition, > predictable SPI enable an attacker to forge packets with a valid SPI. > > s/enable/enables > > fixed > Section 5: > > As a result, TFC cannot not be enabled with minimal, and > communication protection that were relying on TFC will be more > sensitive to traffic shaping. > > s/cannot not/cannot > s/minimal/minimal ESP > s/were relying/rely > > Section 7: > > Currently recommended > [RFC8221] only recommend crypto-suites with an ICV which makes the > ICV a mandatory field. > > s/recommend/recommends > > fixed > Section 8: > > The recommended suites to use are expect to evolve over time > and implementer SHOULD follow the recommendations provided by > [RFC8221] and updates. > > s/expect/expected > s/implementer/implementers > > fixed > Note that it > is not because a encryption algorithm transform is widely > deployed that is secured. > > s/a/an > fixed > > Regards, > Valery Smyslov. > > > -- Daniel Migault Ericsson --0000000000009e886a05b2c65413 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Valery,=C2=A0

Thank=C2=A0= you very much for the review. Your review was very helpful to improve the d= raft and we believe the new version has taken the reviews into account. Ple= ase find a more detailed description of the=C2=A0updates led by your review= s.=C2=A0

Yours,
=C2=A0Daniel

On Tue, Dec = 3, 2019 at 8:08 AM Valery Smyslov <smyslov.ietf@gmail.com> wrote:
Hi,

I reviewed draft-ietf-lwig-minimal-esp-00. In general I think that the docu= ment
provides useful guidelines on how ESP can be implemented on constrained
devices.

General comment: the draft uses RFC2119 requirement language in several pla= ces,
and it is not always clear whether it is just a repetition of the RFC4301 r= equirements
or a new requirement imposed by this document. In general, I think it's= better not to include
the existing RFC4301/4303 requirements in the draft or make it absolutely c= lear that these are not
new requirements if you need to mention them (adding a reference to a corre= sponding section
in the RFCs).

<mglt>
We= initially took this text as an editorial choice to quote or refer=C2=A0to = useful original text. I understand it brings some confusion - unless we rea= d it very carefully. I am tempted to agree that it might be clearer now tha= t we removed the quoted text. In fact it is just commented so it would=C2= =A0be easy to move back, if that would=C2=A0raise=C2=A0any concerns.
<= div>
</mglt>=C2=A0

Another general comment: sections 3-7 discuss how the corresponding ESP pac= ket fields
can be tweaked to deal with low resource devices. I think that for the sake= of clarity
the suggested measures must be summarized in each of these sections. Curren= tly
these sections contain quite a lot of discussion and no clear conclusions w= hat
is OK to do and in what situations. I think document will be more clear if = such
conclusions are put at the end of each section (currently some advises are = spread
over them).

<mglt>
We tried to clarify the text. = One difficulty is that recommendations can easily change over the use cases= .=C2=A0=C2=A0
For section 3, we mentioned that tweak applies to c= onstraint devices for which handling 32 bit random SPI would cause an issue= . I think that is now clearer. We also re-order some of the paragraphs so t= he discussion of a specific use cases remains localized.=C2=A0
Fo= r section 4 we mentioned the SN that has an=C2=A0always=C2=A0increasing sou= rce may take advantage=C2=A0of it. We clarified that other recommendations= =C2=A0concern all devices.=C2=A0
For section 5 - 6 -=C2=A0 7 seem= s relatively generic.=C2=A0
If you believe we could=C2=A0improve = this, feel free to let us know.

</mglt>=C2= =A0

Specific comments:

Section 3.

=C2=A0 =C2=A0When fix SPI are used,
=C2=A0 =C2=A0it is RECOMMENDED the constraint node has as many SPI values a= s ESP
=C2=A0 =C2=A0session per host IP address, and that SA lookup includes the I= P
=C2=A0 =C2=A0addresses.

This is probably wrong if we take into considerations that SA may be rekeye= d.
Some words should be added either prohibiting rekeying ESP SAs in this case=
or discussing that in case of rekey one will consume additional SPI values<= br> for in fact the same SA.

<mglt>
I agree. We now clearly mentio= n that the number of SPI a peer needs to handle depends on the number of se= ssion and the rekying=C2=A0of these SA. We also moved the discussion of fix= ed SPIs to something more generic in order to provide more generic=C2=A0gui= dances. We reinforced=C2=A0also the need to rekey - and managed the keys in= the security consideration section.=C2=A0


SPI section has been updated as fol= lows:

"""
=C2=A0 However,= for some constrained nodes, generating and handling 32 bit
=C2=A0= =C2=A0random SPI may consume too much resource, in which case SPI can be=C2=A0 =C2=A0generated using predictable functions or end up in a using a= subset
=C2=A0 =C2=A0of the possible values for SPI.=C2=A0 In fact, the = SPI does not
=C2=A0 =C2=A0necessarily need to be randomly generated.=C2= =A0 A node provisioned with
=C2=A0 =C2=A0keys by a third party - e.g. th= at does not generate them - and that
=C2=A0 =C2=A0uses a transform that = does not needs random data may not have such
=C2=A0 =C2=A0random generat= ors.=C2=A0 However, non random SPI and restricting their
=C2=A0 =C2=A0po= ssible values MAY lead to privacy and security concerns.=C2=A0 As a
=C2= =A0 =C2=A0result, this alternative should be considered for devices that wo= uld
=C2=A0 =C2=A0be strongly impacted by the generation of a random SPI = and after
=C2=A0 =C2=A0understanding the privacy and security impact of = generating non
=C2=A0 =C2=A0random SPI.

=C2=A0 =C2=A0When a const= rained node limits the number of possible SPIs this limit
=C2=A0 =C2=A0s= hould both consider the number of inbound SAs - possibly per IP
=C2=A0 = =C2=A0addresses - as well as the ability for the node to rekey.=C2=A0 SPI c= an
=C2=A0 =C2=A0typically be used to procee= d to clean key update and the SPI value
=C2=A0 =C2=A0may be used to indi= cate which key is being used.=C2=A0 This can typically
=C2=A0 =C2=A0be i= mplemented by a SPI being encoded with the SAD entry on a subset
=C2=A0 = =C2=A0of bytes (for example 3 bytes), while the remaining byte is left to=C2=A0 =C2=A0indicate the rekey index.
"""
T= he security consideration has been updated as follows:

=
"""
=C2=A0 The security of a communication pr= ovided by ESP is closely related to
=C2=A0 =C2=A0the security associated= to the management of that key.=C2=A0 This usually
=C2=A0 =C2=A0include = mechanisms to prevent a nonce to repeat for example.=C2=A0 When a
=C2=A0= =C2=A0node is provisioned with a session key that is used across reboot,=C2=A0 =C2=A0the implementer MUST ensure that the mechanisms put in place= remain
=C2=A0 =C2=A0valid across reboot as well.

=C2=A0 =C2=A0It= is RECOMMENDED to use ESP in conjunction of key management
=C2=A0 =C2= =A0protocols such as for example IKEv2 [RFC7296] or minimal IKEv2
=C2=A0= =C2=A0[RFC7815].=C2=A0 Such mechanisms are responsible to negotiate fresh<= br>=C2=A0 =C2=A0session keys as well as prevent a session key being use bey= ond its
=C2=A0 =C2=A0life time.=C2=A0 When such mechanisms cannot be imp= lemented and the
=C2=A0 =C2=A0session key is, for example, provisioned, = the nodes SHOULD ensure
=C2=A0 =C2=A0that keys are not used beyond their= life time and that the
=C2=A0 =C2=A0appropriated use of the key remains= across reboots.

=C2=A0 =C2=A0When a node generates its key or when = random value such as nonces are
=C2=A0 =C2=A0generated, the random gener= ation MUST follow [RFC4086].
"""
</mglt>=C2=A0
=C2=A0 =C2=A0When used indoor, the privacy information is stored in the enc= rypted
=C2=A0 =C2=A0data and as such does not leak privacy.

I cannot parse this :-)

<mglt>
Not entirely sure what was the= initial intent, but the current text mentions that privacy implication sho= uld also consider=C2=A0the exposure of the communication. Typically, an ind= oor sensor with local IP address may leak little privacy sensitive=C2=A0inf= ormation with its SPI. Though this is not entirely no information. The curr= ent text is now:

"""
Thes= e devices, due to there limitations, are expected to provide
=C2=A0 =C2= =A0limited information and how the use of non random SPI impacts privacy=C2=A0 =C2=A0requires further analysis.=C2=A0 Typically temperature sensor= s, wind
=C2=A0 =C2=A0sensors, used outdoor do not leak privacy sensitive= information.
=C2=A0 =C2=A0When used indoor, privacy leakage outside the= local network may be
=C2=A0 =C2=A0limited.
""&q= uot;

</mglt>=C2=A0
=C2=A0 =C2=A0 Such packet will not be rejected due to an = SPI mismatch, but instead
=C2=A0 =C2=A0after the signature check which requires more resource and thu= s make
=C2=A0 =C2=A0DoS more efficient, especially for devices powered by batterie= s.

I think this a very good argument against fixed (predictable) SPIs.
In fact, after reading through this section it seems to me that the
conclusion must be - predictable (fixed) SPIs SHOULD NOT be used.

<mglt>
The current text does not ment= ion fixed SPI anymore, but considers SPIs that are non randomly generated.= =C2=A0
We also clarify the text to say. Generate randomly the SPI= when you can. Only if you really cannot consider the alternative. The reas= on I would not like to have SHOULD NOT is that it is still better to have I= Psec with non randomly generated SPIs than no security. That said, we do no= t want to encourage non randomly generated SPIs.
</mglt>=C2= =A0

=C2=A0 =C2=A0Values 0-255 SHOULD NOT be used.

I believe these values MUST NOT be used with IPsec ESP, no?
Why "SHOULD NOT"? The values from this range are reserved
for other protocols utilizing ESP (e.g. SPI (1) was used in SKIP).

<mglt>
This has been changed as well.= Originally we had SHOULD NOT as not to prevent future usage with the reser= ved values. We set it to MUST NOT.
</mglt>=C2=A0
Section 4.

I see no discussion regarding using ESN. I think there is generally no poin= t
to use ESN for constrained devices, but it can be useful if clock is used to generate (E)SN, as suggested in the draft. In this case 64-bit numbers can make sure that no two packets will be sent with the same ESN
(provided the clock has high resolution).

<mglt>
This is correct that the forme= r version did not provide indications on the=C2=A0use of ESN. This has been= added in the new version. It is hard to recommend one or the other but wha= t we would like=C2=A0is to emphasize is that incrementing the life time of = the session with=C2=A0ESN is generally a bad idea and that providing a reke= y mechanism is probably a better option. here is the text we come to:
=

"""
=C2=A0SN can be encoded ov= er 32 bits or 64 bits - known as Extended
=C2=A0 =C2=A0Sequence Number (= ESN).=C2=A0 As per [RFC4303], the support ESN is not



Migault= & Guggemos =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 1, 2021 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]
^L
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Minimal E= SP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0October 20= 20


=C2=A0 =C2=A0mandatory.=C2=A0 The determination of the use of= ESN is based on the
=C2=A0 =C2=A0largest possible value a SN can take o= ver a session.=C2=A0 When SN is
=C2=A0 =C2=A0incremented for each packet= , the number of packets sent over the life
=C2=A0 =C2=A0time of a sessio= n may be considered.=C2=A0 However, when the SN is
=C2=A0 =C2=A0incremen= ted differently - such as when time is used - the maximum
=C2=A0 =C2=A0v= alue SN needs to be considered instead.=C2=A0 Note that the limit of
=C2= =A0 =C2=A0messages being sent is primary determined by the security associa= ted
=C2=A0 =C2=A0to the key rather than the SN.=C2=A0 The security of th= e key used to
=C2=A0 =C2=A0encrypt decreases with the each message being= sent and a node MUST
=C2=A0 =C2=A0ensure the limit is not reached - eve= n though the SN would permit it.
=C2=A0 =C2=A0In a constrained environme= nt, it is likely that the implementation of a
=C2=A0 =C2=A0rekey mechani= sm is preferred over the use of ESN.
"""
=

=C2=A0
</mglt>
=C2=A0
Section 5.

=C2=A0 =C2=A0The purpose of padding is to respect the 32 bit alignment of E= SP.

It is not an accurate statement, the padding is also used when encryption transform requires the input to be a multiple of some number of bytes.
Many modern transforms (based on GCM, CCM, CTR modes) don't have such a requirement, but some (e.g. based on CBC mode) do have.

<mglt>
Correct. We fixed with the fol= lowing text:

"""
=C2=A0Th= e purpose of padding is to respect the 32 bit alignment of ESP or block siz= e expected by an encryption transform - such as AES-CBC for example.
"""
</mglt>=C2=A0
Section 6.

=C2=A0 =C2=A0For interoperability, it is RECOMMENDED a minimal ESP
=C2=A0 =C2=A0implementation discards dummy packets.=C2=A0

I'm puzzled by this sentence. What else can the receiver do with dummy<= br> packets other than discard? RFC4303 leaves him only this option :-)

<mglt>
Your are correct. My main conc= ern when writing these lines=C2=A0was that the implementation handled prope= rly the dummy packets. In a word, do not get upset by them. One case I am t= hinking of is when ESP is used in transport mode an IP communication believ= es a dummy packet should be discarded rather than sent to the next transpor= t layer. In tunnel mode things seem different as the next header is likely = an IP header in which case everything else should be discarded.=C2=A0
=
=C2=A0
</mglt>=C2=A0

Nits:
Throughout the text:
s/fix SPI/fixed SPI
<mglt>
Actually we= removed the fixed SPI.=C2=A0=C2=A0
</mglt>=C2=A0
s/constraint node/constrained node
s/algorythm/algorithm
<mglt>
fixed
</mglt>
=C2=A0

Section 2:

s/IPsec suite protocol/IPsec protocol suite

<mglt>
fixed
</mglt>= =C2=A0
Section 3:

=C2=A0 =C2=A0However, for some constraint nodes, generating a random SPI ma= y
=C2=A0 =C2=A0consume to much resource, in which case SPI can be generated u= sing
=C2=A0 =C2=A0predictable functions or even a fix value.=C2=A0

s/to/too

<mglt>
fixed
</mglt>= =C2=A0
=C2=A0 =C2=A0When a constraint node uses fix value for SPIs, it imposes som= e
=C2=A0 =C2=A0limitations on the number of inbound SA.=C2=A0 This limitation= can be
=C2=A0 =C2=A0alleviate by how the SA look up is performed.=C2=A0 When fix S= PI are used,
=C2=A0 =C2=A0it is RECOMMENDED the constraint node has as many SPI values a= s ESP
=C2=A0 =C2=A0session per host IP address, and that SA lookup includes the I= P
=C2=A0 =C2=A0addresses.

s/alleviate/alleviated
s/RECOMMENDED the/RECOMMENDED that the

=C2=A0 =C2=A0More specifically, traffic pattern MAY leak sufficient informa= tion in
=C2=A0 =C2=A0itself.=C2=A0 In other words, privacy leakage is a complex and= the use of
=C2=A0 =C2=A0random SPI is unlikely to be sufficient.

s/MAY/may

=C2=A0 =C2=A0In addition,
=C2=A0 =C2=A0predictable SPI enable an attacker to forge packets with a val= id SPI.

s/enable/enables

<mglt>
fixed
</mglt>= =C2=A0
Section 5:

=C2=A0 =C2=A0As a result, TFC cannot not be enabled with minimal, and
=C2=A0 =C2=A0communication protection that were relying on TFC will be more=
=C2=A0 =C2=A0sensitive to traffic shaping.=C2=A0

s/cannot not/cannot
s/minimal/minimal ESP
s/were relying/rely

Section 7:

=C2=A0 =C2=A0Currently recommended
=C2=A0 =C2=A0[RFC8221] only recommend crypto-suites with an ICV which makes= the
=C2=A0 =C2=A0ICV a mandatory field.

s/recommend/recommends

<mglt>
fixed
</mglt>= =C2=A0
Section 8:

=C2=A0 =C2=A0The recommended suites to use are expect to evolve over time =C2=A0 =C2=A0and implementer SHOULD follow the recommendations provided by<= br> =C2=A0 =C2=A0[RFC8221] and updates.

s/expect/expected
s/implementer/implementers

<mglt>
fixed
</mglt><= /div>
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0Note that it
=C2=A0 =C2=A0 =C2=A0 =C2=A0is not because a encryption algorithm transform = is widely
=C2=A0 =C2=A0 =C2=A0 =C2=A0deployed that is secured.=C2=A0

s/a/an
<mglt>
fixed
</mgl= t>=C2=A0

Regards,
Valery Smyslov.




--
Daniel Migault
Ericsson
--0000000000009e886a05b2c65413-- From nobody Wed Oct 28 19:56:34 2020 Return-Path: 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 982783A09B5; Wed, 28 Oct 2020 19:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tPDS1O6f8TKI; Wed, 28 Oct 2020 19:56:31 -0700 (PDT) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826873A0991; Wed, 28 Oct 2020 19:56:31 -0700 (PDT) Received: by mail-vk1-xa2b.google.com with SMTP id n141so385850vke.9; Wed, 28 Oct 2020 19:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OyxFZYb5bakaJ1l16vYLSyXkDa0Fy6+1HbF9kHhHelo=; b=WI0sX/8FrVh7fL7dlVwGpvXipqFh/7Yblaz/FqURxUOPVKR2VOFl71QMbKJI9wMG7N 5aZeYfP1udyqqroAruVhTwV9iIiBSSxXveaiOD7brF+j8aBKs1/pR42aeb1a8/HW9mfQ bvKf2Pk4QvETnNw1oJPiVTQTfOVzLAcKA1DUCAh1Rt5vKZwXe80Sycbws7QOIqd2IyTN 76R+2pcdTrmyE23YUeYlC5UuPcVz5eJsxxV+dlFKTwCDSwQinhvuqsPPcBBFSNMnt6Ij n+UzdcyHZVtjZWz6M1ZgOzdUZu2vlY6D4c8/7C1MQM9+23z3usdzVbN7q1f2jattQrKV oYPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OyxFZYb5bakaJ1l16vYLSyXkDa0Fy6+1HbF9kHhHelo=; b=NcuuGOBi9jBJqI3ZXjiKBtmyQp/hFaEBADQUdcDuI5FJhzKkNA0jnU75Ygq8vf6LCL xvGzGsbZt3AbkloP63i3sIvOo9Wxu0lRJKTVrIgkTpSgc+k15q+dIkj4GDdv6HSwmWRD EbvhVIWZVRZKMSXgHJRPyQcGRY2fNF3neVycXap+2Ux2R9m8FkNdtU7h1BK+2Gfmmtxw rI8/8NTFzPKsY5sfwFSvPPsIgeufWAVlGgFeft0loF309odoWYIvxWzr7EJEMQlXLXmX kXfS0cX8a/x8nhsFyjt5E3dZqf/sht+XTnLiVmVWdVW+U7x7W8WJoe1H93Zk5YeCbqLA jYmw== X-Gm-Message-State: AOAM531IGYqbaezY3H+ophPgBgyyLD4RyeK6RosFlnVz+UntH+2BTGT0 HFH+/vi12Jzmwwi2dm0Z+Q69UsDWf2xpsGEXelyIIxLhRIs= X-Google-Smtp-Source: ABdhPJzNflbrPto6VO5VSmBshBnW+N/2ZAKLYuCG16EBd6b8+HEY7ViJzIAM2YJzs/SkY9aQGma50vqDkrvhZgOLla8= X-Received: by 2002:a1f:ac10:: with SMTP id v16mr1918749vke.2.1603940190359; Wed, 28 Oct 2020 19:56:30 -0700 (PDT) MIME-Version: 1.0 References: <160393999553.11364.14119492742804803882@ietfa.amsl.com> In-Reply-To: <160393999553.11364.14119492742804803882@ietfa.amsl.com> From: Daniel Migault Date: Wed, 28 Oct 2020 22:56:19 -0400 Message-ID: To: lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="0000000000004993b405b2c66d34" Archived-At: Subject: [IPsec] Fwd: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 02:56:34 -0000 --0000000000004993b405b2c66d34 Content-Type: text/plain; charset="UTF-8" Hi, Please find an update of our draft on minimal esp. The draft addresses comments from Scott and Valery. We believe the document is now ready for WGLC. Of course comments are welcome! Yours, Daniel ---------- Forwarded message --------- From: Date: Wed, Oct 28, 2020 at 10:53 PM Subject: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-01.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : Minimal ESP Authors : Daniel Migault Tobias Guggemos Filename : draft-ietf-lwig-minimal-esp-01.txt Pages : 14 Date : 2020-10-28 Abstract: This document describes a minimal implementation of the IP Encapsulation Security Payload (ESP) defined in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options to remain compatible with ESP as described in RFC 4303. A minimal version of ESP is not intended to become a replacement of the RFC 4303 ESP, but instead to enable a limited implementation to interoperate with implementations of RFC 4303 ESP. This document describes what is required from RFC 4303 ESP as well as various ways to optimize compliance with RFC 4303 ESP. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. If this document and RFC 4303 conflicts then RFC 4303 is the authoritative description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-minimal-esp-01 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-minimal-esp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-minimal-esp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip -- Daniel Migault Ericsson --0000000000004993b405b2c66d34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find an update of our = draft on minimal esp. The draft addresses comments from Scott and Valery. W= e believe the document is now ready for WGLC.=C2=A0 Of course comments are = welcome!

Yours,=C2=A0
Daniel
<= br>

---------- Forwarded message ---------
From: = <internet-drafts@ietf.org>
Date: Wed, Oct 28, 2020 at 10:53 PM
Subject: [Lwip] I-D = Action: draft-ietf-lwig-minimal-esp-01.txt
To: <i-d-announce@ietf.org>
Cc: <lwip@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Light-Weight Implementation Guidance WG of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Minimal ESP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Dani= el Migault
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tobias Guggemos
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lwig-minimal-esp-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-10-28

Abstract:
=C2=A0 =C2=A0This document describes a minimal implementation of the IP
=C2=A0 =C2=A0Encapsulation Security Payload (ESP) defined in RFC 4303.=C2= =A0 Its
=C2=A0 =C2=A0purpose is to enable implementation of ESP with a minimal set = of
=C2=A0 =C2=A0options to remain compatible with ESP as described in RFC 4303= .=C2=A0 A
=C2=A0 =C2=A0minimal version of ESP is not intended to become a replacement= of the
=C2=A0 =C2=A0RFC 4303 ESP, but instead to enable a limited implementation t= o
=C2=A0 =C2=A0interoperate with implementations of RFC 4303 ESP.

=C2=A0 =C2=A0This document describes what is required from RFC 4303 ESP as = well as
=C2=A0 =C2=A0various ways to optimize compliance with RFC 4303 ESP.

=C2=A0 =C2=A0This document does not update or modify RFC 4303, but provides= a
=C2=A0 =C2=A0compact description of how to implement the minimal version of= the
=C2=A0 =C2=A0protocol.=C2=A0 If this document and RFC 4303 conflicts then R= FC 4303 is
=C2=A0 =C2=A0the authoritative description.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-lwig-minimal-esp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lw= ig-minimal-esp-01
https://datatracker.ietf.org/doc= /html/draft-ietf-lwig-minimal-esp-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-lwig-minimal-esp-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


--
Dani= el Migault
Ericsson
--0000000000004993b405b2c66d34-- From nobody Fri Oct 30 08:59:14 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CABA13A0B17; Fri, 30 Oct 2020 08:59:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <160407355278.30239.3611591879577897734@ietfa.amsl.com> Date: Fri, 30 Oct 2020 08:59:12 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 15:59:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Labeled IPsec Traffic Selector support for IKEv2 Authors : Paul Wouters Sahana Prasad Filename : draft-ietf-ipsecme-labeled-ipsec-04.txt Pages : 10 Date : 2020-10-30 Abstract: This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 30 09:11:38 2020 Return-Path: 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 178B13A105D for ; Fri, 30 Oct 2020 09:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=surrey.ac.uk 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 5Wd3z9gFrPSC for ; Fri, 30 Oct 2020 09:11:27 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150122.outbound.protection.outlook.com [40.107.15.122]) (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 A5C663A1030 for ; Fri, 30 Oct 2020 09:11:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F3uFtrdcmos1YwUJE27yl6+4Gd6kBzyVOcf4h/HWyr9dTwEAXWQsXQG9f8bYbXna88DTLaQdebLrmNx5kta2JIs+jpTWzrgveCdCwWdrJ9bf4xXNVCYtY0HBV3ePnfc1aLGOiZg8p0w4pvMpn1PJa75KrUbHspnU25poDY0K8wJ6FLnKg2zFtu8TZyA49ieWjpf/2vN/z4pRDj9JD9o0zv4rUzqt4bMBPLdS2Q0ZVjZWrliEJC/jZ4TuPPawz2uSprGpvtw+nzl+2eltPut9ojmqv5jhtshTUWZNz1zAcx3lCfQeG8P/NoTJ7wwFipWJhBq9lkj2NEd+PB0SZOa33w== 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=tpmVkSUYjvQIjT396EU0ppU6Lg0JSgbS7JWmd8nNsAI=; b=BAyNo5Qna7zOU9QOQhkOiSytwCfImaeFBU+fnOzMnnupMtwljPbAWvXG0We70Hm//cVdufTtGaoGMUYnCsxz+byIAlHMiKQ6zelVIZqsBlnyo21PJLC5gBP0ggO2OKa16cBUEvgDkxUWcojaR3x2l21aIcffk6TYpd4fZxCZkv10OyzYceoLq7gdrEKKtDfl5YOMuVjH4IoJm0mmarHiy4aPDvPzeH5oHLhdwN0XG8I/qN0IsPy1NbGljnnKtYwmmP4/X8dlgpQN9ZAiUN9f6OejycgzaCC6GEHMhQw/9nAzWkkspEEPVDLRMjZgKcnj54getCsnZejAbCaJEpHUsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=surrey.ac.uk; dmarc=pass action=none header.from=surrey.ac.uk; dkim=pass header.d=surrey.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=surrey.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tpmVkSUYjvQIjT396EU0ppU6Lg0JSgbS7JWmd8nNsAI=; b=UJx4ndfW7p/NUee0j4NZoO5kWkZDjLvMjMwKPOjSFQS+Ajdfcg5fiGmkPE9KQDy6VOIMdmdMzjTAlE2Fwu9NhU9YP1FDJtzfCqnNi28FNxnl3JGrD4PnK9Z85ZBxgfDCERcOQP5ARACOAGaxMb/3BmFWqZUZo6v3JPeTfZgpjN4= Received: from VI1PR06MB4191.eurprd06.prod.outlook.com (2603:10a6:803:72::13) by VI1PR06MB5936.eurprd06.prod.outlook.com (2603:10a6:803:d8::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Fri, 30 Oct 2020 16:11:15 +0000 Received: from VI1PR06MB4191.eurprd06.prod.outlook.com ([fe80::5f9:1782:eec1:f8d2]) by VI1PR06MB4191.eurprd06.prod.outlook.com ([fe80::5f9:1782:eec1:f8d2%7]) with mapi id 15.20.3499.027; Fri, 30 Oct 2020 16:11:15 +0000 From: Haitham Cruickshank To: "ipsec@ietf.org" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-04.txt Thread-Index: AQHWrtWtUKUyo+J9PESL395M1ZsOwqmwUOqA Date: Fri, 30 Oct 2020 16:11:15 +0000 Message-ID: <3046FF4F-206B-46A6-8A1D-3AFE2883831E@surrey.ac.uk> References: <160407355278.30239.3611591879577897734@ietfa.amsl.com> In-Reply-To: <160407355278.30239.3611591879577897734@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.1b.201012 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=surrey.ac.uk; x-originating-ip: [109.156.125.89] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c4f32e8f-cc18-4071-1990-08d87cee6daa x-ms-traffictypediagnostic: VI1PR06MB5936: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ntUVjmf7owQoBFoB/emodH5fbeZniQytvAnR7gbIP2fdxTiFjd7JEVEpDWn0HzUQWvz04HqaWMA0TVRSiEnoh9ZLP//EFf3DApyjuhO/ODFiZhrkgIuiu6gXGWatxCMqNP/wFcee+c1pJ+N+UdB8eXUspcUHvKhplBgTbbCV1ByFoSEGhXD3iXIlv++aQH3CQlyWwq6otWPxvFNul4NEt4aj0o+VlgH+iS4ttSm8QSlUwILXD4ULqS+i+8VHd3A1J4xVwArcKKAq1HpR5v902m/AQzFUXzinYRc28VyFsBPOnbbMw5NwYlYBguUQ0YbmahS+BpBfJL2TirB3LwkdF1zYq/gZ5pIL8m9rFvQFlye06O1VYxp4C0jiWH/vAZiDQlr2JbBUgIhNqcdDZXACJw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR06MB4191.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(366004)(136003)(376002)(346002)(6486002)(8936002)(86362001)(6916009)(4001150100001)(6512007)(71200400001)(786003)(966005)(66574015)(6506007)(2906002)(36756003)(83380400001)(8676002)(26005)(186003)(5660300002)(33656002)(316002)(2616005)(45080400002)(478600001)(64756008)(66556008)(66476007)(66946007)(66446008)(91956017)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: hhLE1MTdpLlVn2GD2IhkmRXCmz6+Yym18VzV9knrKWq4kEDGonruOBODWpncpe3d0dMvdcQPhtRaCvELIgbOKTsXGjKEG1jybJR5yRxlJrki/NaSI6X3c/YfXk3EZuI9ExoNdFAc2hfT5KkX4Jz+N4Ij6u/j8nUrmq0fqONQart0o3zWkKeWFcN/kTEa7PoSMT07+T4UKm/Qf8yoU4eGn1Jm0mo6T6XQC+XAtuBF1+/q6rie0ISHdQlSmsc05yylA220GrIcGLfKCp/hKGi0MGBL6ppaFdKFoB2kzlzMuPEaQjG5jM5BWJEMKOa5HTQujgDOjkSq5XmU6EFTF4gMZCedLpZ96t/Owsda2puBRZymaxAwypn2zRRDdGKZejZw0jU+L9sV7SwRQR3zWtDjeGo3aDPlll8AOgnWCohI8xdJVmvNHUdpXWoySFiLqNhFctbyjSQiHQtz/aIE762Lq8KSQ2tV8LmJ7yCqonmGm275sDTVVC3WjChhNJ3Bwz+I+7ekS6xqxsPwChKEu+g+H7OsLM7DHid2oOWuiWMO0mgab++FdatcqfDq3AhHEpSWDPbXVuaZuIbaf87Y26xOd/+AL+hgtMzcHVocJ8gtg0zgZf7XFgM2wFl/XCSVVyTyzB3+RE/l3FjdipSuRb3TIg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: surrey.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR06MB4191.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4f32e8f-cc18-4071-1990-08d87cee6daa X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2020 16:11:15.6540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4d+GjnawOKFOqyM0WP9Q5q0MhSD19mUfZ07HXsS4Ys4t/snxnonNQI/2rNVW4ZrBA4czoa8j7/wq3AO1pG5buA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB5936 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR06MB4191.eurprd06.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 109.156.125.89 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: VI1PR06MB5936.eurprd06.prod.outlook.com Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 16:11:37 -0000 VGhhbmtzIFJhaHVsLA0KDQpIYXZlIGEgbmljZSB3ZWVrZW5kLg0KDQpIYWl0aGFtDQoNCi0tLQ0K RHIuIEhhaXRoYW0gUy4gQ3J1aWNrc2hhbmsNClJlYWRlcg0KSW5zdGl0dXRlIGZvciBDb21tdW5p Y2F0aW9uIFN5c3RlbXMgKElDUykNCkZhY3VsdHkgb2YgRW5naW5lZXJpbmcgYW5kIFBoeXNpY2Fs IFNjaWVuY2UgDQpVbml2ZXJzaXR5IG9mIFN1cnJleQ0KR3VpbGRmb3JkIEdVMiA3WEgsIFVLIA0K VGVsOiArNDQgMTQ4MyA2ODYwMDcgKGluZGlyZWN0IDY4OTg0NCkNCkZheDogKzQ0IDE0ODMgNjg2 MDExDQplLW1haWw6IEguQ3J1aWNrc2hhbmtAc3VycmV5LmFjLnVrDQpodHRwczovL3d3dy5zdXJy ZXkuYWMudWsvcGVvcGxlL2hhaXRoYW0tY3J1aWNrc2hhbmsgDQoNCu+7v09uIDMwLzEwLzIwMjAs IDE1OjU5LCAiSVBzZWMgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGlw c2VjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4gd3JvdGU6DQoNCiAgICANCiAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVAgU2VjdXJpdHkgTWFpbnRlbmFuY2UgYW5kIEV4 dGVuc2lvbnMgV0cgb2YgdGhlIElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAgICAgICAg ICAgOiBMYWJlbGVkIElQc2VjIFRyYWZmaWMgU2VsZWN0b3Igc3VwcG9ydCBmb3IgSUtFdjINCiAg ICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFBhdWwgV291dGVycw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgU2FoYW5hIFByYXNhZA0KICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLWlwc2VjbWUtbGFiZWxlZC1pcHNlYy0wNC50eHQNCiAgICAJUGFnZXMgICAgICAgICAg IDogMTANCiAgICAJRGF0ZSAgICAgICAgICAgIDogMjAyMC0xMC0zMA0KICAgIA0KICAgIEFic3Ry YWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBUcmFmZmljIFNlbGVjdG9y IChUUykgVHlwZSBmb3IgSW50ZXJuZXQNCiAgICAgICBLZXkgRXhjaGFuZ2UgdmVyc2lvbiAyIHRv IGFkZCBzdXBwb3J0IGZvciBuZWdvdGlhdGluZyBNYW5kYXRvcnkNCiAgICAgICBBY2Nlc3MgQ29u dHJvbCAoTUFDKSBzZWN1cml0eSBsYWJlbHMgYXMgYSB0cmFmZmljIHNlbGVjdG9yIG9mIHRoZQ0K ICAgICAgIFNlY3VyaXR5IFBvbGljeSBEYXRhYmFzZSAoU1BEKS4gIFNlY3VyaXR5IExhYmVscyBm b3IgSVBzZWMgYXJlIGFsc28NCiAgICAgICBrbm93biBhcyAiTGFiZWxlZCBJUHNlYyIuICBUaGUg bmV3IFRTIHR5cGUgaXMgVFNfU0VDTEFCRUwsIHdoaWNoDQogICAgICAgY29uc2lzdHMgb2YgYSB2 YXJpYWJsZSBsZW5ndGggb3BhcXVlIGZpZWxkIHNwZWNpZnlpbmcgdGhlIHNlY3VyaXR5DQogICAg ICAgbGFiZWwuICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIElLRXYyIFRTIG5lZ290aWF0aW9u IHNwZWNpZmllZCBpbg0KICAgICAgIFJGQyA3Mjk2IFNlY3Rpb24gMi45Lg0KICAgIA0KICAgIA0K ICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K ICAgIGh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1pcHNl Y21lLWxhYmVsZWQtaXBzZWMlMkYmYW1wO2RhdGE9MDQlN0MwMSU3Q0guQ3J1aWNrc2hhbmslNDBz dXJyZXkuYWMudWslN0MwZDRlZWM2MWFiMjc0NDcxMjJmMTA4ZDg3Y2VjY2YwYiU3QzZiOTAyNjkz MTA3NDQwYWE5ZTIxZDg5NDQ2YTJlYmI1JTdDMCU3QzAlN0M2MzczOTY3MDM4MDgxMzM2MjQlN0NV bmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklp TENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9azZnOTZJajlT NzdSMjFqbnFodlFqdlZObm1HWFdFQ3d3aSUyRnE5WWh0UkFZJTNEJmFtcDtyZXNlcnZlZD0wDQog ICAgDQogICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K ICAgIGh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtaXBzZWNtZS1s YWJlbGVkLWlwc2VjLTA0JmFtcDtkYXRhPTA0JTdDMDElN0NILkNydWlja3NoYW5rJTQwc3VycmV5 LmFjLnVrJTdDMGQ0ZWVjNjFhYjI3NDQ3MTIyZjEwOGQ4N2NlY2NmMGIlN0M2YjkwMjY5MzEwNzQ0 MGFhOWUyMWQ4OTQ0NmEyZWJiNSU3QzAlN0MwJTdDNjM3Mzk2NzAzODA4MTMzNjI0JTdDVW5rbm93 biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJU aUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPXRGQld1cmVkMHAyd1Yl MkJ4c1VucGdZdERaSDkwaEhtbkFIVVRJUkZlZjd2ZyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KICAgIGh0 dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtaXBz ZWNtZS1sYWJlbGVkLWlwc2VjLTA0JmFtcDtkYXRhPTA0JTdDMDElN0NILkNydWlja3NoYW5rJTQw c3VycmV5LmFjLnVrJTdDMGQ0ZWVjNjFhYjI3NDQ3MTIyZjEwOGQ4N2NlY2NmMGIlN0M2YjkwMjY5 MzEwNzQ0MGFhOWUyMWQ4OTQ0NmEyZWJiNSU3QzAlN0MwJTdDNjM3Mzk2NzAzODA4MTMzNjI0JTdD VW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJ aUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPWJpMUhkQ2tK aSUyQlR3UXo4NVQ3dHdNNDBudkdua1hmR1ZGNUgyQ2RqTHJZYyUzRCZhbXA7cmVzZXJ2ZWQ9MA0K ICAgIA0KICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCiAgICBodHRwczovL2V1cjAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZyZmNkaWZmJTNGdXJsMiUzRGRyYWZ0LWll dGYtaXBzZWNtZS1sYWJlbGVkLWlwc2VjLTA0JmFtcDtkYXRhPTA0JTdDMDElN0NILkNydWlja3No YW5rJTQwc3VycmV5LmFjLnVrJTdDMGQ0ZWVjNjFhYjI3NDQ3MTIyZjEwOGQ4N2NlY2NmMGIlN0M2 YjkwMjY5MzEwNzQ0MGFhOWUyMWQ4OTQ0NmEyZWJiNSU3QzAlN0MwJTdDNjM3Mzk2NzAzODA4MTMz NjI0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lW Mmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPSUy RjY2blAlMkIlMkJTZENZdTdzMmFVUkY1aEI4bWltQTZ0RENqd0x2JTJGJTJCQ0RCa2xrJTNEJmFt cDtyZXNlcnZlZD0wDQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQogICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1mdHAlM0ElMkYlMkZmdHAuaWV0Zi5vcmclMkZpbnRlcm5ldC1k cmFmdHMlMkYmYW1wO2RhdGE9MDQlN0MwMSU3Q0guQ3J1aWNrc2hhbmslNDBzdXJyZXkuYWMudWsl N0MwZDRlZWM2MWFiMjc0NDcxMjJmMTA4ZDg3Y2VjY2YwYiU3QzZiOTAyNjkzMTA3NDQwYWE5ZTIx ZDg5NDQ2YTJlYmI1JTdDMCU3QzAlN0M2MzczOTY3MDM4MDgxMzM2MjQlN0NVbmtub3duJTdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9VXR2cEpuU3psSkdhM0hUaCUyQjV2 bTZscUUzVTBwM2dmTk1mRjlSMlRLMmdrJTNEJmFtcDtyZXNlcnZlZD0wDQogICAgDQogICAgDQog ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBJ UHNlYyBtYWlsaW5nIGxpc3QNCiAgICBJUHNlY0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vZXVyMDIu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5p ZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmlwc2VjJmFtcDtkYXRhPTA0JTdDMDElN0NI LkNydWlja3NoYW5rJTQwc3VycmV5LmFjLnVrJTdDMGQ0ZWVjNjFhYjI3NDQ3MTIyZjEwOGQ4N2Nl Y2NmMGIlN0M2YjkwMjY5MzEwNzQ0MGFhOWUyMWQ4OTQ0NmEyZWJiNSU3QzAlN0MwJTdDNjM3Mzk2 NzAzODA4MTMzNjI0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFp TENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1w O3NkYXRhPU9KSTVGZDB3ZVBNczZVcEJqSlVVak1UZ1F2T2YwMzAyOXJWZ1FPUmZpeWMlM0QmYW1w O3Jlc2VydmVkPTANCiAgICANCg0K From nobody Fri Oct 30 09:13:11 2020 Return-Path: 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 0D0E63A0B5F for ; Fri, 30 Oct 2020 09:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 Vq9MdKQKmqsL for ; Fri, 30 Oct 2020 09:13:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 E4DC93A0A70 for ; Fri, 30 Oct 2020 09:13:07 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CN6mL2C89zKNs for ; Fri, 30 Oct 2020 17:13:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1604074386; bh=ugcbNhaKaQYhYhzmK2QFGnFXVvWv48N3JwkwGZXPZZE=; h=Date:From:To:Subject:In-Reply-To:References; b=M0phoCMYFTjz7Lyk0hEgWy+kVLqa6GzrZkOJgyMXf1MxjCX8Cvv/EhjdhTubzqKNQ o3fcdorQ9BXbD9tVOEGu1dgdDonzMzz5gTudXD+O1+/YxoGVAXhbhQR8ej9ApooXcH eeZ/geLglDM8tTAXcxDQBN5mzJVfNhkD7yHgw3JI= 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 hteGSHCrJD6e for ; Fri, 30 Oct 2020 17:13:05 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 30 Oct 2020 17:13:05 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E86216029BA1; Fri, 30 Oct 2020 12:13:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E7423384C9 for ; Fri, 30 Oct 2020 12:13:03 -0400 (EDT) Date: Fri, 30 Oct 2020 12:13:03 -0400 (EDT) From: Paul Wouters To: ipsec@ietf.org In-Reply-To: <160407355278.30239.3611591879577897734@ietfa.amsl.com> Message-ID: References: <160407355278.30239.3611591879577897734@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 16:13:10 -0000 On Fri, 30 Oct 2020, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-04.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-04 This version is a minor update. It fixes some typos (notably TS_UNAVAILABLE -> TS_UNACCEPTABLE) and adds an Implementation Status section for libreswan/linux/SElinux. Paul From nobody Fri Oct 30 12:13:21 2020 Return-Path: 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 964CC3A1138; Fri, 30 Oct 2020 12:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 8nLOMakDhyfm; Fri, 30 Oct 2020 12:13:17 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 452B93A1136; Fri, 30 Oct 2020 12:13:14 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 173C71B006C6; Fri, 30 Oct 2020 21:13:11 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1604085191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UjR2qo96vBTRyNWg2Gtn7/LmpVRyTLAjfnby3eEkZMU=; b=ehBFyFR/zYMSl1IEnNe5Lz8ARDdEY8GZ2w++lzV9MYXvSzdY1K65sEX1deYgLX1pSxtaY+ fKz5GjmSNpI7juUAAvWKWiyaABDWquk1WmFHyf9M7GVg9AzRe0nrurGXNVBT0cTEtNJsU6 bkixfaiOS2riP8siOhwZ+p/+5/E+Aye2I+8fb6gSQUlHNY8eKPe4XCFpqzXfPP4s/YaV32 bGC1Be0zC3jfaDn0VGgVB1FgnG9baf8h++u5rzyZtNmudTl0zRmihmbDe7pZRvg81Ra8+s jbrMJVgmhowvB8hXA8wEK5O/iSLlgWSwVSybKuTVEW3/7F1XWYghSCEjDgqgZA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 129CB25C131D; Fri, 30 Oct 2020 21:13:09 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24476.26053.16496.150596@fireball.acr.fi> Date: Fri, 30 Oct 2020 21:13:09 +0200 From: Tero Kivinen To: Daniel Migault Cc: "Scott Fluhrer \(sfluhrer\)" , "ipsec\@ietf.org" , lwip@ietf.org In-Reply-To: References: X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1604085191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UjR2qo96vBTRyNWg2Gtn7/LmpVRyTLAjfnby3eEkZMU=; b=kqyn46QgOZ1+10VUUoWjCnDMGOPMRgEl47zSl9KChJ28qxysuCr2rEkJ+RlAV5iz+52rX+ QqA7FCY84/NmBhMJwuU79sQH3EoOrm/HNceZohDdW1KkSZnO33xxR9zx5p138DOvTgi/Wh oVWqAS/UOKQqA7WNul6Ku6Be9EIrap5M2c9pOMEoLpoQHOQlUV+E4NjExE/uHy3gbNG1p+ zGBQ1GgbQ5ERgCsz4gtGATyn6yUuDEYJ3zooBjHOuS7VNTfx0Lulr+845Vh44iGvl4U7wb 7Hy+pUgvRCaeanVUPchXHqSlweNm3pxttivxFvdLNofzoNx09N0qlonYwLemBQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1604085191; a=rsa-sha256; cv=none; b=m/PdhBmcZG1ralL2sW6OEJDP794RwZeya/hr0M4CUSTni2AC4PlxcWYYHGQAY+tBa770Qy u0PqGC6b2qUeaMgGhQX/mI1c54oTbQcnOAXrNRq+J/F4Uxe7BHLMpPf6uxxPHX9ttjQ+ls b9uAakM0capKtlh7gDqVTNRK1+8vppyEGmI+3y/8250dwjXCVvrIoVN5vHeSy3Q2prDguh O085swOpXwr0klNvTxvyg0TOGEh/Z3OxlhPaFdx3D+Kpddv1WeulvzGDjC17m4U2guPrqT GNSjQFE/LgP8+jlt+sLHFRlEFcYsUu3qH22P/Ga4I2tv5dtu4PqtinXWJyIplQ== Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 19:13:20 -0000 Daniel Migault writes: > The security consideration has been updated as follows: >=20 > """ > =C2=A0 The security of a communication provided by ESP is closely rel= ated to > =C2=A0 =C2=A0the security associated to the management of that key.=C2= =A0 This usually > =C2=A0 =C2=A0include mechanisms to prevent a nonce to repeat for exam= ple.=C2=A0 When a > =C2=A0 =C2=A0node is provisioned with a session key that is used acro= ss reboot, > =C2=A0 =C2=A0the implementer MUST ensure that the mechanisms put in p= lace remain > =C2=A0 =C2=A0valid across reboot as well. >=20 > =C2=A0 =C2=A0It is RECOMMENDED to use ESP in conjunction of key manag= ement > =C2=A0 =C2=A0protocols such as for example IKEv2 [RFC7296] or minimal= IKEv2 > =C2=A0 =C2=A0[RFC7815].=C2=A0 Such mechanisms are responsible to nego= tiate fresh > =C2=A0 =C2=A0session keys as well as prevent a session key being use = beyond its > =C2=A0 =C2=A0life time.=C2=A0 When such mechanisms cannot be implemen= ted and the > =C2=A0 =C2=A0session key is, for example, provisioned, the nodes SHOU= LD ensure > =C2=A0 =C2=A0that keys are not used beyond their life time and that t= he > =C2=A0 =C2=A0appropriated use of the key remains across reboots. Why the last sentence has SHOULD and not MUST=3F If device reuses the key across reboots and the algorithm is counter mode based, this will cause serious security issues. Also same thing happens if the counters are allowed to roll over. I would suggest changing that "MUST ensure". > The use of fix SPI MUST NOT be considered as a way to avoid stron= g random > generators.=C2=A0 Such generator will be required in order to pro= vide strong > cryptographic protection=E2=80=9D; actually, if the IPsec impleme= ntation doesn=E2=80=99t > actually generate its own keys (that is, it relies on an external= service > to provide them), and the transform itself doesn=E2=80=99t requir= e random data > (CBC can be implemented securely without one), then the IPsec > implementation doesn=E2=80=99t actually need an CSPRNG. > =20 > > The current text presented it in another way. The former text seems t= o explain > that random was necessary for the generation of SPI. The current text= has been > updated to explain that we may have nodes without random generators.=C2= =A0 >=20 > I am wondering how the IV is generated with CBC without random genera= tor.=C2=A0 Normally you use just counter, and encrypt it with secret key. The IV in CBC does not be random, it needs to be unpredictable and it should not be direct counter or other source with low Hamming distance between successive IVs. Actually the problem with old way of CBC mode was that the IV was random, but predictable as implementations used last block of previous packet. If attacker does not know the key you are using to encrypt the counter to generate IVs, the IVs will be unpredictable and random. --=20 kivinen@iki.fi From nobody Fri Oct 30 12:26:38 2020 Return-Path: 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 B08CF3A116E; Fri, 30 Oct 2020 12:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 CJjAeJ5j7L7Y; Fri, 30 Oct 2020 12:26:31 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 56FE43A116D; Fri, 30 Oct 2020 12:26:30 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id D759820AD3; Fri, 30 Oct 2020 21:26:26 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1604085986; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p4bcr5mDGgC4+UN5bjZjOQN6rANuAHsfk2XVtSwwbM8=; b=UzabmDrPxvLDe3iJCgJWOQcdRXFukajUwweHBtSCIOFfupy9JHhl8Wy1r736b9E0pCnTIz ng6BT6STViveGKC/XxJj4YksnDY5pNgoTdninipcNfVgELXeoCEbH9+ADwY9BJWvaDypYj G+Y19o8qj6plgmjxN4i/0wZL2AZhuvs= Received: by fireball.acr.fi (Postfix, from userid 15204) id 9D4F625C131F; Fri, 30 Oct 2020 21:26:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24476.26850.591422.567867@fireball.acr.fi> Date: Fri, 30 Oct 2020 21:26:26 +0200 From: Tero Kivinen To: Daniel Migault Cc: Valery Smyslov , IPsecME WG , lwip@ietf.org, Tobias Guggemos In-Reply-To: References: <060501d5a9da$b8552490$28ff6db0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 7 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1604085986; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p4bcr5mDGgC4+UN5bjZjOQN6rANuAHsfk2XVtSwwbM8=; b=Tgf1L8hjw0ETK2sluEXzdZUwk8cYA9mRnDi+ppyWSEsjzoZNbZG5P4ttVBuW6VEnAVzmPB AM1T/b0lAqbpyrfdFE0acpEEpkp6bcL4gD1mIDkic0UA/7Qq7xdfZQelPdtJRDOSV9Z8vT ISdlvsR3sIvitVuEWP9XNd4RDio2CLU= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1604085986; a=rsa-sha256; cv=none; b=lMOadup9TRTfm4HQ0a7u/eCHxCRYR6tYIqY+wXRNfMajuFoDiz29Ou/ZH5S7qqnoNn1rPM 0uDsowJbConLIoVXdlKYnqnUvf7acPHPcPG43i2xgXYp4DHTi35rjT3/rPr/0JD+KkwKD/ 745gU69S1DcFr0+Cd1tkKUYTeeWArSU= Archived-At: Subject: Re: [IPsec] [Lwip] Review of draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 19:26:34 -0000 Daniel Migault writes: > =A0 =A0value SN needs to be considered instead.=A0 Note that the limi= t of > =A0 =A0messages being sent is primary determined by the security asso= ciated > =A0 =A0to the key rather than the SN.=A0 The security of the key used= to > =A0 =A0encrypt decreases with the each message being sent and a node = MUST > =A0 =A0ensure the limit is not reached - even though the SN would per= mit it. > =A0 =A0In a constrained environment, it is likely that the implementa= tion of a > =A0 =A0rekey mechanism is preferred over the use of ESN. No. The security of the key does not decrease, but the ability for the attacker to attack the key might incrase, and the value of attacking that one key also increases when more data is encrypted with it. Also with short block length algorithms there were stricter limits of data that can be encrypted with one key. --=20 kivinen@iki.fi From nobody Fri Oct 30 12:40:30 2020 Return-Path: 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 179883A11A9; Fri, 30 Oct 2020 12:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=cert.org 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 yqFsUPLdWAXP; Fri, 30 Oct 2020 12:40:24 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 624A83A11B0; Fri, 30 Oct 2020 12:40:23 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09UJe80Y005018; Fri, 30 Oct 2020 15:40:08 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 09UJe80Y005018 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1604086809; bh=UXDd4RoHBYuuWWCfC+/yfzH/Km+xpEg4xIRf0Vs4SPs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=QsQzA/RE1sglvo7WF/J12BFxKDRQFwy+9ztjW3BJfPeD2dOUnhgJ30c59KT0zv6kk I1ks2O6AKrJsfOpnIjtWGaBg6tHRVOATSf0mh1O5746giUOPUFiwCrIrMjBSuv09iF zZyNvO1M165z6fQk1k84pOvOQPOFaj4jvV+8R2rY= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09UJe4Ev031668; Fri, 30 Oct 2020 15:40:04 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 30 Oct 2020 15:40:04 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Fri, 30 Oct 2020 15:40:03 -0400 From: Roman Danyliw To: tom petch CC: "i2nsf@ietf.org" , Fernando Pereniguez-Garcia , Gabriel Lopez , "ynir.ietf@gmail.com" , "last-call@ietf.org" , "ipsec@ietf.org" , Rafa Marin-Lopez Thread-Topic: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt Thread-Index: AQHWreX0c88acJXFBk2yYgVjsJF2bKmvCuOA///cU0CAAVuUAP//zZ2A Date: Fri, 30 Oct 2020 19:40:03 +0000 Message-ID: <834a668ac559460a9f356bbb6c16b8fd@cert.org> References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <5F9815D1.9010303@btconnect.com> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> In-Reply-To: <5F9BF578.6000101@btconnect.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.126] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 19:40:28 -0000 SGkgVG9tIQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRvbSBwZXRj aCA8ZGFlZHVsdXNAYnRjb25uZWN0LmNvbT4NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDMwLCAy MDIwIDc6MTQgQU0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFJhZmEgTWFy aW4tTG9wZXogPHJhZmFAdW0uZXM+DQo+IENjOiBpMm5zZkBpZXRmLm9yZzsgRmVybmFuZG8gUGVy ZW5pZ3Vlei1HYXJjaWENCj4gPGZlcm5hbmRvLnBlcmVuaWd1ZXpAY3VkLnVwY3QuZXM+OyBHYWJy aWVsIExvcGV6IDxnYWJpbG1AdW0uZXM+Ow0KPiB5bmlyLmlldGZAZ21haWwuY29tOyBsYXN0LWNh bGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtMYXN0LUNhbGxdIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtDQo+IGZsb3ctcHJvdGVjdGlv bi0xMS50eHQNCj4gDQo+IFJvbWFuICBub3QgdGhpcyBJLUQgYnV0IHNlZSBiZWxvdw0KPiANCj4g T24gMjkvMTAvMjAyMCAxODo0NiwgUm9tYW4gRGFueWxpdyB3cm90ZToNCj4gPiBIaSBUb20hDQo+ ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbGFzdC1jYWxs IDxsYXN0LWNhbGwtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIHRvbSBwZXRjaA0KPiA+ PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyOSwgMjAyMCAxMjozOCBQTQ0KPiA+PiBUbzogUmFm YSBNYXJpbi1Mb3BleiA8cmFmYUB1bS5lcz4NCj4gPj4gQ2M6IGkybnNmQGlldGYub3JnOyBGZXJu YW5kbyBQZXJlbmlndWV6LUdhcmNpYQ0KPiA+PiA8ZmVybmFuZG8ucGVyZW5pZ3VlekBjdWQudXBj dC5lcz47IEdhYnJpZWwgTG9wZXogPGdhYmlsbUB1bS5lcz47DQo+ID4+IHluaXIuaWV0ZkBnbWFp bC5jb207IGxhc3QtY2FsbEBpZXRmLm9yZw0KPiA+Pg0KPiA+PiBUb3AgcG9zdGluZyBhIG5ldywg cmVsYXRlZCBpc3N1ZSB0aGF0IG1heSBuZWVkIFNlY3VyaXR5IEFEIG9yIFdHDQo+ID4+IENoYWly IHRvIGFjdCBvbi4NCj4gPj4NCj4gPj4gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgSUFOQSBlbnRy aWVzIGZvciBJS0V2MiBhcmUgaW5jb21wbGV0ZS4NCj4gPj4gUkZDODI0NyBkb2VzIGEgZmluZSBq b2Igb2Ygc3BlY2lmeWluZyBhbGdvcml0aG1zIGFuZCBhZGRpbmcNCj4gPj4gaW5mb3JtYXRpb24g c3VjaCBhcyBzdGF0dXMgKE1VU1QvU0hPVUxEKyksIElvVCwgQUVBRCBhbmQgc28gb24sDQo+ID4+ IGluZm9ybWF0aW9uIHdoaWNoIGlzIG5vdCBwcmVzZW50IG9uIElBTkEuICBUaGUgcG9saWN5IGZv ciwgZS5nLg0KPiA+PiBUcmFuc2Zvcm0gVHlwZSAxLCBpcyBleHBlcnQgcmV2aWV3IGFuZCBlbnRy aWVzIGhhdmUgYmVlbiBhZGRlZCB2aWENCj4gPj4gZHJhZnQtc215c2xvdi1lc3AtZ29udCBidXQg dGhlIElBTkEgZW50cmllcyBsYWNrIHRoaXMgaW5mb3JtYXRpb24NCj4gPj4gYW5kLCBsb29raW5n IGF0IHRoZSBJLUQsIEkgc2VlIG5vIHN1Y2ggaW5mb3JtYXRpb24gKG5vciBpcyB0aGVyZSBhbnkN Cj4gPj4gcmVhc29uIGZvciBpdCB0byBiZSB0aGVyZSkuICBZZXQgZHJhZnQtaWV0Zi1pMm5zZi1z ZG4uLi4gbmVlZHMgdGhpcyBpbmZvcm1hdGlvbg0KPiBhcyByZWZlcmVuY2VzIGluIHRoZSBZQU5H IG1vZHVsZSBzaG93Lg0KPiA+Pg0KPiA+PiBJdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgaXMgYSBz aW1pbGFyIHNpdHVhdGlvbiB0byB0aGF0IHdoaWNoIHRoZSBUTFMNCj4gPj4gV0cgZm91bmQgaXRz ZWxmIGluIGFuZCB3aGljaCBsZWQgdG8gYSByZXZpc2lvbiBvZiB0aGUgVExTIElBTkENCj4gPj4g ZW50cmllcyB0byBwcm92aWRlIHdoYXQgd2FzIG5lZWRlZCB2aWEgYWRkaXRpb25hbCBjb2x1bW5z Lg0KPiA+DQo+ID4gUGxlYXNlIGhlbHAgbWUgdW5kZXJzdGFuZC4gIEluIHBhcnRpY3VsYXIsIEkn bSBub3QgZm9sbG93aW5nIHdoeSB0aGlzDQo+IGRvY3VtZW50IHNob3VsZCBtb2RpZnkgSUtFIElB TkEgcmVnaXN0cmllcy4gIEluIG15IHZpZXcsIHRoaXMgZG9jdW1lbnQgaXMNCj4gcHJvdmlkZXMg YSBkYXRhIG1vZGVsIHRvIGVuY29kZSBhbiAiSUtFdjIgY29uZmlndXJhdGlvbiIgb2Ygc29ydHMu ICBDZXJ0YWlubHksDQo+IHRoZXJlIGFyZSB2YWxpZC9pbnZhbGlkL2luY29tcGxldGUvbm90IHJl Y29tbWVuZGVkIHdheXMgdG8gcHJvdmlkZSBhDQo+IGNvbmZpZ3VyYXRpb24gd2l0aCB0aGlzIGRh dGEgbW9kZWwgaWYgb25lIHJlbGllZCBzb2xlbHkgb24gdGhlIHBvaW50ZXJzIHRvIHRoZQ0KPiBJ QU5BIHJlZ2lzdHJpZXMgZnJvbSB0aGUgWUFORyBtb2R1bGUgZGVmaW5pdGlvbi4gIEhvd2V2ZXIs IGFzIHlvdSBub3RlZCwNCj4gUkZDODI0NyBhbHJlYWR5IHByb3ZpZGVzIGd1aWRhbmNlIG9uIHNw ZWNpZnlpbmcgYSBjb25maWd1cmF0aW9uIChhbGJlaXQgdGhpcw0KPiBndWlkYW5jZSBpc24ndCBm dWxseSBlbmNvZGVkIGluIHRoZSByZWdpc3RyaWVzKS4gIEZ1cnRoZXJtb3JlLCB0aGlzIGRvY3Vt ZW50DQo+IHN0YXRlczoNCj4gPg0KPiA+IFNlY3Rpb24gOC4xDQo+ID4gICAgIG8gIElLRXYyIGNv bmZpZ3VyYXRpb25zIHNob3VsZCBhZGhlcmUgdG8gdGhlIHJlY29tbWVuZGF0aW9ucyBpbg0KPiA+ ICAgICAgICBbUkZDODI0N10uDQo+ID4NCj4gPiBzbyB0aGVyZSBpcyBndWlkYW5jZSBvbiBwcm9k dWNpbmcgYSBjb25maWd1cmF0aW9uLiAgV2hhdCBpcyBtaXNzaW5nPw0KPiA+DQo+ID4+IEkgdGhp bmsgdGhhdCB0aGUgSUFOQSBwYWdlcyBmb3IgSUtFdjIgbmVlZCByZXZpc2luZyBzbyB0aGF0IHRo YXQNCj4gPj4gYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aGF0IFJGQzgyNDcgcHJvdmlkZXMgaXMg cmVxdWlyZWQgYXMNCj4gPj4gYWRkaXRpb25hbCBjb2x1bW5zIGluIHRoZSBJQU5BIGVudHJpZXMg YXQgbGVhc3QgZm9yIFR5cGUgMSwgVHlwZSAyLA0KPiA+PiBUeXBlIDMsIFR5cGUgNCBhbmQgQXV0 aGVudGljYXRpb24gTWV0aG9kLg0KPiA+DQo+ID4gV2hpbGUgdGhpbmdzIGNvdWxkIGJlIGNsZWFy ZXIsIEknbSB1bnN1cmUgb2Ygd2h5IF90aGlzIFlBTkcgZG9jdW1lbnRfDQo+IHNob3VsZCBkbyBh IHJlZ2lzdHJ5IHJlZW5naW5lZXJpbmcuICBEaWQgeW91IG1lYW4gaXQgc2hvdWxkIGJlIGRvbmUg aW4gZ2VuZXJhbD8NCj4gDQo+IE5vdCB0aGlzIEktRCBidXQgYW5vdGhlciBJLUQgZnJvbSBhIFdH IHdpdGggY2xvc2VyIGxpbmtzIHRvIElLRXYyOyBJIGRvbid0IGtub3cNCj4gd2hpY2ggV0cgdGhh dCB3b3VsZCBiZSBidXQgYSBTZWN1cml0eSBBRCB3b3VsZDotKQ0KDQpUaGFua3MgZm9yIGNsYXJp ZnlpbmcuICBJUFNFQ01FIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2lwc2VjbWUv YWJvdXQvKSAod2hvIGhhcyBiZWVuIGNyb3NzLXBvc3RlZCB3aXRoIHRoaXMgbm90ZSkgIGlzIGxp a2VseSB0aGUgYmVzdCBwbGFjZSB0byBoYW5kbGUgSVBzZWMgbWFpbnRlbmFuY2UgYW5kIHRoZSBr aW5kIG9mIHJlZ2lzdHJ5IG1vZGlmaWNhdGlvbnMgeW91IGRlc2NyaWJlIGJlbG93Lg0KDQpSZWdh cmRzLA0KUm9tYW4NCg0KPiBUaGlzIEktRCwgYXMgeW91IHF1b3RlLCBwb2ludHMgdG8gUkZDODI0 NyBmb3IgZ3VpZGFuY2UgYW5kIHRoYXQgaXMgZmluZS4NCj4gICBCdXQgc2VjdXJpdHkgbW92ZXMg b24gYW5kIG5ldyBhbGdvcml0aG1zIHdpbGwgYmUgbmVlZGVkIGFuZCB0aGlzIEktRCBhbHNvDQo+ IHBvaW50cyB0byB0aGUgSUFOQSByZWdpc3RyeSwgd2hpY2ggaXMgRXhwZXJ0IFJldmlldywgd2hl cmUgbmV3IGVudHJpZXMgaGF2ZQ0KPiBiZWVuIGFkZGVkIGFscmVhZHk7IGFuZCBmb3IgdGhvc2Ug dGhlIElBTkEgUmVnaXN0cnkgZ2l2ZXMgbm8gZ3VpZGFuY2UgYW5kIHRoZQ0KPiBJLUQgdGhhdCBJ QU5BIHJlZmVyZW5jZXMgZm9yIHRoZSBuZXcgZW50cmllcyAtIHdyaXR0ZW4gYnkgdGhlIEV4cGVy dCBSZXZpZXdlciEgLQ0KPiBhbHNvIGdpdmVzIG5vIGd1aWRhbmNlLiBPdmVyIHRpbWUgd2UgYXJl IGxpa2VseSB0byBhY2NydWUgYWxnb3JpdGhtcyB3aXRoIG5vDQo+IGd1aWRhbmNlIHVubGVzcyBh bmQgdW50aWwgYW4gUkZDODI0Ny1iaXMgYXBwZWFycyBvciB3ZSByZXF1aXJlIElBTkEgdG8gaGF2 ZQ0KPiBjb2x1bW5zIGZvciBndWlkYW5jZS4NCj4gQ3VycmVudGx5IHRoZSBuZXcgYWxnb3JpdGht cyBhcmUgR09TVCBhbmQgc28gcGVyaGFwcyBvZiBsaW1pdGVkIGludGVyZXN0IGJ1dA0KPiBvbiB0 aGUgVExTIGxpc3QgSSBhbSBhbHdheXMgc2VlaW5nIG5ldyBhbGdvcml0aG1zIGFwcGVhciBhbmQg dGhlcmUgdGhlIG5ldw0KPiBJQU5BIGVudHJ5IGlzIHJlcXVpcmVkIHRvIGdpdmUgZ3VpZGFuY2Uu ICBNeSBzZW5zZSBpcyB0aGF0IElLRXYyIGlzIGEgYml0IHNsb3dlcg0KPiB0byB0YWtlIHVwIG5l dyBvbmVzIGJ1dCwgYXMgd2l0aCBSRkM4MjQ3LCBpdCBkb2VzIGV2ZW50dWFsbHkuDQo+IA0KPiBJ IHRoaW5rIHRoYXQgdXNlcnMgbmVlZCB0aG9zZSBleHRyYSBjb2x1bW5zIHRoYXQgUkZDODI0NyBw cm92aWRlcyBvbiB0aGUgSUFOQQ0KPiB3ZWJzaXRlIHNvIHRoYXQgd2hlbiBuZXcgYWxnb3JpdGht cyBhcmUgYWRkZWQgYnkgRXhwZXJ0IFJldmlldywgdGhlbiB0aGF0DQo+IGd1aWRhbmNlIG11c3Qg YmUgYWRkZWQgYXMgd2VsbC4gIFRoaXMgaXMgd2hhdCB0aGUgVExTIFdHIGNhbWUgcm91bmQgdG8g YW5kIEkNCj4gdGhpbmsgdGhhdCBJS0V2MiBuZWVkcyB0byBkbyB0aGUgc2FtZS4NCj4gDQo+IFRv bSBQZXRjaA0KPiANCj4gDQo+ID4gUmVnYXJkcywNCj4gPiBSb21hbg0KPiA+DQo+ID4+IFRvbSBQ ZXRjaA0KPiA+Pg0KPiA+PiBPbiAyOS8xMC8yMDIwIDExOjIzLCBSYWZhIE1hcmluLUxvcGV6IHdy b3RlOg0KPiA+Pj4gSGkgVG9tOg0KPiA+Pj4NCj4gPj4+PiBFbCAyOCBvY3QgMjAyMCwgYSBsYXMg MTk6MDIsIHRvbSBwZXRjaCA8ZGFlZHVsdXNAYnRjb25uZWN0LmNvbT4NCj4gZXNjcmliacOzOg0K PiA+Pj4+DQo+ID4+Pj4gT24gMjgvMTAvMjAyMCAxMDo0MiwgUmFmYSBNYXJpbi1Mb3BleiB3cm90 ZToNCj4gPj4+Pj4gSGkgVG9tOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFuayB5b3UgdmVyeSBtdWNo IGZvciB5b3VyIGluc2lnaHQuIEl0IGlzIHZlcnkgaGVscGZ1bC4gUGxlYXNlDQo+ID4+Pj4+IHNl ZSBvdXINCj4gPj4gY29tbWVudHMvcXVlc3Rpb25zIGlubGluZS4NCj4gPj4+Pj4NCj4gPj4+Pj4+ IEVsIDI3IG9jdCAyMDIwLCBhIGxhcyAxMzo0MiwgdG9tIHBldGNoIDxkYWVkdWx1c0BidGNvbm5l Y3QuY29tPg0KPiA+PiBlc2NyaWJpw7M6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSB0aGluayB0aGF0 IHRoZSBJRVNHIHdpbGwgZmluZCBhIG51bWJlciBvZiBwcm9ibGVtcyB3aXRoIHRoaXMgSS1ELg0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IFlBTkcgbW9kdWxlIHJlZmVyZW5jZXMgUkZDODIyIHdoaWNoIGlz IHNldmVyYWwgeWVhcnMgb3V0IG9mIGRhdGUNCj4gPj4+Pg0KPiA+Pj4+IFJhZmENCj4gPj4+Pg0K PiA+Pj4+IE9uIGJvaWxlciBwbGF0ZSwgSSBtZWFuIHRoZSByZWZlcmVuY2UgdG8gUkZDMjExOSB3 aGljaCBub3cgbXVzdCB1c2UNCj4gPj4+PiB0aGUNCj4gPj4gbGFuZ3VhZ2UgZnJvbSBSRkM4MTc0 IGluIHRoZSBib2R5IG9mIHRoZSBJLUQ7IHNvcnJ5IGZvciB0aGUgY29uZnVzaW9uLg0KPiA+Pj4N Cj4gPj4+IEFoIG9rLiBJIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIGNoYW5nZSB0aGF0IHBh cmFncmFwaCB3aXRoIHRoaXM6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCj4gPj4+ ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQi LA0KPiA+PiAiTUFZIiwgYW5kDQo+ID4+PiAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJl IHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbg0KPiA+Pj4gQkNQDQo+ID4+PiAxNCBS RkMyMTE5IFJGQzgxNzQgd2hlbiwgYW5kIG9ubHkgd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsIGNh cGl0YWxzLA0KPiA+Pj4gYXMgc2hvd24gaGVyZS4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiBPbiBY WFhYLCB5b3UgaGF2ZSBYWFhYIHN0YW5kaW5nIGluIGZvciBtb3JlIHRoYW4gb25lIFJGQy10by1i ZQ0KPiA+Pj4+IHdoaWNoDQo+ID4+IGNvbmZ1c2VzLiAgVGhlIGNvbnZlbnRpb24gaXMgdG8gdXNl IFhYWFggZm9yIHRoaXMgSS1EIGFuZCB0aGVuIEFBQUENCj4gPj4gQkJCQiBldGMgZm9yIGFueSBv dGhlcnMgc3VjaCBhcyB0aGUgbmV0Y29uZiBJLUQgaW4gdGhpcyBpbnN0YW5jZS4NCj4gPj4+DQo+ ID4+PiBBaCBvay4gSW4gYW55IGNhc2UsIHdlIGhhdmUgbm93IG9ubHkgWFhYWCBmb3Igb3VyIFJG Qy10by1iZSBzbw0KPiA+Pj4gcHJvYmxlbQ0KPiA+PiBmaXhlZC4NCj4gPj4+Pg0KPiA+Pj4+IFR3 byBiaWcgaXNzdWVzLCBmb3IgbWUgKHBlcmhhcHMgbm90IGZvciBvdGhlcnMpLiAgVGhlIGNvbnZl bnRpb24NCj4gPj4+PiB3aXRoIFlBTkcNCj4gPj4gaXMgZm9yIGVhY2ggc3VjY2Vzc2l2ZSBsaW5l IHRvIGJlIGluZGVudGVkIHR3byBjaGFyYWN0ZXJzLCB5b3UgaGF2ZQ0KPiA+PiBmb3VyLCB3aGlj aCBjcmVhdGVzIGEgbG90IG9mIHdoaXRlIHNwYWNlIGFuZCBwdXNoZXMgdGhlIHRleHQgdG8gdGhl DQo+ID4+IHJpZ2h0IGhhbmQgbWFyZ2luLiAgSSB0aGluayB0aGF0IHR3byBjaGFyYWN0ZXJzIGlz IHRoZSBkZWZhdWx0IHdoZW4NCj4gPj4geW91IHVzZSBweWFuZyB0byBmb3JtYXQgYSBZQU5HIG1v ZHVsZS4NCj4gPj4+DQo+ID4+PiBXZSBjYW4gdHJ5IHRvIHJlZHVjZSBpdCB0byB0d28gY2hhcmFj dGVycy4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiBBbmQgcmVmZXJlbmNlcy4gIEkgaGF2ZSBoYWQg dG8gd29yayBoYXJkZXIgdGhhbiBJIHdhbnQgdG8gdG8gbWFrZQ0KPiA+Pj4+IHNlbnNlIG9mIHRo ZSBJQU5BIHJlZmVyZW5jZXMuICBJIHRoaW5rIHlvdSBzaG91bGQgaGF2ZSBmaXZlDQo+ID4+Pj4g c2VwYXJhdGUgcmVmZXJlbmNlcyBpbiB0aGUgSS1EIGZvciBJQU5BIGZvciBUcmFuc2Zvcm0gVHlw ZSAxDQo+ID4+Pj4gVHJhbnNmb3JtIFR5cGUgMyBUcmFuc2Zvcm0gVHlwZSA0IEF1dGhlbnRpY2F0 aW9uIE1ldGhvZCBQcm90b2NvbA0KPiA+Pj4+IE51bWJlcnMgYW5kIGVhY2ggcmVmZXJlbmNlIGlu IHRoZSBJLUQgc2hvdWxkIGhhdmUgYSBVUkwgcG9pbnRpbmcgdG8NCj4gPj4+PiB0aGUgc3BlY2lm aWMgc2VjdGlvbiBvZg0KPiA+PiBJQU5BIHdlYiBzaXRlLg0KPiA+Pj4NCj4gPj4+IE9rLCBnb29k LiBUaGlzIGZvbGxvd3Mgd2hhdCB3ZSB0aG91Z2h0Lg0KPiA+Pj4NCj4gPj4+PiBJbiB0aGUgWUFO RywgaXQgaXMgaGFyZGVyIHRvIGtub3cgd2hhdCB0byBkby4gIFRob3NlIGZpcnN0IHRocmVlDQo+ ID4+Pj4gcmVmZXJlbmNlcw0KPiA+PiBhcmUgaW4gdGhlIHRoaXJkIHRpZXIgaS5lLg0KPiA+Pj4+ IEdyb3VwIC0gSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIFYyIChJS0V2MikgUGFyYW1ldGVycyBSZWdp c3RyeQ0KPiA+Pj4+IC1UcmFuc2Zvcm0gQXR0cmlidXRlIFR5cGVzIGFuZCB0aGVuIFR5cGUgMSwg MywgNCBhcyB0aGUgdGhpcmQgdGllcg0KPiA+Pj4+IGFzIEkgYW0gY2FsbGluZyBpdCBhbmQgSSB0 aGluayB0aGF0IGV2ZXJ5IHJlZmVyZW5jZSBpbiB0aGUgWUFORw0KPiA+Pj4+IHNob3VsZCBnaXZl IG1lIGFsbCB0aHJlZSB0aWVycyBhZnRlciBJQU5BIGluIHRoYXQgb3JkZXIgcGVyaGFwcw0KPiA+ Pj4+IElBTkE7IElLRXYyIFBhcmFtZXRlcnM7IFRyYW5zZm9ybSBBdHJpYnV0ZSBUeXBlczsgVHJh bnNmb3JtIFR5cGUgMQ0KPiA+Pj4NCj4gPj4+IEdyZWF0LiBXZSBhbHNvIGNvbnNpZGVyZWQgdGhp cyBhcyBhIHBvc3NpYmxlIHNvbHV0aW9uIGFmdGVyIHNlbmRpbmcgb3VyIGUtDQo+IG1haWwuDQo+ ID4+IExldOKAmXMgZG8gaXQuDQo+ID4+Pg0KPiA+Pj4+IElmIHRoZSBzeW50YXggbmVlZHMgdHdl ZWtpbmcsIHRoZW4gdGhlIFJGQyBFZGl0b3Igd2lsbCBkbyBhIGdvb2QNCj4gPj4+PiBqb2Igb2Yg dGhhdA0KPiA+PiBidXQgYXQgcHJlc2VudCB0aGUgcmVmZXJlbmNlcyBhcmUgaW5jb25zaXN0ZW50 IGluIHdoaWNoIGVsZW1lbnRzIGFyZQ0KPiA+PiBzcGVjaWZpZWQgaW4gd2hhdCBvcmRlciBhbmQg dGhhdCBpcyBzb21ldGhpbmcgdGhlIFJGQyBFZGl0b3IgcHJvYmFibHkNCj4gY2Fubm90IGNvcGUg d2l0aC4NCj4gPj4+PiBBdXRoZW50aWNhdGlvbiBNZXRob2QgaXMgYSByZWdpc3RyeSBzbyB0aGF0 IGp1c3QgbmVlZHMgR3JvdXAgbmFtZQ0KPiA+Pj4+IGFuZA0KPiA+PiBSZWdpc3RyeSBuYW1lIGFm dGVyIElBTkEuDQo+ID4+Pg0KPiA+Pj4gT2ssIGdvb2QuDQo+ID4+Pj4NCj4gPj4+PiBTb21lIG1p bm9yIGdsaXRjaGVzLg0KPiA+Pj4+IEktRCBhcHBlYXJzIHR3aWNlIGluIHRoZSBib2R5IG9mIHRo ZSBJLUQgLSBwZXJoYXBzIGRvY3VtZW50IG9yIG1lbW8uDQo+ID4+Pg0KPiA+Pj4gT2suDQo+ID4+ Pg0KPiA+Pj4+IG9iamV0aXZlcy9vYmplY3RpdmVzLw0KPiA+Pj4NCj4gPj4+IEZpeGVkLg0KPiA+ Pj4+IGVuZCBwb3J0IG51bWJlciBwZXJoYXBzIC9tdXN0L01VU1QvDQo+ID4+Pg0KPiA+Pj4+IGFu ZCBZQU5HIGlzIHZlcnkgZ29vZCBhdCBpbmNsdWRpbmcgc3VjaCBjaGVja3Mgd2l0aCBhIG11c3Qg Li4uLg0KPiA+Pj4+ICdJZiBBRUFEIGlzIHVzZWQgLi4gd2hlcmU/IHRoaXMgb2NjdXJzIGluIHNl dmVyYWwgcGxhY2VzIGFuZCBJDQo+ID4+Pj4gdGhpbmsgdGhhdCB5b3UNCj4gPj4gbmVlZCB0byBz cGVjaWZ5IHRoZSBsZWFmIHdoZXJlIEFFQUQgd2lsbCBiZSBzcGVjaWZpZWQgb3IgaW1wbGllZC4N Cj4gPj4+DQo+ID4+PiBPayB3ZSBoYXZlIGNoYW5nZWQgaXQgdG86DQo+ID4+Pg0KPiA+Pj4gSWYg QXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBpcyB1 c2VkDQo+ID4+PiAobGVhZg0KPiA+Pj4gZXNwLWFsZ29yaXRobXMvZW5jcnlwdGlvbi9hbGdvcml0 aG0tdHlwZSkNCj4gPj4+IHRoaXMgZmxhZyBNVVNUIGJlIGZhbHNlLiINCj4gPj4+DQo+ID4+Pj4g QW5kIGlzIGl0IHBvc3NpYmxlIHRvIG1ha2UgdGhhdCBhIFlBTkcgJ211c3QnIHN0YXRlbWVudCAt IGxvb2tpbmcNCj4gPj4+PiBhdCB0aGUNCj4gPj4gSUtFdjIgcmVnaXN0cmllcyBpdCBpcyBub3Qg b2J2aW91cyB3aGljaCBhcmUgQUVBRCBzbyB0aGF0IG1pZ2h0IGJlDQo+ID4+IG1vcmUgY29tcGxl eGl0eSB0aGFuIGl0IGlzIHdvcnRoLg0KPiA+Pj4+ICdvbmx5IGF2YWlsYWJsZSBvbiBsaW51eCBr ZXJuZWxzJyBVbSBpbXBsZW1lbnRhdGlvbiBkZXRhaWwsIHlvdSBtYXkNCj4gPj4+PiBnZXQNCj4g Pj4gYXNrZWQgdG8gcmVtb3ZlIHRoYXQgYWx0b2dldGhlciBvciBhdCBsZWFzdCB0byBhIEluZm9y bWF0aXZlIEFwcGVuZGl4DQo+ID4+IC0gSSB3b3VsZCBsZWF2ZSBpdCBpbiBmb3Igbm93Lg0KPiA+ Pj4NCj4gPj4+IE9rLg0KPiA+Pj4NCj4gPj4+PiAnaW1wb3J0IGlldGYtaTJuc2YtaWtlYycgdGhl IHJlZmVyZW5jZSBuZWVkcyB0byBiZSB0byBhIFJGQyBhbmQgaWYNCj4gPj4+PiBpdCBpcyBub3Qg eWV0IGFuIFJGQyB0aGVuIFJGQyBYWFhYIDx0aXRsZT4gaW4gYm90aCBBcHBlbmRpeCBCIGFuZCBD DQo+ID4+Pg0KPiA+Pj4gWWVzLCB3ZSBoYXZlIGNoYW5nZWQgdGhhdCB0bzoNCj4gPj4+DQo+ID4+ PiBSRkMgWFhYWDogU29mdHdhcmUtRGVmaW5lZCBOZXR3b3JraW5nDQo+ID4+PiAgICAgICAgICAg ICAgICAgIChTRE4pLWJhc2VkIElQc2VjIEZsb3cgUHJvdGVjdGlvbi4NCj4gPj4+DQo+ID4+Pj4g bGVhZi1saXN0IHBmcy1ncm91cHMgY291bGQgZG8gd2l0aCBhIHJlZmVyZW5jZSAtIFRyYW5zZm9y bSBUeXBlIDQ/DQo+ID4+Pg0KPiA+Pj4gVGhlIGxlYWYgbGlzdCBpcyByZWZlcnJpbmcgdG8gdHlw ZSBwZnMtZ3JvdXAgYW5kIHdlIGhhdmUgbm93DQo+ID4+Pg0KPiA+Pj4gdHlwZWRlZiBwZnMtZ3Jv dXAgew0KPiA+Pj4gICAgICAgICAgICAgICB0eXBlIHVpbnQxNjsNCj4gPj4+ICAgICAgICAgICAg ICAgZGVzY3JpcHRpb24NCj4gPj4+ICAgICAgICAgICAgICAgICAgICJESCBncm91cHMgZm9yIElL RSBhbmQgSVBzZWMgU0EgcmVrZXkuIjsNCj4gPj4+ICAgICAgICAgICAgICAgcmVmZXJlbmNlDQo+ ID4+PiAgICAgICAgICAgICAgICAgICAiSUFOQTsgSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIFYyIChJ S0V2MikgUGFyYW1ldGVyczsNCj4gPj4+IAkJCQlUcmFuc2Zvcm0gQXRyaWJ1dGUgVHlwZXM7IFRy YW5zZm9ybSBUeXBlIDQgLQ0KPiA+Pj4gICAgICAgICAgICAgICAgICAgRGlmZmllLUhlbGxtYW4g R3JvdXAgVHJhbnNmb3JtIElEcy4NCj4gPj4+IAkJCQlTZWN0aW9uIDMuMy4yIGluIFJGQyA3Mjk2 LiI7DQo+ID4+PiAgICAgICAgICAgfQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiBJIGFt IHN0aWxsIHdvcmtpbmcgbXkgd2F5IHRocm91Z2ggdGhlIFlBTkcgc28gbWF5IGhhdmUgc29tZSBt b3JlDQo+ID4+IGNvbW1lbnRzIHRvbW9ycm93Lg0KPiA+Pj4NCj4gPj4+IE9rLCBkbyBub3Qgd29y cnkgd2Ugd2lsbCB3b3JrIGluIC0xMiB3aXRoIHRoZXNlIGNvbW1lbnRzIHNvIGZhciB0bw0KPiA+ Pj4gaGF2ZSBhDQo+ID4+IHF1aWNrIHJlc3BvbnNlLiBXZSBjYW4gcHJlcGFyZSBhIGFub3RoZXIg dmVyc2lvbiBsYXRlciB3aXRoIHRoZSByZXN0IG9mDQo+IHRoZW0uDQo+ID4+Pg0KPiA+Pj4gVGhh bmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBlZmZvcnQuDQo+ID4+Pj4NCj4gPj4+PiBUb20gUGV0 Y2gNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+ Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ DQo+ID4+Pj4+IFdlIGhhdmUgcmVhbGl6ZWQgdGhhdCB3ZSBtaXNzZWQgdG8gY2hhbmdlIHRoaXMs IGV2ZW4gdGhvdWdoIHdlDQo+ID4+Pj4+IGRpc2N1c3NlZA0KPiA+PiBpdC4gV2Ugd2lsbCBjaGFu Z2UgaXQgcmlnaHQgYXdheSBpbiB0aGUgZm9sbG93aW5nIHdheSAoYm9sZCk6DQo+ID4+Pj4+DQo+ ID4+Pj4+IGNhc2UgcmZjODIyLWFkZHJlc3Mtc3RyaW5nIHsNCj4gPj4+Pj4gICAgICAgIGxlYWYg cmZjODIyLWFkZHJlc3Mtc3RyaW5nIHsNCj4gPj4+Pj4gICAgICAgICAgICAgdHlwZSBzdHJpbmc7 DQo+ID4+Pj4+ICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ID4+Pj4+ICAgICAgICAgICAgICAg ICAiU3BlY2lmaWVzIHRoZSBpZGVudGl0eSBhcyBhDQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAg ZnVsbHktcXVhbGlmaWVkIFJGQzUzMjIgZW1haWwNCj4gPj4+Pj4gICAgICAgICAgICAgICAgICBh ZGRyZXNzIHN0cmluZy4gQW4gZXhhbXBsZSBpcywNCj4gPj4+Pj4gICAgICAgICAgICAgICAgICBq c21pdGhAZXhhbXBsZS5jb20uIFRoZSBzdHJpbmcNCj4gPj4+Pj4gICAgICAgICAgICAgICAgICBN VVNUIE5PVCBjb250YWluIGFueQ0KPiA+Pj4+PiAgICAgICAgICAgICAgICAgIHRlcm1pbmF0b3Jz IGUuZy4sIE5VTEwsIENSLA0KPiA+Pj4+PiAgICAgICAgICAgICAgICAgIGV0Yy4pLiI7DQo+ID4+ Pj4+ICAgICAgICAgICAgICByZWZlcmVuY2UNCj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAi UkZDIDUzMjIuIjsNCj4gPj4+Pj4gICAgICAgIH0NCj4gPj4+Pj4gfQ0KPiA+Pj4+Pg0KPiA+Pj4+ PiBCdHcsIHdlIGFscmVhZHkgdXNlZCBpbiB0aGUgcGFzdCDigJxjYXNlIHJmYzgyMi1hZGRyZXNz LXN0cmluZ+KAnSBhbmQNCj4gPj4+Pj4g4oCcbGVhZg0KPiA+PiByZmM4MjItYWRkcmVzcy1zdHJp bmfigJ0gc2luY2UgdGhpcyBpcyBjb21pbmcgZnJvbSBJS0V2MiBzdGFuZGFyZC4gRG8NCj4gPj4g eW91IHRoaW5rIHdlIHNob3VsZCBjaGFuZ2UgdGhhdCBuYW1lIGFzIHdlbGw/DQo+ID4+Pj4+DQo+ ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gWUFORyBtb2R1bGUgcmVmZXJlbmNlcyBJQU5BIFBy b3RvY29sIE51bWJlcnMgd2hpY2ggaXMgbm90IGluIHRoZQ0KPiA+Pj4+Pj4gSS1EIHJlZmVyZW5j ZXMNCj4gPj4+Pj4NCj4gPj4+Pj4gV2UgaGF2ZSBpbmNsdWRlZCB0aGUgZm9sbG93aW5nIHJlZmVy ZW5jZToNCj4gPj4+Pj4NCj4gPj4+Pj4gW0lBTkEtUHJvdG9jb2xzLU51bWJlcl0NCj4gPj4+Pj4g ICAgICAgICAgICAgICAgIEludGVybmV0IEFzc2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5IChJQU5B KSwgIlByb3RvY29sDQo+ID4+Pj4+ICAgICAgICAgICAgICAgICBOdW1iZXJzIiwgSmFudWFyeSAy MDIwLg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IHMuMiBib2lsZXIgcGxh dGUgaXMgb3V0IG9mIGRhdGUNCj4gPj4+Pj4NCj4gPj4+Pj4gV2hhdCB3ZSBzZWUgaXMgdGhlIEkt RCBoYXMgdGhlIHNlY29uZCBjaG9pY2Ugc3RhdGVkIGluDQo+ID4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL3N0YW5kYXJkcy9pZHMvZ3VpZGVsaW5lcy8NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhpcyBJ bnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0K PiA+Pj4+PiAgICAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQo+ID4+Pj4+DQo+ ID4+Pj4+ICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmcNCj4gPj4+Pj4gICAgICBUYXNrIEZvcmNlIChJRVRGKS4gIE5v dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KPiA+Pj4+PiAgICAgIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtDQo+ID4+Pj4+ICAgICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4DQo+ IG1vbnRocw0KPiA+Pj4+PiAgICAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9i c29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQNCj4gYW55DQo+ID4+Pj4+ICAgICAgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UN Cj4gPj4+Pj4gICAgICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y ayBpbiBwcm9ncmVzcy4iDQo+ID4+Pj4+DQo+ID4+Pj4+IENvdWxkIHlvdSByZWZlciB3aGF0IGlz IG91dCBvZiBkYXRlPw0KPiA+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFhYWFggaXMgc3RhbmRp bmcgaW4gZm9yIG1vcmUgdGhhbiBvbmUgUkZDDQo+ID4+Pj4+DQo+ID4+Pj4+IFllcywgWFhYWCBo YXMgYmVlbiB1c2VkIGJlY2F1c2Ugd2UgZG8gbm90IGtub3cgdGhlIGZ1dHVyZSBudW1iZXINCj4g Pj4gYXNzaWduZWQgdG8gb3VyIEktRC4NCj4gPj4+Pj4NCj4gPj4+Pj4gQWxzbyB3ZSByZWFsaXpl ZCB3ZSBhbHNvIGluY2x1ZGVkIHRoaXMgdG8gcmVmZXIgdG8gY3J5cHRvLXR5cGVzDQo+ID4+Pj4+ IEktRCBidXQgdGhpcw0KPiA+PiBoYXMgYmVlbiBzb2x2ZWQgbm93IGluIGEgbmV3IHZlcnNpb24g LTEyIHRoYXQgd2UgYXJlIHByZXBhcmluZyB0bw0KPiA+PiBpbmNsdWRlIHlvdXIgY29tbWVudHMu IFdlIG5vdGljZWQgd2UgY2FuIHJlcGxhY2UgdGhlIHR5cGUgb2YgcncNCj4gPj4gY2VydC1kYXRh PywgY2EtZGF0YSosIGNybC0gZGF0YT8gZm9yIGJpbmFyeSB3aXRob3V0IGFueSBwcm9ibGVtLg0K PiA+Pj4+Pg0KPiA+Pj4+PiB8ICAgICAgICAgICB8ICAgICArLS1ydyBjZXJ0LWRhdGE/ICAgICAg ICBiaW5hcnkNCj4gPj4+Pj4gfCAgICAgICAgICAgKy0tcncgcHJpdmF0ZS1rZXk/ICAgICAgICAg ICAgYmluYXJ5DQo+ID4+Pj4+IHwgICAgICAgICAgICstLXJ3IGNhLWRhdGEqICAgICAgICAgICAg ICAgIGJpbmFyeQ0KPiA+Pj4+PiB8ICAgICAgICAgICArLS1ydyBjcmwtZGF0YT8gICAgICAgICAg ICAgICBiaW5hcnkNCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBidXQgdGhlIHNob3cgc3Rv cHBlciB0aGF0IG1ha2VzIGEgcHJvcGVyIHJldmlldyBvZiB0aGlzIHRvbw0KPiA+Pj4+Pj4gY29z dGx5IGlzIHRoZQ0KPiA+PiByZWZlcmVuY2VzLiAgVGhvc2UgdG8gSUFOQSBvZiB3aGljaCB0aGVy ZSBhcmUgc2V2ZXJhbCBJIHdhbnQgdG8NCj4gPj4gcHVyc3VlLiAgVGhlIEktRCByZWZlcmVuY2Ug aXMgdG8gSUtFdjIgcGFyYW1ldGVycy4gU2FkbHksIHRoaXMgaXMgYQ0KPiA+PiB0aHJlZSB0aWVy IHN0cnVjdHVyZSBhbmQgbm9vbmUgYWdyZWVzIG9uIHdoYXQgdG8gY2FsbCB0aGUgdGhpcmQgdGll cg0KPiA+PiBzbyBJIHdpbGwgY2FsbCBpdCB0aWVyMyBoZXJlLiAgVG9wIGxldmVsIGlzIEdyb3Vw LCBhcyBwZXIgUkZDODEyNiwNCj4gPj4gc2Vjb25kIGxldmVsIGlzIFJlZ2lzdHJ5LiAgVGhlIEkt RCByZWZlcmVuY2UgaXMgdG8gdGhlIEdyb3VwIG9ubHkNCj4gPj4gd2hpY2ggaXMgZmluZSBpZiB0 aGUgYWN0dWFsIHJlZmVyZW5jZSB0aGVuIHNwZWNpZmllcyB0aGUgUmVnaXN0cnkgYW5kDQo+ID4+ IFRpZXIzIGJ1dCB0aGV5IG5ldmVyIGRvLCB1c3VhbGx5IGp1c3QgVGllcjMgZS5nLiBUcmFuc2Zv cm0gVHlwZSAzDQo+ID4+IHdoaWNoIG1ha2VzIGZvciBhIGxvdCBvZiB3b3JrIGZvciB0aGUgcmVh ZGVyLCB0b28gbXVjaCBmb3IgdGhpcyBvbmUuDQo+ID4+IFlvdSBoYXZlIHRvIGdvIGh1bnRpbmcg aW4gYWxsIHRoZSBzZWNvbmQgbGV2ZWwgUmVnaXN0cnkgdW50aWwgeW91IGNhbg0KPiA+PiBmaW5k IGEgbWF0Y2ggZm9yIHRoZSBUaWVyMyBpZGVudGlmaWVyLiBBbmQgdGhlcmUgYXJlIG5vIFVSTC4g IElmIHlvdQ0KPiA+PiB3YW50IGFuIGV4YW1wbGUgdGhhdCBJIGZpbmQgZWFzeSB0byB1c2UsIGdv IGxvb2sgYXQgUkZDODQwNyAoYXMgdXN1YWwpLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBZb3XigJlyZSBy aWdodC4gQ291bGQgeW91IHBvaW50IHRoZSBleGFjdCBwYXJ0IGF0IFJGQyA4NDA3IHdpdGggdGhh dA0KPiA+PiBleGFtcGxlPyBXZSB3b3VsZCByZWFsbHkgYXBwcmVjaWF0ZSBpdC4NCj4gPj4+Pj4N Cj4gPj4+Pj4gT24gdGhlIG90aGVyIGhhbmQsIHdvdWxkIGl0IGJlIGVub3VnaCB0byBpbmNsdWRl IHRoZSBVUkwgZm9yDQo+ID4+Pj4+IFRyYW5zZm9ybQ0KPiA+PiBUeXBlIDMgaHR0cHM6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvaWtldjItcGFyYW1ldGVycy9pa2V2Mi0NCj4gPj4gcGFyYW1l dGVycy54aHRtbCNpa2V2Mi1wYXJhbWV0ZXJzLTcgPw0KPiA+Pj4+Pg0KPiA+Pj4+PiAoU2FtZSBm b3IgVHJhbnNmb3JtIFR5cGUgMSwgVHJhbnNmb3JtIFR5cGUgNCkNCj4gPj4+Pj4NCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBUaGUgcmVmZXJlbmNlIGZvciBpbXBvcnQgb2YgaTJuc2YtaWtlYyBnaXZlcyBh IFlBTkcgbW9kdWxlIG5hbWU7DQo+ID4+Pj4+PiB0aGlzIG5lZWRzIHRvIGJlIHRoZSBuYW1lIG9m IHRoZSBSRkMgdG8gYmUNCj4gPj4+Pj4NCj4gPj4+Pj4gRml4ZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+ IGltcG9ydCBpZXRmLWkybnNmLWlrZWMgew0KPiA+Pj4+PiAgICAgICAgICAgICAgIHByZWZpeCBu c2Zpa2VjOw0KPiA+Pj4+PiAgICAgICAgICAgICAgIHJlZmVyZW5jZQ0KPiA+Pj4+PiAgICAgICAg ICAgICAgICAgICAiUkZDIFhYWFg6IFNvZnR3YXJlLURlZmluZWQgTmV0d29ya2luZw0KPiA+Pj4+ PiAgICAgICAgICAgICAgICAgIChTRE4pLWJhc2VkIElQc2VjIEZsb3cgUHJvdGVjdGlvbi4iOyB9 DQo+ID4+Pj4+DQo+ID4+Pj4+IFdlIHN0aWxsIHVzZSBYWFhYIGJlY2F1c2Ugd2UgZG8gbm90IGtu b3cgdGhlIG51bWJlciBhc3NpZ25lZCB0bw0KPiA+Pj4+PiB0aGUgUkZDDQo+ID4+IHRvIGJlLg0K PiA+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZSBleGFtcGxlIElQdjYgYWRkcmVzcyBpbiB0 aGUgWUFORyBtb2R1bGUgaGFzIDowOjA6IHdoaWNoIGlzDQo+ID4+Pj4+PiB1c3VhbGx5DQo+ID4+ IGp1c3QgOjoNCj4gPj4+Pj4NCj4gPj4+Pj4gRml4ZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+IElmIHlv dSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRzLCBwbGVhc2UgbGV0IHVzIGtub3cgc28gd2UgY2Fu DQo+ID4+Pj4+IGluY2x1ZGUgdGhlbSBpbiAtMTINCj4gPj4+Pj4NCj4gPj4+Pj4gQmVzdCBSZWdh cmRzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEFuZCBJIGhhdmUgc29tZSB3YXkgdG8gZ28gc3RpbGwu DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVG9tIFBldGNoDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gMjIv MTAvMjAyMCAxODozOSwgUmFmYSBNYXJpbi1Mb3BleiB3cm90ZToNCj4gPj4+Pj4+PiBEZWFyIGFs bDoNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEFmdGVyIHJlY2VpdmluZyBhIHN1Z2dlc3Rpb24gdG8g bWFrZSB0aGluZ3MgY2xlYXJlciBpbiB0aGUNCj4gPj4+Pj4+PiBmZWF0dXJlIGlrZWxlc3MtDQo+ ID4+IG5vdGlmaWNhdGlvbiBkZXNjcmlwdGlvbiwgd2UgaGF2ZSBqdXN0IHVwbG9hZGVkIGEgbmV3 IHZlcnNpb24gLTExDQo+ID4+IHdpdGggYSBtaW5vciBjaGFuZ2UgdG8gYWRkIHRoZSBmb2xsb3dp bmcgdGV4dDoNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IGZlYXR1cmUgaWtlbGVzcy1ub3RpZmljYXRp b24gew0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gPj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAiVGhpcyBmZWF0dXJlIGluZGljYXRlcyB0aGF0IHRoZSBzZXJ2ZXIgc3Vw cG9ydHMNCj4gPj4+Pj4+PiAgICAgICAgICAgICAgICAgICBnZW5lcmF0aW5nIG5vdGlmaWNhdGlv bnMgaW4gdGhlIGlrZWxlc3MgbW9kdWxlLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgVG8gZW5zdXJlIGJyb2FkZXIgYXBwbGljYWJpbGl0eSBvZiB0aGlzIG1vZHVsZSwN Cj4gPj4+Pj4+PiAgICAgICAgICAgICAgICAgICB0aGUgbm90aWZpY2F0aW9ucyBhcmUgbWFya2Vk IGFzIGEgZmVhdHVyZS4NCj4gPj4+Pj4+PiAgICAgICAgICAgICAgICAgICBGb3IgdGhlIGltcGxl bWVudGF0aW9uIG9mIGlrZWxlc3MgY2FzZSwNCj4gPj4+Pj4+PiAgICAgICAgICAgICAgICAgICB0 aGUgTlNGIGlzIGV4cGVjdGVkIHRvIGltcGxlbWVudCB0aGlzDQo+ID4+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgZmVhdHVyZS4iOw0KPiA+Pj4+Pj4+ICAgICAgICAgICB9DQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PiBCZXN0IFJlZ2FyZHMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSW5pY2lvIGRlbCBt ZW5zYWplIHJlZW52aWFkbzoNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gRGU6IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZw0KPiA+Pj4+Pj4+PiBBc3VudG86IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3INCj4gPj4+Pj4+Pj4gZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0 aW9uLTExLnR4dA0KPiA+Pj4+Pj4+PiBGZWNoYTogMjIgZGUgb2N0dWJyZSBkZSAyMDIwLCAxNToz Mjo1MCBDRVNUDQo+ID4+Pj4+Pj4+IFBhcmE6ICJGZXJuYW5kbyBQZXJlbmlndWV6LUdhcmNpYSIN Cj4gPj4+Pj4+Pj4gPGZlcm5hbmRvLnBlcmVuaWd1ZXpAY3VkLnVwY3QuZXM+LCAiUmFmYWVsIExv cGV6IiA8cmFmYUB1bS5lcz4sDQo+ID4+Pj4+Pj4+ICJHYWJyaWVsIExvcGV6LU1pbGxhbiIgPGdh YmlsbUB1bS5lcz4sICJSYWZhIE1hcmluLUxvcGV6Ig0KPiA+Pj4+Pj4+PiA8cmFmYUB1bS5lcz4N Cj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs DQo+ID4+Pj4+Pj4+IGRyYWZ0LWlldGYtaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJvdGVjdGlvbi0x MS50eHQNCj4gPj4+Pj4+Pj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSYWZh IE1hcmluLUxvcGV6IGFuZCBwb3N0ZWQNCj4gPj4+Pj4+Pj4gdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gTmFtZToJCWRyYWZ0LWlldGYtaTJuc2Ytc2RuLWlw c2VjLWZsb3ctcHJvdGVjdGlvbg0KPiA+Pj4+Pj4+PiBSZXZpc2lvbjoJMTENCj4gPj4+Pj4+Pj4g VGl0bGU6CQlTb2Z0d2FyZS1EZWZpbmVkIE5ldHdvcmtpbmcgKFNETiktYmFzZWQgSVBzZWMgRmxv dw0KPiA+PiBQcm90ZWN0aW9uDQo+ID4+Pj4+Pj4+IERvY3VtZW50IGRhdGU6CTIwMjAtMTAtMjIN Cj4gPj4+Pj4+Pj4gR3JvdXA6CQlpMm5zZg0KPiA+Pj4+Pj4+PiBQYWdlczoJCTkyDQo+ID4+Pj4+ Pj4+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0 LWlldGYtaTJuc2Ytc2RuLQ0KPiBpcHNlYy0NCj4gPj4gZmxvdy1wcm90ZWN0aW9uLTExLnR4dA0K PiA+Pj4+Pj4+PiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1pMm5zZi1zZG4tDQo+IGlwc2VjLQ0KPiA+PiBmbG93LXByb3RlY3Rpb24v DQo+ID4+Pj4+Pj4+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtaTJuc2YtDQo+IHNkbi0NCj4gPj4gaXBzZWMtZmxvdy1wcm90 ZWN0aW9uDQo+ID4+Pj4+Pj4+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtDQo+IGZsb3ctDQo+ID4+IHByb3RlY3Rp b24tMTENCj4gPj4+Pj4+Pj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWkybnNmLXNkbi0NCj4gaXBzZWMtDQo+ID4+IGZsb3ctcHJv dGVjdGlvbi0xMQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBBYnN0cmFjdDoNCj4gPj4+Pj4+Pj4g ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byBwcm92aWRlIElQc2VjLWJhc2VkIGZs b3cNCj4gcHJvdGVjdGlvbg0KPiA+Pj4+Pj4+PiAgICAgKGludGVncml0eSBhbmQgY29uZmlkZW50 aWFsaXR5KSBieSBtZWFucyBvZiBhbiBJbnRlcmZhY2UgdG8gTmV0d29yaw0KPiA+Pj4+Pj4+PiAg ICAgU2VjdXJpdHkgRnVuY3Rpb24gKEkyTlNGKSBjb250cm9sbGVyLiAgSXQgY29uc2lkZXJzIHR3 byBtYWluIHdlbGwtDQo+ID4+Pj4+Pj4+ICAgICBrbm93biBzY2VuYXJpb3MgaW4gSVBzZWM6IChp KSBnYXRld2F5LXRvLWdhdGV3YXkgYW5kIChpaSkgaG9zdC10by0NCj4gPj4+Pj4+Pj4gICAgIGhv c3QuICBUaGUgc2VydmljZSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhbGxvd3MgdGhlDQo+ ID4+Pj4+Pj4+ICAgICBjb25maWd1cmF0aW9uIGFuZCBtb25pdG9yaW5nIG9mIElQc2VjIFNlY3Vy aXR5IEFzc29jaWF0aW9ucyAoU0FzKQ0KPiA+Pj4+Pj4+PiAgICAgZnJvbSBhIEkyTlNGIENvbnRy b2xsZXIgdG8gb25lIG9yIHNldmVyYWwgZmxvdy1iYXNlZA0KPiA+Pj4+Pj4+PiBOZXR3b3JrDQo+ ID4+IFNlY3VyaXR5DQo+ID4+Pj4+Pj4+ICAgICBGdW5jdGlvbnMgKE5TRnMpIHRoYXQgcmVseSBv biBJUHNlYyB0byBwcm90ZWN0IGRhdGEgdHJhZmZpYy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4g ICAgIFRoZSBkb2N1bWVudCBmb2N1c2VzIG9uIHRoZSBJMk5TRiBOU0YtZmFjaW5nIGludGVyZmFj ZSBieQ0KPiBwcm92aWRpbmcNCj4gPj4+Pj4+Pj4gICAgIFlBTkcgZGF0YSBtb2RlbHMgZm9yIGNv bmZpZ3VyaW5nIHRoZSBJUHNlYyBkYXRhYmFzZXMgKFNQRCwNCj4gPj4+Pj4+Pj4gU0FELA0KPiA+ PiBQQUQpDQo+ID4+Pj4+Pj4+ICAgICBhbmQgSUtFdjIuICBUaGlzIGFsbG93cyBJUHNlYyBTQSBl c3RhYmxpc2htZW50IHdpdGggbWluaW1hbA0KPiA+Pj4+Pj4+PiAgICAgaW50ZXJ2ZW50aW9uIGJ5 IHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IuICBJdCBkb2VzIG5vdCBkZWZpbmUgYW55DQo+ID4+ Pj4+Pj4+ICAgICBuZXcgcHJvdG9jb2wuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lDQo+ID4+Pj4+Pj4+IG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZQ0KPiA+ Pj4+Pj4+PiBhdA0KPiA+PiB0b29scy5pZXRmLm9yZy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4g VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4+Pj4+PiBSYWZhIE1hcmluLUxvcGV6LCBQaEQNCj4gPj4+Pj4+PiBEZXB0 LiBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcgKERJSUMpIEZhY3Vs dHkNCj4gPj4+Pj4+PiBvZiBDb21wdXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2YgTXVyY2lhDQo+ ID4+Pj4+Pj4gMzAxMDAgTXVyY2lhIC0gU3BhaW4NCj4gPj4+Pj4+PiBUZWxmOiArMzQ4Njg4ODg1 MDEgRmF4OiArMzQ4Njg4ODQxNTEgZS1tYWlsOiByYWZhQHVtLmVzDQo+ID4+Pj4+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4gUmFmYSBNYXJpbi1Mb3Bleiwg UGhEDQo+ID4+Pj4+IERlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBFbmdpbmVl cmluZyAoRElJQykgRmFjdWx0eSBvZg0KPiA+Pj4+PiBDb21wdXRlciBTY2llbmNlLVVuaXZlcnNp dHkgb2YgTXVyY2lhDQo+ID4+Pj4+IDMwMTAwIE11cmNpYSAtIFNwYWluDQo+ID4+Pj4+IFRlbGY6 ICszNDg2ODg4ODUwMSBGYXg6ICszNDg2ODg4NDE1MSBlLW1haWw6IHJhZmFAdW0uZXMNCj4gPj4+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4NCj4g Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPj4+IFJhZmEgTWFyaW4tTG9wZXosIFBoRA0KPiA+Pj4gRGVwdC4gSW5mb3JtYXRpb24g YW5kIENvbW11bmljYXRpb25zIEVuZ2luZWVyaW5nIChESUlDKSBGYWN1bHR5IG9mDQo+ID4+PiBD b21wdXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2YgTXVyY2lhDQo+ID4+PiAzMDEwMCBNdXJjaWEg LSBTcGFpbg0KPiA+Pj4gVGVsZjogKzM0ODY4ODg4NTAxIEZheDogKzM0ODY4ODg0MTUxIGUtbWFp bDogcmFmYUB1bS5lcw0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ ID4+DQo+ID4+IC0tDQo+ID4+IGxhc3QtY2FsbCBtYWlsaW5nIGxpc3QNCj4gPj4gbGFzdC1jYWxs QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGFz dC1jYWxsDQo= From nobody Fri Oct 30 13:21:14 2020 Return-Path: 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 CCBB33A1215 for ; Fri, 30 Oct 2020 13:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 xMYvz2EMqyOD for ; Fri, 30 Oct 2020 13:21:07 -0700 (PDT) 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 F04013A1213 for ; Fri, 30 Oct 2020 13:21:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CNDGS4fn5zF8K; Fri, 30 Oct 2020 21:21:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1604089264; bh=GoRTTMwAHLHbm3XbwBulc9120yzfOEMEriU35fEk7kw=; h=From:Subject:Date:References:Cc:To; b=UjMkJCHV4d+8NZdtYefFk/K+mt//tsVplj5twKorc6xZLH5o0Q1Lusc217cZ8/qXP dbI9iio6fbwsO3DAIAPMMm5YnwRlXIMvQCpqfAMYL4Z5w63yfdxRL1TqV1qaBCpGGn hN7MFikBizdejzbsFbpifHaoqonf9VQJ1VKVw5Qg= 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 G9ymXWTktCK4; Fri, 30 Oct 2020 21:21:00 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 30 Oct 2020 21:20:58 +0100 (CET) Received: from [193.110.157.220] (unknown [193.110.157.220]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 8DBB96020F2B; Fri, 30 Oct 2020 16:20:57 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7EB7996D-C18E-42C9-A524-D754CDACE491 Content-Transfer-Encoding: 7bit From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Fri, 30 Oct 2020 16:20:55 -0400 Message-Id: References: <834a668ac559460a9f356bbb6c16b8fd@cert.org> Cc: tom petch To: "ipsec@ietf.org WG" X-Mailer: iPhone Mail (18A393) Archived-At: Subject: [IPsec] IKEv2 IANA registries, was Fwd: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 20:21:12 -0000 --Apple-Mail-7EB7996D-C18E-42C9-A524-D754CDACE491 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree we should make our IANA entries clearer. Begin forwarded message: > From: Roman Danyliw > Date: October 30, 2020 at 15:41:09 EDT > To: tom petch > Cc: ipsec@ietf.org, i2nsf@ietf.org, Gabriel Lopez , ynir.iet= f@gmail.com, Fernando Pereniguez-Garcia , l= ast-call@ietf.org, Rafa Marin-Lopez > Subject: Re: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn= -ipsec-flow-protection-11.txt >=20 > =EF=BB=BFHi Tom! >=20 >> -----Original Message----- >> From: tom petch >> Sent: Friday, October 30, 2020 7:14 AM >> To: Roman Danyliw ; Rafa Marin-Lopez >> Cc: i2nsf@ietf.org; Fernando Pereniguez-Garcia >> ; Gabriel Lopez ; >> ynir.ietf@gmail.com; last-call@ietf.org >> Subject: Re: [Last-Call] New Version Notification for draft-ietf-i2nsf-sd= n-ipsec- >> flow-protection-11.txt >>=20 >> Roman not this I-D but see below >>=20 >>> On 29/10/2020 18:46, Roman Danyliw wrote: >>> Hi Tom! >>>=20 >>>> -----Original Message----- >>>> From: last-call On Behalf Of tom petch >>>> Sent: Thursday, October 29, 2020 12:38 PM >>>> To: Rafa Marin-Lopez >>>> Cc: i2nsf@ietf.org; Fernando Pereniguez-Garcia >>>> ; Gabriel Lopez ; >>>> ynir.ietf@gmail.com; last-call@ietf.org >>>>=20 >>>> Top posting a new, related issue that may need Security AD or WG >>>> Chair to act on. >>>>=20 >>>> It seems to me that the IANA entries for IKEv2 are incomplete. >>>> RFC8247 does a fine job of specifying algorithms and adding >>>> information such as status (MUST/SHOULD+), IoT, AEAD and so on, >>>> information which is not present on IANA. The policy for, e.g. >>>> Transform Type 1, is expert review and entries have been added via >>>> draft-smyslov-esp-gont but the IANA entries lack this information >>>> and, looking at the I-D, I see no such information (nor is there any >>>> reason for it to be there). Yet draft-ietf-i2nsf-sdn... needs this inf= ormation >> as references in the YANG module show. >>>>=20 >>>> It seems to me that this is a similar situation to that which the TLS >>>> WG found itself in and which led to a revision of the TLS IANA >>>> entries to provide what was needed via additional columns. >>>=20 >>> Please help me understand. In particular, I'm not following why this >> document should modify IKE IANA registries. In my view, this document is= >> provides a data model to encode an "IKEv2 configuration" of sorts. Certa= inly, >> there are valid/invalid/incomplete/not recommended ways to provide a >> configuration with this data model if one relied solely on the pointers t= o the >> IANA registries from the YANG module definition. However, as you noted, >> RFC8247 already provides guidance on specifying a configuration (albeit t= his >> guidance isn't fully encoded in the registries). Furthermore, this docum= ent >> states: >>>=20 >>> Section 8.1 >>> o IKEv2 configurations should adhere to the recommendations in >>> [RFC8247]. >>>=20 >>> so there is guidance on producing a configuration. What is missing? >>>=20 >>>> I think that the IANA pages for IKEv2 need revising so that that >>>> additional information that RFC8247 provides is required as >>>> additional columns in the IANA entries at least for Type 1, Type 2, >>>> Type 3, Type 4 and Authentication Method. >>>=20 >>> While things could be clearer, I'm unsure of why _this YANG document_ >> should do a registry reengineering. Did you mean it should be done in ge= neral? >>=20 >> Not this I-D but another I-D from a WG with closer links to IKEv2; I don'= t know >> which WG that would be but a Security AD would:-) >=20 > Thanks for clarifying. IPSECME (https://datatracker.ietf.org/wg/ipsecme/a= bout/) (who has been cross-posted with this note) is likely the best place t= o handle IPsec maintenance and the kind of registry modifications you descri= be below. >=20 > Regards, > Roman >=20 >> This I-D, as you quote, points to RFC8247 for guidance and that is fine. >> But security moves on and new algorithms will be needed and this I-D als= o >> points to the IANA registry, which is Expert Review, where new entries ha= ve >> been added already; and for those the IANA Registry gives no guidance and= the >> I-D that IANA references for the new entries - written by the Expert Revi= ewer! - >> also gives no guidance. Over time we are likely to accrue algorithms with= no >> guidance unless and until an RFC8247-bis appears or we require IANA to ha= ve >> columns for guidance. >> Currently the new algorithms are GOST and so perhaps of limited interest b= ut >> on the TLS list I am always seeing new algorithms appear and there the ne= w >> IANA entry is required to give guidance. My sense is that IKEv2 is a bit= slower >> to take up new ones but, as with RFC8247, it does eventually. >>=20 >> I think that users need those extra columns that RFC8247 provides on the I= ANA >> website so that when new algorithms are added by Expert Review, then that= >> guidance must be added as well. This is what the TLS WG came round to an= d I >> think that IKEv2 needs to do the same. >>=20 >> Tom Petch >>=20 >>=20 >>> Regards, >>> Roman >>>=20 >>>> Tom Petch >>>>=20 >>>> On 29/10/2020 11:23, Rafa Marin-Lopez wrote: >>>>> Hi Tom: >>>>>=20 >>>>>> El 28 oct 2020, a las 19:02, tom petch >> escribi=C3=B3: >>>>>>=20 >>>>>> On 28/10/2020 10:42, Rafa Marin-Lopez wrote: >>>>>>> Hi Tom: >>>>>>>=20 >>>>>>> Thank you very much for your insight. It is very helpful. Please >>>>>>> see our >>>> comments/questions inline. >>>>>>>=20 >>>>>>>> El 27 oct 2020, a las 13:42, tom petch >>>> escribi=C3=B3: >>>>>>>>=20 >>>>>>>> I think that the IESG will find a number of problems with this I-D.= >>>>>>>>=20 >>>>>>>> YANG module references RFC822 which is several years out of date >>>>>>=20 >>>>>> Rafa >>>>>>=20 >>>>>> On boiler plate, I mean the reference to RFC2119 which now must use >>>>>> the >>>> language from RFC8174 in the body of the I-D; sorry for the confusion. >>>>>=20 >>>>> Ah ok. I guess you are referring to change that paragraph with this: >>>>>=20 >>>>>=20 >>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", >>>> "MAY", and >>>>> "OPTIONAL" in this document are to be interpreted as described in >>>>> BCP >>>>> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, >>>>> as shown here. >>>>>=20 >>>>>>=20 >>>>>> On XXXX, you have XXXX standing in for more than one RFC-to-be >>>>>> which >>>> confuses. The convention is to use XXXX for this I-D and then AAAA >>>> BBBB etc for any others such as the netconf I-D in this instance. >>>>>=20 >>>>> Ah ok. In any case, we have now only XXXX for our RFC-to-be so >>>>> problem >>>> fixed. >>>>>>=20 >>>>>> Two big issues, for me (perhaps not for others). The convention >>>>>> with YANG >>>> is for each successive line to be indented two characters, you have >>>> four, which creates a lot of white space and pushes the text to the >>>> right hand margin. I think that two characters is the default when >>>> you use pyang to format a YANG module. >>>>>=20 >>>>> We can try to reduce it to two characters. >>>>>=20 >>>>>>=20 >>>>>> And references. I have had to work harder than I want to to make >>>>>> sense of the IANA references. I think you should have five >>>>>> separate references in the I-D for IANA for Transform Type 1 >>>>>> Transform Type 3 Transform Type 4 Authentication Method Protocol >>>>>> Numbers and each reference in the I-D should have a URL pointing to >>>>>> the specific section of >>>> IANA web site. >>>>>=20 >>>>> Ok, good. This follows what we thought. >>>>>=20 >>>>>> In the YANG, it is harder to know what to do. Those first three >>>>>> references >>>> are in the third tier i.e. >>>>>> Group - Internet Key Exchange V2 (IKEv2) Parameters Registry >>>>>> -Transform Attribute Types and then Type 1, 3, 4 as the third tier >>>>>> as I am calling it and I think that every reference in the YANG >>>>>> should give me all three tiers after IANA in that order perhaps >>>>>> IANA; IKEv2 Parameters; Transform Atribute Types; Transform Type 1 >>>>>=20 >>>>> Great. We also considered this as a possible solution after sending ou= r e- >> mail. >>>> Let=E2=80=99s do it. >>>>>=20 >>>>>> If the syntax needs tweeking, then the RFC Editor will do a good >>>>>> job of that >>>> but at present the references are inconsistent in which elements are >>>> specified in what order and that is something the RFC Editor probably >> cannot cope with. >>>>>> Authentication Method is a registry so that just needs Group name >>>>>> and >>>> Registry name after IANA. >>>>>=20 >>>>> Ok, good. >>>>>>=20 >>>>>> Some minor glitches. >>>>>> I-D appears twice in the body of the I-D - perhaps document or memo. >>>>>=20 >>>>> Ok. >>>>>=20 >>>>>> objetives/objectives/ >>>>>=20 >>>>> Fixed. >>>>>> end port number perhaps /must/MUST/ >>>>>=20 >>>>>> and YANG is very good at including such checks with a must .... >>>>>> 'If AEAD is used .. where? this occurs in several places and I >>>>>> think that you >>>> need to specify the leaf where AEAD will be specified or implied. >>>>>=20 >>>>> Ok we have changed it to: >>>>>=20 >>>>> If Authenticated Encryption with Associated Data (AEAD) is used >>>>> (leaf >>>>> esp-algorithms/encryption/algorithm-type) >>>>> this flag MUST be false." >>>>>=20 >>>>>> And is it possible to make that a YANG 'must' statement - looking >>>>>> at the >>>> IKEv2 registries it is not obvious which are AEAD so that might be >>>> more complexity than it is worth. >>>>>> 'only available on linux kernels' Um implementation detail, you may >>>>>> get >>>> asked to remove that altogether or at least to a Informative Appendix >>>> - I would leave it in for now. >>>>>=20 >>>>> Ok. >>>>>=20 >>>>>> 'import ietf-i2nsf-ikec' the reference needs to be to a RFC and if >>>>>> it is not yet an RFC then RFC XXXX in both Appendix B and C >>>>>=20 >>>>> Yes, we have changed that to: >>>>>=20 >>>>> RFC XXXX: Software-Defined Networking >>>>> (SDN)-based IPsec Flow Protection. >>>>>=20 >>>>>> leaf-list pfs-groups could do with a reference - Transform Type 4? >>>>>=20 >>>>> The leaf list is referring to type pfs-group and we have now >>>>>=20 >>>>> typedef pfs-group { >>>>> type uint16; >>>>> description >>>>> "DH groups for IKE and IPsec SA rekey."; >>>>> reference >>>>> "IANA; Internet Key Exchange V2 (IKEv2) Parameters; >>>>> Transform Atribute Types; Transform Type 4 - >>>>> Diffie-Hellman Group Transform IDs. >>>>> Section 3.3.2 in RFC 7296."; >>>>> } >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I am still working my way through the YANG so may have some more >>>> comments tomorrow. >>>>>=20 >>>>> Ok, do not worry we will work in -12 with these comments so far to >>>>> have a >>>> quick response. We can prepare a another version later with the rest of= >> them. >>>>>=20 >>>>> Thank you very much for your effort. >>>>>>=20 >>>>>> Tom Petch >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> We have realized that we missed to change this, even though we >>>>>>> discussed >>>> it. We will change it right away in the following way (bold): >>>>>>>=20 >>>>>>> case rfc822-address-string { >>>>>>> leaf rfc822-address-string { >>>>>>> type string; >>>>>>> description >>>>>>> "Specifies the identity as a >>>>>>> fully-qualified RFC5322 email >>>>>>> address string. An example is, >>>>>>> jsmith@example.com. The string >>>>>>> MUST NOT contain any >>>>>>> terminators e.g., NULL, CR, >>>>>>> etc.)."; >>>>>>> reference >>>>>>> "RFC 5322."; >>>>>>> } >>>>>>> } >>>>>>>=20 >>>>>>> Btw, we already used in the past =E2=80=9Ccase rfc822-address-string= =E2=80=9D and >>>>>>> =E2=80=9Cleaf >>>> rfc822-address-string=E2=80=9D since this is coming from IKEv2 standard= . Do >>>> you think we should change that name as well? >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> YANG module references IANA Protocol Numbers which is not in the >>>>>>>> I-D references >>>>>>>=20 >>>>>>> We have included the following reference: >>>>>>>=20 >>>>>>> [IANA-Protocols-Number] >>>>>>> Internet Assigned Numbers Authority (IANA), "Protocol= >>>>>>> Numbers", January 2020. >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> s.2 boiler plate is out of date >>>>>>>=20 >>>>>>> What we see is the I-D has the second choice stated in >>>>>>> https://www.ietf.org/standards/ids/guidelines/ >>>>>>>=20 >>>>>>> This Internet-Draft is submitted in full conformance with the >>>>>>> provisions of BCP 78 and BCP 79. >>>>>>>=20 >>>>>>> Internet-Drafts are working documents of the Internet Engineerin= g >>>>>>> Task Force (IETF). Note that other groups may also distribute >>>>>>> working documents as Internet-Drafts. The list of current Inter= net- >>>>>>> Drafts is at https://datatracker.ietf.org/drafts/current/. >>>>>>>=20 >>>>>>> Internet-Drafts are draft documents valid for a maximum of six >> months >>>>>>> and may be updated, replaced, or obsoleted by other documents at= >> any >>>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>>> material or to cite them other than as "work in progress." >>>>>>>=20 >>>>>>> Could you refer what is out of date? >>>>>>>=20 >>>>>>>>=20 >>>>>>>> XXXX is standing in for more than one RFC >>>>>>>=20 >>>>>>> Yes, XXXX has been used because we do not know the future number >>>> assigned to our I-D. >>>>>>>=20 >>>>>>> Also we realized we also included this to refer to crypto-types >>>>>>> I-D but this >>>> has been solved now in a new version -12 that we are preparing to >>>> include your comments. We noticed we can replace the type of rw >>>> cert-data?, ca-data*, crl- data? for binary without any problem. >>>>>>>=20 >>>>>>> | | +--rw cert-data? binary >>>>>>> | +--rw private-key? binary >>>>>>> | +--rw ca-data* binary >>>>>>> | +--rw crl-data? binary >>>>>>>=20 >>>>>>>>=20 >>>>>>>> but the show stopper that makes a proper review of this too >>>>>>>> costly is the >>>> references. Those to IANA of which there are several I want to >>>> pursue. The I-D reference is to IKEv2 parameters. Sadly, this is a >>>> three tier structure and noone agrees on what to call the third tier >>>> so I will call it tier3 here. Top level is Group, as per RFC8126, >>>> second level is Registry. The I-D reference is to the Group only >>>> which is fine if the actual reference then specifies the Registry and >>>> Tier3 but they never do, usually just Tier3 e.g. Transform Type 3 >>>> which makes for a lot of work for the reader, too much for this one. >>>> You have to go hunting in all the second level Registry until you can >>>> find a match for the Tier3 identifier. And there are no URL. If you >>>> want an example that I find easy to use, go look at RFC8407 (as usual).= >>>>>>>=20 >>>>>>> You=E2=80=99re right. Could you point the exact part at RFC 8407 wit= h that >>>> example? We would really appreciate it. >>>>>>>=20 >>>>>>> On the other hand, would it be enough to include the URL for >>>>>>> Transform >>>> Type 3 https://www.iana.org/assignments/ikev2-parameters/ikev2- >>>> parameters.xhtml#ikev2-parameters-7 ? >>>>>>>=20 >>>>>>> (Same for Transform Type 1, Transform Type 4) >>>>>>>=20 >>>>>>>>=20 >>>>>>>> The reference for import of i2nsf-ikec gives a YANG module name; >>>>>>>> this needs to be the name of the RFC to be >>>>>>>=20 >>>>>>> Fixed. >>>>>>>=20 >>>>>>> import ietf-i2nsf-ikec { >>>>>>> prefix nsfikec; >>>>>>> reference >>>>>>> "RFC XXXX: Software-Defined Networking >>>>>>> (SDN)-based IPsec Flow Protection."; } >>>>>>>=20 >>>>>>> We still use XXXX because we do not know the number assigned to >>>>>>> the RFC >>>> to be. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> The example IPv6 address in the YANG module has :0:0: which is >>>>>>>> usually >>>> just :: >>>>>>>=20 >>>>>>> Fixed. >>>>>>>=20 >>>>>>> If you have any further comments, please let us know so we can >>>>>>> include them in -12 >>>>>>>=20 >>>>>>> Best Regards. >>>>>>>>=20 >>>>>>>> And I have some way to go still. >>>>>>>>=20 >>>>>>>> Tom Petch >>>>>>>>=20 >>>>>>>> On 22/10/2020 18:39, Rafa Marin-Lopez wrote: >>>>>>>>> Dear all: >>>>>>>>>=20 >>>>>>>>> After receiving a suggestion to make things clearer in the >>>>>>>>> feature ikeless- >>>> notification description, we have just uploaded a new version -11 >>>> with a minor change to add the following text: >>>>>>>>>=20 >>>>>>>>> feature ikeless-notification { >>>>>>>>> description >>>>>>>>> "This feature indicates that the server supports >>>>>>>>> generating notifications in the ikeless module. >>>>>>>>>=20 >>>>>>>>> To ensure broader applicability of this module, >>>>>>>>> the notifications are marked as a feature. >>>>>>>>> For the implementation of ikeless case, >>>>>>>>> the NSF is expected to implement this >>>>>>>>> feature."; >>>>>>>>> } >>>>>>>>>=20 >>>>>>>>> Best Regards. >>>>>>>>>=20 >>>>>>>>>> Inicio del mensaje reenviado: >>>>>>>>>>=20 >>>>>>>>>> De: internet-drafts@ietf.org >>>>>>>>>> Asunto: New Version Notification for >>>>>>>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt >>>>>>>>>> Fecha: 22 de octubre de 2020, 15:32:50 CEST >>>>>>>>>> Para: "Fernando Pereniguez-Garcia" >>>>>>>>>> <fernando.pereniguez@cud.upct.es>, "Rafael Lopez" <rafa@um.es>, >>>>>>>>>> "Gabriel Lopez-Millan" <gabilm@um.es>, "Rafa Marin-Lopez" >>>>>>>>>> <rafa@um.es> >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> A new version of I-D, >>>>>>>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt >>>>>>>>>> has been successfully submitted by Rafa Marin-Lopez and posted >>>>>>>>>> to the IETF repository. >>>>>>>>>>=20 >>>>>>>>>> Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection >>>>>>>>>> Revision: 11 >>>>>>>>>> Title: Software-Defined Networking (SDN)-based IPsec Flow >>>> Protection >>>>>>>>>> Document date: 2020-10-22 >>>>>>>>>> Group: i2nsf >>>>>>>>>> Pages: 92 >>>>>>>>>> URL: https://www.ietf.org/archive/id/draft-ietf-i2nsf-= sdn- >> ipsec- >>>> flow-protection-11.txt >>>>>>>>>> Status: https://datatracker.ietf.org/doc/draft-ietf-i2nsf= -sdn- >> ipsec- >>>> flow-protection/ >>>>>>>>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-= i2nsf- >> sdn- >>>> ipsec-flow-protection >>>>>>>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-= ipsec- >> flow- >>>> protection-11 >>>>>>>>>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2= nsf-sdn- >> ipsec- >>>> flow-protection-11 >>>>>>>>>>=20 >>>>>>>>>> Abstract: >>>>>>>>>> This document describes how to provide IPsec-based flow >> protection >>>>>>>>>> (integrity and confidentiality) by means of an Interface to Ne= twork >>>>>>>>>> Security Function (I2NSF) controller. It considers two main w= ell- >>>>>>>>>> known scenarios in IPsec: (i) gateway-to-gateway and (ii) host= -to- >>>>>>>>>> host. The service described in this document allows the >>>>>>>>>> configuration and monitoring of IPsec Security Associations (S= As) >>>>>>>>>> from a I2NSF Controller to one or several flow-based >>>>>>>>>> Network >>>> Security >>>>>>>>>> Functions (NSFs) that rely on IPsec to protect data traffic. >>>>>>>>>>=20 >>>>>>>>>> The document focuses on the I2NSF NSF-facing interface by >> providing >>>>>>>>>> YANG data models for configuring the IPsec databases (SPD, >>>>>>>>>> SAD, >>>> PAD) >>>>>>>>>> and IKEv2. This allows IPsec SA establishment with minimal >>>>>>>>>> intervention by the network administrator. It does not define= any >>>>>>>>>> new protocol. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Please note that it may take a couple of minutes from the time >>>>>>>>>> of submission until the htmlized version and diff are available >>>>>>>>>> at >>>> tools.ietf.org. >>>>>>>>>>=20 >>>>>>>>>> The IETF Secretariat >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ------------------------------------------------------- >>>>>>>>> Rafa Marin-Lopez, PhD >>>>>>>>> Dept. Information and Communications Engineering (DIIC) Faculty >>>>>>>>> of Computer Science-University of Murcia >>>>>>>>> 30100 Murcia - Spain >>>>>>>>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>>>>>>>> ------------------------------------------------------- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>> ------------------------------------------------------- >>>>>>> Rafa Marin-Lopez, PhD >>>>>>> Dept. Information and Communications Engineering (DIIC) Faculty of >>>>>>> Computer Science-University of Murcia >>>>>>> 30100 Murcia - Spain >>>>>>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>>>>>> ------------------------------------------------------- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> ------------------------------------------------------- >>>>> Rafa Marin-Lopez, PhD >>>>> Dept. Information and Communications Engineering (DIIC) Faculty of >>>>> Computer Science-University of Murcia >>>>> 30100 Murcia - Spain >>>>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>>>> ------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> -- >>>> last-call mailing list >>>> last-call@ietf.org >>>> https://www.ietf.org/mailman/listinfo/last-call > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail-7EB7996D-C18E-42C9-A524-D754CDACE491 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><br><br><div dir=3D"ltr">I agree we should m= ake our IANA entries clearer.</div><div dir=3D"ltr"><br>Begin forwarded mess= age:<br><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><b>From:</b> Ro= man Danyliw <rdd@cert.org><br><b>Date:</b> October 30, 2020 at 15:41:0= 9 EDT<br><b>To:</b> tom petch <daedulus@btconnect.com><br><b>Cc:</b> i= psec@ietf.org, i2nsf@ietf.org, Gabriel Lopez <gabilm@um.es>, ynir.ietf= @gmail.com, Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es&g= t;, last-call@ietf.org, Rafa Marin-Lopez <rafa@um.es><br><b>Subject:</= b> <b>Re: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipse= c-flow-protection-11.txt</b><br><br></div></blockquote><blockquote type=3D"c= ite"><div dir=3D"ltr">=EF=BB=BF<span>Hi Tom!</span><br><span></span><br><blo= ckquote type=3D"cite"><span>-----Original Message-----</span><br></blockquot= e><blockquote type=3D"cite"><span>From: tom petch <daedulus@btconnect.com= ></span><br></blockquote><blockquote type=3D"cite"><span>Sent: Friday, Oc= tober 30, 2020 7:14 AM</span><br></blockquote><blockquote type=3D"cite"><spa= n>To: Roman Danyliw <rdd@cert.org>; Rafa Marin-Lopez <rafa@um.es>= ;</span><br></blockquote><blockquote type=3D"cite"><span>Cc: i2nsf@ietf.org;= Fernando Pereniguez-Garcia</span><br></blockquote><blockquote type=3D"cite"= ><span><fernando.pereniguez@cud.upct.es>; Gabriel Lopez <gabilm@um.= es>;</span><br></blockquote><blockquote type=3D"cite"><span>ynir.ietf@gma= il.com; last-call@ietf.org</span><br></blockquote><blockquote type=3D"cite">= <span>Subject: Re: [Last-Call] New Version Notification for draft-ietf-i2nsf= -sdn-ipsec-</span><br></blockquote><blockquote type=3D"cite"><span>flow-prot= ection-11.txt</span><br></blockquote><blockquote type=3D"cite"><span></span>= <br></blockquote><blockquote type=3D"cite"><span>Roman  not this I-D bu= t see below</span><br></blockquote><blockquote type=3D"cite"><span></span><b= r></blockquote><blockquote type=3D"cite"><span>On 29/10/2020 18:46, Roman Da= nyliw wrote:</span><br></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><span>Hi Tom!</span><br></blockquote></blockquote><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockq= uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>-----Original Message-----</span><br></blockquote></blockquote>= </blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>From: last-call <last-call-bounces@ietf.org> On B= ehalf Of tom petch</span><br></blockquote></blockquote></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>= Sent: Thursday, October 29, 2020 12:38 PM</span><br></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><span>To: Rafa Marin-Lopez <rafa@um.es></span><br></b= lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><span>Cc: i2nsf@ietf.org; Fernando Per= eniguez-Garcia</span><br></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span><f= ernando.pereniguez@cud.upct.es>; Gabriel Lopez <gabilm@um.es>;</spa= n><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><span>ynir.ietf@gmail.com; la= st-call@ietf.org</span><br></blockquote></blockquote></blockquote><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></= span><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><span>Top posting a new, r= elated issue that may need Security AD or WG</span><br></blockquote></blockq= uote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><span>Chair to act on.</span><br></blockquote></blockquo= te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><span></span><br></blockquote></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span>It seems to me that the IANA entries for IKEv2 are incomplete.</span><= br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><span>RFC8247 does a fine job of= specifying algorithms and adding</span><br></blockquote></blockquote></bloc= kquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>information such as status (MUST/SHOULD+), IoT, AEAD and so on,= </span><br></blockquote></blockquote></blockquote><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><span>information which i= s not present on IANA.  The policy for, e.g.</span><br></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><span>Transform Type 1, is expert review and entrie= s have been added via</span><br></blockquote></blockquote></blockquote><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><sp= an>draft-smyslov-esp-gont but the IANA entries lack this information</span><= br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><span>and, looking at the I-D, I= see no such information (nor is there any</span><br></blockquote></blockquo= te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><span>reason for it to be there).  Yet draft-ietf-i2n= sf-sdn... needs this information</span><br></blockquote></blockquote></block= quote><blockquote type=3D"cite"><span>as references in the YANG module show.= </span><br></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><span></span><br></blockquote></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>It seems to me that this is a similar situation to that which t= he TLS</span><br></blockquote></blockquote></blockquote><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>WG found its= elf in and which led to a revision of the TLS IANA</span><br></blockquote></= blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><span>entries to provide what was needed via addit= ional columns.</span><br></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Please help m= e understand.  In particular, I'm not following why this</span><br></bl= ockquote></blockquote><blockquote type=3D"cite"><span>document should modify= IKE IANA registries.  In my view, this document is</span><br></blockqu= ote><blockquote type=3D"cite"><span>provides a data model to encode an "IKEv= 2 configuration" of sorts.  Certainly,</span><br></blockquote><blockquo= te type=3D"cite"><span>there are valid/invalid/incomplete/not recommended wa= ys to provide a</span><br></blockquote><blockquote type=3D"cite"><span>confi= guration with this data model if one relied solely on the pointers to the</s= pan><br></blockquote><blockquote type=3D"cite"><span>IANA registries from th= e YANG module definition.  However, as you noted,</span><br></blockquot= e><blockquote type=3D"cite"><span>RFC8247 already provides guidance on speci= fying a configuration (albeit this</span><br></blockquote><blockquote type=3D= "cite"><span>guidance isn't fully encoded in the registries).  Furtherm= ore, this document</span><br></blockquote><blockquote type=3D"cite"><span>st= ates:</span><br></blockquote><blockquote type=3D"cite"><blockquote type=3D"c= ite"><span></span><br></blockquote></blockquote><blockquote type=3D"cite"><b= lockquote type=3D"cite"><span>Section 8.1</span><br></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><span>   &nb= sp;o  IKEv2 configurations should adhere to the recommendations in</spa= n><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>       [RFC8247].</span><br></blo= ckquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><sp= an></span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquot= e type=3D"cite"><span>so there is guidance on producing a configuration. &nb= sp;What is missing?</span><br></blockquote></blockquote><blockquote type=3D"= cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><span>I think that the IANA pages for IKEv2 need revising so that that</spa= n><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><span>additional information t= hat RFC8247 provides is required as</span><br></blockquote></blockquote></bl= ockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote typ= e=3D"cite"><span>additional columns in the IANA entries at least for Type 1,= Type 2,</span><br></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Type 3, Typ= e 4 and Authentication Method.</span><br></blockquote></blockquote></blockqu= ote><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= span>While things could be clearer, I'm unsure of why _this YANG document_</= span><br></blockquote></blockquote><blockquote type=3D"cite"><span>should do= a registry reengineering.  Did you mean it should be done in general?<= /span><br></blockquote><blockquote type=3D"cite"><span></span><br></blockquo= te><blockquote type=3D"cite"><span>Not this I-D but another I-D from a WG wi= th closer links to IKEv2; I don't know</span><br></blockquote><blockquote ty= pe=3D"cite"><span>which WG that would be but a Security AD would:-)</span><b= r></blockquote><span></span><br><span>Thanks for clarifying.  IPSECME (= https://datatracker.ietf.org/wg/ipsecme/about/) (who has been cross-posted w= ith this note)  is likely the best place to handle IPsec maintenance an= d the kind of registry modifications you describe below.</span><br><span></s= pan><br><span>Regards,</span><br><span>Roman</span><br><span></span><br><blo= ckquote type=3D"cite"><span>This I-D, as you quote, points to RFC8247 for gu= idance and that is fine.</span><br></blockquote><blockquote type=3D"cite"><s= pan>  But security moves on and new algorithms will be needed and this I= -D also</span><br></blockquote><blockquote type=3D"cite"><span>points to the= IANA registry, which is Expert Review, where new entries have</span><br></b= lockquote><blockquote type=3D"cite"><span>been added already; and for those t= he IANA Registry gives no guidance and the</span><br></blockquote><blockquot= e type=3D"cite"><span>I-D that IANA references for the new entries - written= by the Expert Reviewer! -</span><br></blockquote><blockquote type=3D"cite">= <span>also gives no guidance. Over time we are likely to accrue algorithms w= ith no</span><br></blockquote><blockquote type=3D"cite"><span>guidance unles= s and until an RFC8247-bis appears or we require IANA to have</span><br></bl= ockquote><blockquote type=3D"cite"><span>columns for guidance.</span><br></b= lockquote><blockquote type=3D"cite"><span>Currently the new algorithms are G= OST and so perhaps of limited interest but</span><br></blockquote><blockquot= e type=3D"cite"><span>on the TLS list I am always seeing new algorithms appe= ar and there the new</span><br></blockquote><blockquote type=3D"cite"><span>= IANA entry is required to give guidance.  My sense is that IKEv2 is a b= it slower</span><br></blockquote><blockquote type=3D"cite"><span>to take up n= ew ones but, as with RFC8247, it does eventually.</span><br></blockquote><bl= ockquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cit= e"><span>I think that users need those extra columns that RFC8247 provides o= n the IANA</span><br></blockquote><blockquote type=3D"cite"><span>website so= that when new algorithms are added by Expert Review, then that</span><br></= blockquote><blockquote type=3D"cite"><span>guidance must be added as well. &= nbsp;This is what the TLS WG came round to and I</span><br></blockquote><blo= ckquote type=3D"cite"><span>think that IKEv2 needs to do the same.</span><br= ></blockquote><blockquote type=3D"cite"><span></span><br></blockquote><block= quote type=3D"cite"><span>Tom Petch</span><br></blockquote><blockquote type=3D= "cite"><span></span><br></blockquote><blockquote type=3D"cite"><span></span>= <br></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>R= egards,</span><br></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><span>Roman</span><br></blockquote></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span>Tom Petch</span><br></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><span></span><br></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>On 29/10= /2020 11:23, Rafa Marin-Lopez wrote:</span><br></blockquote></blockquote></b= lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><span>Hi Tom:</span><br></blockquote><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></spa= n><br></blockquote></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>El 28 oct 2020, a las 19:02, tom petc= h <daedulus@btconnect.com></span><br></blockquote></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><span>escribi=C3=B3= :</span><br></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><span></span><br></blockquote></blockquote></blockquote></blockquote></bl= ockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>On 28/1= 0/2020 10:42, Rafa Marin-Lopez wrote:</span><br></blockquote></blockquote></= blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span>Hi Tom:</span><br></blockquot= e></blockquote></blockquote></blockquote></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= ></span><br></blockquote></blockquote></blockquote></blockquote></blockquote= ></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><span>Thank you very much for your insight. It is very hel= pful. Please</span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span>see our</span><br></blockquote></blockquo= te></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>comments/ques= tions inline.</span><br></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></s= pan><br></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>El 27 oct 2020, a las 13:42, to= m petch <daedulus@btconnect.com></span><br></blockquote></blockquote><= /blockquote></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>escri= bi=C3=B3:</span><br></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>I= think that the IESG will find a number of problems with this I-D.</span><br= ></blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><span>YANG module references RFC822 which is= several years out of date</span><br></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></b= lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span>Rafa</span><br></blockquote></blockquote></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><span></span><br></blockquote></blockquote></blockquote></blockquote></bloc= kquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>On boiler p= late, I mean the reference to RFC2119 which now must use</span><br></blockqu= ote></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>the</span><br></blockquote></blockquo= te></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><span>language from RFC8174 in t= he body of the I-D; sorry for the confusion.</span><br></blockquote></blockq= uote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote>= </blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Ah o= k. I guess you are referring to change that paragraph with this:</span><br><= /blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><span></span><br></blockquote></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><span></span><br></blockquote></blockquote></blockqu= ote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span>The key words "MUST", "MU= ST NOT", "REQUIRED", "SHALL", "SHALL NOT",</span><br></blockquote></blockquo= te></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>"SHOULD", "SH= OULD NOT", "RECOMMENDED", "NOT RECOMMENDED",</span><br></blockquote></blockq= uote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>"MAY", and</span><br></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><span>"OPTIONAL" in this d= ocument are to be interpreted as described in</span><br></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>BCP</span><= br></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>14 RFC2119 RFC8174 when, and only when, they appear in all capi= tals,</span><br></blockquote></blockquote></blockquote></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><span>as shown here.</span><br></blockquote></blockquote= ></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></bl= ockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><span></span><br></blockquote></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>On XXXX, you have XXXX standing in for more than one RFC-to-be<= /span><br></blockquote></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span>which</span><br><= /blockquote></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>confu= ses.  The convention is to use XXXX for this I-D and then AAAA</span><b= r></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><span>BBBB etc for any others suc= h as the netconf I-D in this instance.</span><br></blockquote></blockquote><= /blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Ah ok. In a= ny case, we have now only XXXX for our RFC-to-be so</span><br></blockquote><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>probl= em</span><br></blockquote></blockquote></blockquote></blockquote><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>fix= ed.</span><br></blockquote></blockquote></blockquote><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></= blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>Two big issues, for me (perhaps not for others).  = The convention</span><br></blockquote></blockquote></blockquote></blockquote= ></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>wi= th YANG</span><br></blockquote></blockquote></blockquote></blockquote></bloc= kquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>is for each successive line to be indented two characters, you h= ave</span><br></blockquote></blockquote></blockquote><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>four, which cre= ates a lot of white space and pushes the text to the</span><br></blockquote>= </blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><span>right hand margin.  I think that two c= haracters is the default when</span><br></blockquote></blockquote></blockquo= te><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><span>you use pyang to format a YANG module.</span><br></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa= n>We can try to reduce it to two characters.</span><br></blockquote></blockq= uote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></b= lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span>And references.  I have had to work harder than I wa= nt to to make</span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>sen= se of the IANA references.  I think you should have five</span><br></bl= ockquote></blockquote></blockquote></blockquote></blockquote><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>separate references in the I-D f= or IANA for Transform Type 1</span><br></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><span>Transform Type 3 Transform Type 4 Authentication Method Protocol= </span><br></blockquote></blockquote></blockquote></blockquote></blockquote>= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Numbers and each= reference in the I-D should have a URL pointing to</span><br></blockquote><= /blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span>the specific section of</span><br></block= quote></blockquote></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>IANA web si= te.</span><br></blockquote></blockquote></blockquote><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><span></span><br></blockquote></blockquote></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><span>Ok, good. This follows what we thought.</spa= n><br></blockquote></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><span>In the YANG, it i= s harder to know what to do.  Those first three</span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>references</span><br></blockquote></bloc= kquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span>are in the third tier i= .e.</span><br></blockquote></blockquote></blockquote><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><span>Group - Internet Key Exchange V2 (IKEv2= ) Parameters Registry</span><br></blockquote></blockquote></blockquote></blo= ckquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= span>-Transform Attribute Types and then Type 1, 3, 4 as the third tier</spa= n><br></blockquote></blockquote></blockquote></blockquote></blockquote><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><span>as I am calling it an= d I think that every reference in the YANG</span><br></blockquote></blockquo= te></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><span>should give me all three tiers after IANA in that o= rder perhaps</span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>IANA;= IKEv2 Parameters; Transform Atribute Types; Transform Type 1</span><br></bl= ockquote></blockquote></blockquote></blockquote></blockquote><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span></span><br></blockquote></blockquote></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>Great. We also considered this as a p= ossible solution after sending our e-</span><br></blockquote></blockquote></= blockquote></blockquote><blockquote type=3D"cite"><span>mail.</span><br></bl= ockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote typ= e=3D"cite"><span>Let=E2=80=99s do it.</span><br></blockquote></blockquote></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>If the syntax needs tweeking, then the RFC Editor will do a goo= d</span><br></blockquote></blockquote></blockquote></blockquote></blockquote= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>job of that</sp= an><br></blockquote></blockquote></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><s= pan>but at present the references are inconsistent in which elements are</sp= an><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span>specified in what orde= r and that is something the RFC Editor probably</span><br></blockquote></blo= ckquote></blockquote><blockquote type=3D"cite"><span>cannot cope with.</span= ><br></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa= n>Authentication Method is a registry so that just needs Group name</span><b= r></blockquote></blockquote></blockquote></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span>and</span><br></blockquot= e></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Registry name a= fter IANA.</span><br></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><span></span><br></blockquote></blockquote></blockquote></blockq= uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>Ok, good.</span><br></blockquote></bl= ockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span></span><br></blockquote></blockquote></blockquote></block= quote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><sp= an>Some minor glitches.</span><br></blockquote></blockquote></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><span>I-D appears twice in the body of the I-D - perhaps document or memo.<= /span><br></blockquote></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></bloc= kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span>Ok.</span><br></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa= n></span><br></blockquote></blockquote></blockquote></blockquote><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><span>objetives/objectives/</span= ><br></blockquote></blockquote></blockquote></blockquote></blockquote><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><span></span><br></blockquote></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><span>Fixed.</span><br></blockquo= te></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><span>end port number perhaps /must/MUST/</span><br></bl= ockquote></blockquote></blockquote></blockquote></blockquote><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span></span><br></blockquote></blockquote></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>and YANG is= very good at including such checks with a must ....</span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>'If AEAD is used .. where? this occurs i= n several places and I</span><br></blockquote></blockquote></blockquote></bl= ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span>think that you</span><br></blockquote></blockquote></blockquote></bloc= kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><span>need to specify the leaf where AEAD will be spec= ified or implied.</span><br></blockquote></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><span></span><br></blockquote></blockquote></blockquote><= /blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>Ok we have changed it to:</span= ><br></blockquote></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><span>If Authenticated Encryption with Associate= d Data (AEAD) is used</span><br></blockquote></blockquote></blockquote></blo= ckquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type= =3D"cite"><blockquote type=3D"cite"><span>(leaf</span><br></blockquote></blo= ckquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>esp-algo= rithms/encryption/algorithm-type)</span><br></blockquote></blockquote></bloc= kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span>this flag MUST be fals= e."</span><br></blockquote></blockquote></blockquote></blockquote><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><span></span><br></blockquote></blockquote></blockquote></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>And i= s it possible to make that a YANG 'must' statement - looking</span><br></blo= ckquote></blockquote></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><span>at the</span><br></blockquote></= blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><span>IKEv2 registries i= t is not obvious which are AEAD so that might be</span><br></blockquote></bl= ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><span>more complexity than it is worth.</span><br></= blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>'only available on linux kernels' Um implementation det= ail, you may</span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>get</= span><br></blockquote></blockquote></blockquote></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span>asked to remove that altogether or at least to a Informative Appendix<= /span><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><span>- I would leave it i= n for now.</span><br></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><span></span><br></blockquote></blockquote></blockquote></blockq= uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>Ok.</span><br></blockquote></blockquo= te></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></= blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><span>'import ietf-i2nsf-ikec' the reference nee= ds to be to a RFC and if</span><br></blockquote></blockquote></blockquote></= blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><span>it is not yet an RFC then RFC XXXX <title> in both Appendix B a= nd C</span><br></blockquote></blockquote></blockquote></blockquote></blockqu= ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Yes, we have chan= ged that to:</span><br></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></bloc= kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span>RFC XXXX: Software-Def= ined Networking</span><br></blockquote></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>       &nb= sp;         (SDN)-based IPsec Fl= ow Protection.</span><br></blockquote></blockquote></blockquote></blockquote= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></bl= ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span>leaf-list pfs-groups could do with a reference - Transform Type 4?</sp= an><br></blockquote></blockquote></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><span></span><br></blockquote></blockquote></blockqu= ote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span>The leaf list is referrin= g to type pfs-group and we have now</span><br></blockquote></blockquote></bl= ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockqu= ote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= >typedef pfs-group {</span><br></blockquote></blockquote></blockquote></bloc= kquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>       =        type uint16;</span><br></blockquot= e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span> &= nbsp;            = ;description</span><br></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><span>        =           "DH groups for I= KE and IPsec SA rekey.";</span><br></blockquote></blockquote></blockquote></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>      =         reference</span><br></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa= n>             &= nbsp;    "IANA; Internet Key Exchange V2 (IKEv2) Paramet= ers;</span><br></blockquote></blockquote></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><span>               &= nbsp;Transform Atribute Types; Transform Type 4 -</span><br></blockquote></b= lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>  = ;            &nb= sp;   Diffie-Hellman Group Transform IDs.</span><br></blockqu= ote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= >                Section 3.3.2 in RFC= 7296.";</span><br></blockquote></blockquote></blockquote></blockquote><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><span>        &nbs= p; }</span><br></blockquote></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><span></span><br></blockquote></blockquote></blockqu= ote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span></span><br></blockquote></blockquote></blockquote></blo= ckquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= span>I am still working my way through the YANG so may have some more</span>= <br></blockquote></blockquote></blockquote></blockquote></blockquote><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= >comments tomorrow.</span><br></blockquote></blockquote></blockquote><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><span></span><br></blockquote></blockquote></blockquote= ></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquot= e type=3D"cite"><blockquote type=3D"cite"><span>Ok, do not worry we will wor= k in -12 with these comments so far to</span><br></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span>have a</span><br>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><span>quick response. W= e can prepare a another version later with the rest of</span><br></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><span>them.</span><br>= </blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blo= ckquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Thank yo= u very much for your effort.</span><br></blockquote></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span><= /span><br></blockquote></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Tom Petch</span><= br></blockquote></blockquote></blockquote></blockquote></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></b= lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span></span><br></blockquote></blockquote></blockquote></block= quote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><sp= an></span><br></blockquote></blockquote></blockquote></blockquote></blockquo= te><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></= blockquote></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blo= ckquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><span></span><br></blockquote></blockquote></blockq= uote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></s= pan><br></blockquote></blockquote></blockquote></blockquote></blockquote><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockq= uote></blockquote></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote>= </blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><span></span><br></blockquote></blockquote></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><span></span><br></blockquote></blockquote></blockquote></blockquote></bloc= kquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>W= e have realized that we missed to change this, even though we</span><br></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><span>discussed</span><br></blockquote></blockquote></blockquote></blockqu= ote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><span>it. We will change it right away in th= e following way (bold):</span><br></blockquote></blockquote></blockquote><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><span></span><br></blockquote></blockquote></blockquote></blockquote></bloc= kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><span>case rfc822-address-string {</span><br></block= quote></blockquote></blockquote></blockquote></blockquote></blockquote><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= span>       leaf rfc822-address-string {</span= ><br></blockquote></blockquote></blockquote></blockquote></blockquote></bloc= kquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>           &n= bsp;type string;</span><br></blockquote></blockquote></blockquote></blockquo= te></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>       =      description</span><br></blockquote></blockquot= e></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>   = ;            &nb= sp;"Specifies the identity as a</span><br></blockquote></blockquote></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span>    &nb= sp;            f= ully-qualified RFC5322 email</span><br></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span>     =             addr= ess string. An example is,</span><br></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><span>     &n= bsp;           jsmith= @example.com. The string</span><br></blockquote></blockquote></blockquote></= blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span>     &nbs= p;           MUST NOT= contain any</span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span>       &nbs= p;         terminators e.g., NU= LL, CR,</span><br></blockquote></blockquote></blockquote></blockquote></bloc= kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><span>        &nb= sp;        etc.).";</span><br></bloc= kquote></blockquote></blockquote></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span>            &nb= sp;reference</span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span>       &nbs= p;            "R= FC 5322.";</span><br></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><span>       }</spa= n><br></blockquote></blockquote></blockquote></blockquote></blockquote></blo= ckquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><span>}</span><br></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Btw, we alread= y used in the past =E2=80=9Ccase rfc822-address-string=E2=80=9D and</span><b= r></blockquote></blockquote></blockquote></blockquote></blockquote></blockqu= ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>=E2=80=9Cleaf</span><br></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span>rfc822-address-string=E2=80=9D= since this is coming from IKEv2 standard. Do</span><br></blockquote></block= quote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><span>you think we should change that name as well?</sp= an><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockqu= ote></blockquote></blockquote></blockquote></blockquote></blockquote><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><sp= an></span><br></blockquote></blockquote></blockquote></blockquote></blockquo= te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><span>YANG module references IANA Protocol N= umbers which is not in the</span><br></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><span>I-D references</span><br></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></b= lockquote></blockquote></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><span>We have included the following reference:</span><br></blockquote></= blockquote></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></s= pan><br></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span>[IANA-Protocols-Number]</span><br></blockquote></blockquo= te></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>  &nbs= p;            &n= bsp;Internet Assigned Numbers Authority (IANA), "Protocol</span><br></blockq= uote></blockquote></blockquote></blockquote></blockquote></blockquote><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><s= pan>             = ;   Numbers", January 2020.</span><br></blockquote></blockquo= te></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span>s.2 boiler plate is out of da= te</span><br></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote><= /blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>What we see is t= he I-D has the second choice stated in</span><br></blockquote></blockquote><= /blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>https://www.iet= f.org/standards/ids/guidelines/</span><br></blockquote></blockquote></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquot= e></blockquote></blockquote></blockquote></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= >This Internet-Draft is submitted in full conformance with the</span><br></b= lockquote></blockquote></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><span>     provisions of BCP 78 and BCP 79.</span><br= ></blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>     Internet-Drafts= are working documents of the Internet Engineering</span><br></blockquote></= blockquote></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span> &n= bsp;   Task Force (IETF).  Note that other groups may al= so distribute</span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>     working documen= ts as Internet-Drafts.  The list of current Internet-</span><br></block= quote></blockquote></blockquote></blockquote></blockquote></blockquote><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= span>     Drafts is at https://datatracker.ietf.org/draf= ts/current/.</span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><span>    = ; Internet-Drafts are draft documents valid for a maximum of six</span>= <br></blockquote></blockquote></blockquote></blockquote></blockquote></block= quote><blockquote type=3D"cite"><span>months</span><br></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa= n>     and may be updated, replaced, or obsoleted by oth= er documents at</span><br></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><span>any</span><br></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>     time.  It is inappropriat= e to use Internet-Drafts as reference</span><br></blockquote></blockquote></= blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><span>   &nb= sp; material or to cite them other than as "work in progress."</span><b= r></blockquote></blockquote></blockquote></blockquote></blockquote></blockqu= ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>Could you refer what is out of date?</sp= an><br></blockquote></blockquote></blockquote></blockquote></blockquote></bl= ockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span></span><br></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span>XXXX is standing in for m= ore than one RFC</span><br></blockquote></blockquote></blockquote></blockquo= te></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Y= es, XXXX has been used because we do not know the future number</span><br></= blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><span>assigned to our I-D.</span><br></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span>Also we realized we also included this to= refer to crypto-types</span><br></blockquote></blockquote></blockquote></bl= ockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>I-D but this</span><br></blockq= uote></blockquote></blockquote></blockquote></blockquote></blockquote><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa= n>has been solved now in a new version -12 that we are preparing to</span><b= r></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><span>include your comments. We n= oticed we can replace the type of rw</span><br></blockquote></blockquote></b= lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><span>cert-data?, ca-data*, crl- data? for binary without any pr= oblem.</span><br></blockquote></blockquote></blockquote><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><span>|           | &= nbsp;   +--rw cert-data?       =  binary</span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span>|       &nb= sp;   +--rw private-key?       =      binary</span><br></blockquote></blockquote></b= lockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span>|   &nb= sp;       +--rw ca-data*   &nbs= p;            bi= nary</span><br></blockquote></blockquote></blockquote></blockquote></blockqu= ote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><span>|         = ;  +--rw crl-data?         = ;      binary</span><br></blockquote></blockqu= ote></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote><= /blockquote></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><span>but the show stopper that makes a proper review of th= is too</span><br></blockquote></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>costly is t= he</span><br></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>references.  Those to IANA of which= there are several I want to</span><br></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><span>pursue.  The I-D reference is to IKEv2 parameters. Sadly, thi= s is a</span><br></blockquote></blockquote></blockquote><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>three tier s= tructure and noone agrees on what to call the third tier</span><br></blockqu= ote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><span>so I will call it tier3 here.  To= p level is Group, as per RFC8126,</span><br></blockquote></blockquote></bloc= kquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>second level is Registry.  The I-D reference is to the Gro= up only</span><br></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>which is fi= ne if the actual reference then specifies the Registry and</span><br></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>Tier3 but they never do, usually just= Tier3 e.g. Transform Type 3</span><br></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><span>which makes for a lot of work for the reader, too much for this on= e.</span><br></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><span>You have to go h= unting in all the second level Registry until you can</span><br></blockquote= ></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span>find a match for the Tier3 identifier. An= d there are no URL.  If you</span><br></blockquote></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>want an example that I find easy to use, go look at RFC8407 (as= usual).</span><br></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><span>You=E2=80=99re right. Could you point the exact part at RFC 8407= with that</span><br></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><span>example? We would really appreciate it.</span= ><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquot= e></blockquote></blockquote></blockquote></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= >On the other hand, would it be enough to include the URL for</span><br></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><span>Transform</span><br></blockquote></blockquote></blockquote></blockqu= ote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><span>Type 3 https://www.iana.org/assignment= s/ikev2-parameters/ikev2-</span><br></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><span>parameters.xhtml#ikev2-parameters-7 ?</span><br></blockquote></blockq= uote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><span></span><br></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span>(Same for Transform Type 1= , Transform Type 4)</span><br></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>The= reference for import of i2nsf-ikec gives a YANG module name;</span><br></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span>this needs to be the name of t= he RFC to be</span><br></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Fixed.= </span><br></blockquote></blockquote></blockquote></blockquote></blockquote>= </blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><span></span><br></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>import ietf-i2nsf-ikec {</span>= <br></blockquote></blockquote></blockquote></blockquote></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>           &n= bsp;  prefix nsfikec;</span><br></blockquote></blockquote></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span>    &nb= sp;         reference</span><br= ></blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>           &n= bsp;      "RFC XXXX: Software-Defined Networki= ng</span><br></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><span>         &n= bsp;       (SDN)-based IPsec Flow Protect= ion."; }</span><br></blockquote></blockquote></blockquote></blockquote></blo= ckquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><span></span><br></blockquote></blockquote></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><span>We still use XXXX beca= use we do not know the number assigned to</span><br></blockquote></blockquot= e></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>the RFC</spa= n><br></blockquote></blockquote></blockquote></blockquote></blockquote></blo= ckquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type= =3D"cite"><span>to be.</span><br></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span></span><br></blockquote></blockquote></blockquote></blockquote></block= quote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquo= te></blockquote></blockquote></blockquote></blockquote></blockquote></blockq= uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>The example IPv6 address in the YANG m= odule has :0:0: which is</span><br></blockquote></blockquote></blockquote></= blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><span>usually</span><br></blockquote></blockquote></blockquote></blockqu= ote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span>just ::</span><br></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Fixed.</span><= br></blockquote></blockquote></blockquote></blockquote></blockquote></blockq= uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>If you have any further comments, please= let us know so we can</span><br></blockquote></blockquote></blockquote></bl= ockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>include them in -12</span><br><= /blockquote></blockquote></blockquote></blockquote></blockquote></blockquote= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><span></span><br></blockquote></blockquote></blockquote></blockquote></= blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><span>Best Regards.</span><br></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span></span><br></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= span>And I have some way to go still.</span><br></blockquote></blockquote></= blockquote></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><span></span><br></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><span>Tom Petch</span><br></blockquote></blockquote></blockquote></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><s= pan></span><br></blockquote></blockquote></blockquote></blockquote></blockqu= ote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>On 22/10/20= 20 18:39, Rafa Marin-Lopez wrote:</span><br></blockquote></blockquote></bloc= kquote></blockquote></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>Dear all:</span><br></blockquote></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></s= pan><br></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>After receiving a suggestion to make things clearer in t= he</span><br></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><span>feature ikeless-</span><br></blockquote></blockqu= ote></blockquote></blockquote></blockquote></blockquote></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>notification description, we have just uploaded a new version -= 11</span><br></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><span>with a minor cha= nge to add the following text:</span><br></blockquote></blockquote></blockqu= ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>feature ikeless-notification {</span><br></blockquote></blockqu= ote></blockquote></blockquote></blockquote></blockquote></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>  &nbs= p;           descript= ion</span><br></blockquote></blockquote></blockquote></blockquote></blockquo= te></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><span>         = ;         "This feature indicat= es that the server supports</span><br></blockquote></blockquote></blockquote= ></blockquote></blockquote></blockquote></blockquote></blockquote><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><span>     = ;            &nb= sp;generating notifications in the ikeless module.</span><br></blockquote></= blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>= </blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span><= /span><br></blockquote></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><span>         &nbs= p;        To ensure broader applicab= ility of this module,</span><br></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>      =             the n= otifications are marked as a feature.</span><br></blockquote></blockquote></= blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>   &= nbsp;            = ;  For the implementation of ikeless case,</span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= >             &n= bsp;    the NSF is expected to implement this</span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>           &n= bsp;      feature.";</span><br></blockquote></= blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>= </blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span> &= nbsp;        }</span><br></blockquot= e></blockquote></blockquote></blockquote></blockquote></blockquote></blockqu= ote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><sp= an></span><br></blockquote></blockquote></blockquote></blockquote></blockquo= te></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><span>Best Regards.</span><br></blockquote></blockquot= e></blockquote></blockquote></blockquote></blockquote></blockquote></blockqu= ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>Inicio del mensaje reenviado:</span><= br></blockquote></blockquote></blockquote></blockquote></blockquote></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockqu= ote></blockquote></blockquote></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>De: internet-drafts@ietf.org</span><b= r></blockquote></blockquote></blockquote></blockquote></blockquote></blockqu= ote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><span>Asunto: New Version N= otification for</span><br></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><sp= an>draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt</span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>Fecha: 22 de octubre de 2020, 15:32:5= 0 CEST</span><br></blockquote></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Para: "Fern= ando Pereniguez-Garcia"</span><br></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><span><fernando.pereniguez@cud.upct.es>, "Rafael Lopez" <rafa@= um.es>,</span><br></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote></blockquote></blockquote><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>"Ga= briel Lopez-Millan" <gabilm@um.es>, "Rafa Marin-Lopez"</span><br></blo= ckquote></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span><rafa@um.es></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote= ></blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><span>A new version of I-D,</span><br></blockquote></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote></= blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on-11.txt</span><br></blockquote></blockquote></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote></blockquote><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>has= been successfully submitted by Rafa Marin-Lopez and posted</span><br></bloc= kquote></blockquote></blockquote></blockquote></blockquote></blockquote></bl= ockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span>to the IETF repository.</span= ><br></blockquote></blockquote></blockquote></blockquote></blockquote></bloc= kquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></block= quote></blockquote></blockquote></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>Name:       &nbs= p;draft-ietf-i2nsf-sdn-ipsec-flow-protection</span><br></blockquote></blockq= uote></blockquote></blockquote></blockquote></blockquote></blockquote></bloc= kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><span>Revision:    11</span><br></blockq= uote></blockquote></blockquote></blockquote></blockquote></blockquote></bloc= kquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>Title:        Sof= tware-Defined Networking (SDN)-based IPsec Flow</span><br></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><span>Protection</span><br></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><span>Document date:    2020-10-22</span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><span>Group:     &n= bsp;  i2nsf</span><br></blockquote></blockquote></blockquote></blockquo= te></blockquote></blockquote></blockquote></blockquote></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><s= pan>Pages:        92</span><br></blockquote></blockquote= ></blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><span>URL:        &= nbsp;   https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-= </span><br></blockquote></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite= "><span>ipsec-</span><br></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>flow-protection-11.txt</span><b= r></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><span>Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-ietf= -i2nsf-sdn-</span><br></blockquote></blockquote></blockquote></blockquote></= blockquote></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><span>ipsec-</span><br></blockquote><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><span>flow-protection/</s= pan><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Htmlized:  &= nbsp;    https://datatracker.ietf.org/doc/html/draft-iet= f-i2nsf-</span><br></blockquote></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><span>sdn-</span><br></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><span>ipsec-flow-protection</s= pan><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Htmlized:  &= nbsp;    https://tools.ietf.org/html/draft-ietf-i2nsf-sd= n-ipsec-</span><br></blockquote></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><span>flow-</span><br></blockquote><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><span>protection-11</span><br= ></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><span>Diff:    =        https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-i2nsf-sdn-</span><br></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote></blockquote><bl= ockquote type=3D"cite"><span>ipsec-</span><br></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>flow-protec= tion-11</span><br></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><span>Abstract:</span><br></b= lockquote></blockquote></blockquote></blockquote></blockquote></blockquote><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><span>    This doc= ument describes how to provide IPsec-based flow</span><br></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><span>protection</span><br>= </blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><span>    (integrity and confidentiality) b= y means of an Interface to Network</span><br></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>    Security Function (I2NSF) controller= .  It considers two main well-</span><br></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote></= blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><span>    known scenarios in IPsec: (i) gate= way-to-gateway and (ii) host-to-</span><br></blockquote></blockquote></block= quote></blockquote></blockquote></blockquote></blockquote></blockquote></blo= ckquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span>    host.  The service described in t= his document allows the</span><br></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote></blockquote></blockquote></blockquote><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><span>    configuration and monitoring of IPsec Security= Associations (SAs)</span><br></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote></blockquote></blockquote></blockquote><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><span>    from a I2NSF Controller to one or several flow-bas= ed</span><br></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Network</sp= an><br></blockquote></blockquote></blockquote></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><span>Security</span><br><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><span>    Function= s (NSFs) that rely on IPsec to protect data traffic.</span><br></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><span>    The document focuses on the I2= NSF NSF-facing interface by</span><br></blockquote></blockquote></blockquote= ></blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te><blockquote type=3D"cite"><span>providing</span><br></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><s= pan>    YANG data models for configuring the IPsec databases (= SPD,</span><br></blockquote></blockquote></blockquote></blockquote></blockqu= ote></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>SAD,</span>= <br></blockquote></blockquote></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><span>PAD)</span><br></blockq= uote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span>    and IKEv2.  T= his allows IPsec SA establishment with minimal</span><br></blockquote></bloc= kquote></blockquote></blockquote></blockquote></blockquote></blockquote></bl= ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><span>    intervention by the net= work administrator.  It does not define any</span><br></blockquote></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote></= blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span>    new protocol.</span><= br></blockquote></blockquote></blockquote></blockquote></blockquote></blockq= uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockqu= ote></blockquote></blockquote></blockquote></blockquote></blockquote></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><span></span><br></blockquote></blockquote></blockquote= ></blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= >Please note that it may take a couple of minutes from the time</span><br></= blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><span>of submission until the h= tmlized version and diff are available</span><br></blockquote></blockquote><= /blockquote></blockquote></blockquote></blockquote></blockquote></blockquote= ></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><span>at</span><br></blockquote></blockquote></blockquot= e></blockquote></blockquote></blockquote></blockquote></blockquote></blockqu= ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><span>tools.ietf.org.</span><br></blockquote></blockquote></blockquote= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span= >The IETF Secretariat</span><br></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote></blockquote><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><span></span><br></blockquote></blockquote></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote></blockquote><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></s= pan><br></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><span>----------------= ---------------------------------------</span><br></blockquote></blockquote>= </blockquote></blockquote></blockquote></blockquote></blockquote></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Rafa Marin-L= opez, PhD</span><br></blockquote></blockquote></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><span>Dept. Information and Communications Engin= eering (DIIC) Faculty</span><br></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote><blockquote type= =3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><span>of Computer Science-University o= f Murcia</span><br></blockquote></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><span>30100 Murcia - Spain</span><br></blockquote= ></blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa= n>Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es</span><br></blockq= uote></blockquote></blockquote></blockquote></blockquote></blockquote></bloc= kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span>-------------------------------------------------------</span><br></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote></= blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><span></span><br></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blo= ckquote></blockquote></blockquote></blockquote></blockquote></blockquote></b= lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><span></span><br></blockquote></blockquote></blockquote></blockquote></bl= ockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote></blockquote></blockquote><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></bloc= kquote></blockquote></blockquote></blockquote></blockquote></blockquote></bl= ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><span></span><br></blockquote></blockquote></blockquote></blockquote></blo= ckquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockq= uote></blockquote></blockquote></blockquote></blockquote></blockquote><block= quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><s= pan>-------------------------------------------------------</span><br></bloc= kquote></blockquote></blockquote></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span>Rafa Marin-Lopez, PhD</span><br></blockquote></blockquote></blockquote= ></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><span>Dept. Information and Comm= unications Engineering (DIIC) Faculty of</span><br></blockquote></blockquote= ></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cit= e"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Computer Scie= nce-University of Murcia</span><br></blockquote></blockquote></blockquote></= blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><blockquote type=3D"cite"><span>30100 Murcia - Spain</span><b= r></blockquote></blockquote></blockquote></blockquote></blockquote></blockqu= ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"= cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es</span><= br></blockquote></blockquote></blockquote></blockquote></blockquote></blockq= uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>-------------------------------------------------------</span><= br></blockquote></blockquote></blockquote></blockquote></blockquote></blockq= uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D= "cite"><span></span><br></blockquote></blockquote></blockquote></blockquote>= </blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite= "><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></b= lockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><= blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></bloc= kquote></blockquote></blockquote></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span></span><br></blockquote></blockquote></blockquote></blockquote></block= quote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><span></span><br></blockquote></blockquote></blockquo= te></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>= </span><br></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>-------------------------------------------------------= </span><br></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>Rafa Marin-Lopez, PhD</span><br></blockquote></blockquo= te></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Dept. Informa= tion and Communications Engineering (DIIC) Faculty of</span><br></blockquote= ></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquot= e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Co= mputer Science-University of Murcia</span><br></blockquote></blockquote></bl= ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><b= lockquote type=3D"cite"><blockquote type=3D"cite"><span>30100 Murcia - Spain= </span><br></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es= </span><br></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span>-------------------------------------------------------= </span><br></blockquote></blockquote></blockquote></blockquote><blockquote t= ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote= type=3D"cite"><span></span><br></blockquote></blockquote></blockquote></blo= ckquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type= =3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquo= te></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"c= ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></= blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite">= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite= "><span></span><br></blockquote></blockquote></blockquote></blockquote><bloc= kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bl= ockquote type=3D"cite"><span></span><br></blockquote></blockquote></blockquo= te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu= ote type=3D"cite"><span></span><br></blockquote></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">= <span>--</span><br></blockquote></blockquote></blockquote><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>last-call m= ailing list</span><br></blockquote></blockquote></blockquote><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>last-ca= ll@ietf.org</span><br></blockquote></blockquote></blockquote><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>https:/= /www.ietf.org/mailman/listinfo/last-call</span><br></blockquote></blockquote= ></blockquote><span>-- </span><br><span>last-call mailing list</span><br><sp= an>last-call@ietf.org</span><br><span>https://www.ietf.org/mailman/listinfo/= last-call</span><br></div></blockquote></body></html>= --Apple-Mail-7EB7996D-C18E-42C9-A524-D754CDACE491-- From nobody Fri Oct 30 15:42:22 2020 Return-Path: <kivinen@iki.fi> 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 755D33A12A4; Fri, 30 Oct 2020 15:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 3s6gASlk6a_9; Fri, 30 Oct 2020 15:42:19 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 79B323A03F2; Fri, 30 Oct 2020 15:42:16 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 477C820ACC; Sat, 31 Oct 2020 00:42:14 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1604097734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JdObjbwBpmusZoxDTDpANds47ddtMWZ6EGdRk7tNJBU=; b=Qthps85cGvEBtLXbiXtbawX4jdWoJOgIu2afkudLq59U7HBr+GCfBUNtyw+BE8gWNt/oUm X7Xasi9w7kXO4aixrUYYHL7RTcHsug3GR9Jik3sfMk7u6WeLNMmemvqYxeDRn2rNuRS7JX 1skWp3yIc+KgI9MyjZyr0qSa8ifzs+k= Received: by fireball.acr.fi (Postfix, from userid 15204) id 1CBEF25C132D; Sat, 31 Oct 2020 00:42:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24476.38596.868667.906930@fireball.acr.fi> Date: Sat, 31 Oct 2020 00:42:12 +0200 From: Tero Kivinen <kivinen@iki.fi> To: Roman Danyliw <rdd@cert.org> Cc: tom petch <daedulus@btconnect.com>, "ipsec\@ietf.org" <ipsec@ietf.org>, "i2nsf\@ietf.org" <i2nsf@ietf.org>, Gabriel Lopez <gabilm@um.es>, "ynir.ietf\@gmail.com" <ynir.ietf@gmail.com>, Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, "last-call\@ietf.org" <last-call@ietf.org>, Rafa Marin-Lopez <rafa@um.es> In-Reply-To: <834a668ac559460a9f356bbb6c16b8fd@cert.org> References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <EE5AB669-73BB-4517-A6F4-23B7807FB36E@um.es> <5F9815D1.9010303@btconnect.com> <DDE550B1-9A9E-4954-B6F9-C0A33ECE1275@um.es> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 39 min X-Total-Time: 39 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1604097734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JdObjbwBpmusZoxDTDpANds47ddtMWZ6EGdRk7tNJBU=; b=cCiWRoA4wkfk29YI9mqXeRtZbM79247ul1IHHL1n31pmrYldwRyXQY9Gd5Z1QVf7t7L8RA Ut2BoVoXsIJUcXPqbWdDyv+3VY6JpxfPxEwyfIsxFHsJUtE38zWhv6GeQYRKK/OTJ8atmT jI70MBBOeAdMeKWoUPqwGxyJ6DaW/XE= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1604097734; a=rsa-sha256; cv=none; b=NghmXMGVEQx7tqG2ifbLiAJ0Xp1YHyatHOkbvjhffU04VzgaoDTIQGdPHZ3S0kSLNNVDSG agbYObjYa0tFt62UBoJdmuIJfIRNKMEE2Cdvm7PHZdTTTTVzkk1bbT+Y8W9WpPMPRhQqWr y+H3a1XCUwmqQ/91HwhthkaP0k4yOCA= Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/GJAlP2frgOCE4-DJ4LdVfELJqh0> Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt 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, 30 Oct 2020 22:42:22 -0000 Roman Danyliw writes: > > >> It seems to me that the IANA entries for IKEv2 are incomplete. > > >> RFC8247 does a fine job of specifying algorithms and adding > > >> information such as status (MUST/SHOULD+), IoT, AEAD and so on, > > >> information which is not present on IANA. The policy for, e.g. > > >> Transform Type 1, is expert review and entries have been added via > > >> draft-smyslov-esp-gont but the IANA entries lack this information > > >> and, looking at the I-D, I see no such information (nor is there any > > >> reason for it to be there). Yet draft-ietf-i2nsf-sdn... needs > > >> this information as references in the YANG module show. I am lost what information is missing from the IANA registry. The registry do include numbers from draft-smyslov-esp-gost document. The RFC8247 says: ---------------------------------------------------------------------- 1.3. Updating Algorithm Requirement Levels ... .... As a result, any algorithm listed at the IKEv2 IANA registry not mentioned in this document MAY be implemented. ---------------------------------------------------------------------- I.e., all algorithms not listed there are MAY to implement. But I do not see any reason why the yang module should provide any other than pointer to the IANA registry, and the IANA registry already has pointer to the RFC8247 to indicate the requirement levels for algorithms. > > >> It seems to me that this is a similar situation to that which the TLS > > >> WG found itself in and which led to a revision of the TLS IANA > > >> entries to provide what was needed via additional columns. There was some requests to modify the IANA registry while we were publishing RFC 8247 and the WG decided against it, and instead decided to provide pointer to the RFC 8211 and RFC 8247 in the notes section. The reason for that is that duplicating information always causes problems, and because there is no (public) history of the IANA registries, there is no way of finding out when and why specific change to the registry was done unless there happens to be RFC that actually did that change. I myself as an IANA expert of those registries do think it is better that working group will do RFC that will update the levels, and that will leave audit trail and public working group mailing list discussion about the changes. > > >> I think that the IANA pages for IKEv2 need revising so that that > > >> additional information that RFC8247 provides is required as > > >> additional columns in the IANA entries at least for Type 1, Type 2, > > >> Type 3, Type 4 and Authentication Method. I fail to see why does that information need to be in the IANA registry? This is YANG model for IPsec, it should just refer to the IANA registry about the mapping from algorithms to numbers and other way around, but whether the algorithm is recommended or not, does not belong to the YANG model, as that is not something that can be modified by configuration or be part of running state. This document seems to have wierd text in it: typedef encryption-algorithm-type { type uint16; description "The encryption algorithm is specified with a 16-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; I do not see what the last sentence of the text is trying to say? Does it mean that this yang model cannot be shown of running configuration where someone is using one the algorithms not considered safe anymore? In ietf we usually just try to say what implementors are implementing, we do not that often limit what adminstrators can configure. If the implementation happens to implement one of those weak ciphers for example for talking to one obsoleted old hardware that only supports them, then I do not see why this yang model should forbid showing running status of such configuration. I think this document should just say that the algorithm numbers are from the IANA registry, and nothing more. There might be informal reference to the RFC 8221, and RFC 8247 but even that should not be needed, as anybody implementing IKEv2 or ESP will already follow those and only implement the algorithms from there that they seem proper. In some cases that selection might include algorithms which are on SHOULD NOT or even MUST NOT, if the backward compatibility to obsolete hardware is more important than conformance. > > This I-D, as you quote, points to RFC8247 for guidance and that is > > fine. But security moves on and new algorithms will be needed and > > this I-D also points to the IANA registry, which is Expert Review, > > where new entries have been added already; and for those the IANA > > Registry gives no guidance and the I-D that IANA references for > > the new entries - written by the Expert Reviewer! - also gives no > > guidance. Over time we are likely to accrue algorithms with no > > guidance unless and until an RFC8247-bis appears or we require > > IANA to have columns for guidance. Currently the new algorithms > > are GOST and so perhaps of limited interest but on the TLS list I > > am always seeing new algorithms appear and there the new IANA > > entry is required to give guidance. My sense is that IKEv2 is a > > bit slower to take up new ones but, as with RFC8247, it does > > eventually. The original cryptographic algorithm impelemtation requirements for ESP and AH was published as RFC4305 in 2007. It was replaced with RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2 we skipped the 2014 update, as that was not needed. We do have plans to keep that draft up to date, and update it when there is need for that, most likely in next 5 years or so, provided that implementation status of some of new algorithms progresses favorably. > > I think that users need those extra columns that RFC8247 provides > > on the IANA website so that when new algorithms are added by > > Expert Review, then that guidance must be added as well. This is > > what the TLS WG came round to and I think that IKEv2 needs to do > > the same. I as an Expert does not want to decide whether the individual request to add new 3rot13 cipher to the IANA registry should be MUST NOT, SHOULD NOT, MAY or what. If the field is in the IANA registry then whoever requests to add information to there can request whatever value they want for that field too. Of course as an IANA expert I can reject that by saying that 3rot13 is not MUST, but it is MUST NOT algorithm, and then we can have discussion about that. I rather have that discussion in the working group when we are updating the requirements document next time. And as I said IANA registries do not have any (public) history, or any way of finding out why they got changed and who did the change. There has happened some changes in the registry where I as an IANA Expert was not aware of at all... And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or when some of those earlier algorithms was renamed, I need to go to my private mail archives. -- kivinen@iki.fi From nobody Fri Oct 30 18:12:47 2020 Return-Path: <rdd@cert.org> 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 D77773A14A3; Fri, 30 Oct 2020 18:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=cert.org 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 x0yzAyzJfa_U; Fri, 30 Oct 2020 18:12:44 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 3487F3A14A1; Fri, 30 Oct 2020 18:12:43 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09V1CYfR003916; Fri, 30 Oct 2020 21:12:34 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 09V1CYfR003916 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1604106755; bh=RFkuzr3HWVoGN8xSoMUI8oY29LQEwrQaNrkKm+N7uxA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Q2AxARZ+zbJ6UJyrQrQxVLlh6TILgsK/SS4lwAkbYNDjtPOyzguv/HLuVB+EuAJo3 QTiecJppMnuMyfrEuII2RASuxRc5PdQTO9OqZfp7+y2p1P0Ma7lT7X14SyQE2oc0ms GSXbQFcEKdOB7oneVB4zSYihGPtnesGajSV2ZVjs= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09V1CUmr018108; Fri, 30 Oct 2020 21:12:31 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 30 Oct 2020 21:12:30 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Fri, 30 Oct 2020 21:12:30 -0400 From: Roman Danyliw <rdd@cert.org> To: Tero Kivinen <kivinen@iki.fi> CC: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, "i2nsf@ietf.org" <i2nsf@ietf.org>, Gabriel Lopez <gabilm@um.es>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>, "ipsec@ietf.org" <ipsec@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, Rafa Marin-Lopez <rafa@um.es>, tom petch <daedulus@btconnect.com> Thread-Topic: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt Thread-Index: AQHWreX0c88acJXFBk2yYgVjsJF2bKmvCuOA///cU0CAAVuUAP//zZ2AgADyqwD//+IF8A== Date: Sat, 31 Oct 2020 01:12:29 +0000 Message-ID: <4cd0a090e912445280b33d2842714cb1@cert.org> References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <EE5AB669-73BB-4517-A6F4-23B7807FB36E@um.es> <5F9815D1.9010303@btconnect.com> <DDE550B1-9A9E-4954-B6F9-C0A33ECE1275@um.es> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> In-Reply-To: <24476.38596.868667.906930@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/OYhNLhVF8nONoEwBAgCmtaE3sbQ> Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt 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: Sat, 31 Oct 2020 01:12:47 -0000 Hi Tero! > -----Original Message----- > From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Tero Kivinen > Sent: Friday, October 30, 2020 6:42 PM > To: Roman Danyliw <rdd@cert.org> > Cc: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>; > i2nsf@ietf.org; Gabriel Lopez <gabilm@um.es>; ynir.ietf@gmail.com; > ipsec@ietf.org; last-call@ietf.org; Rafa Marin-Lopez <rafa@um.es>; tom pe= tch > <daedulus@btconnect.com> > Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-= i2nsf-sdn- > ipsec-flow-protection-11.txt >=20 > Roman Danyliw writes: > > > >> It seems to me that the IANA entries for IKEv2 are incomplete. > > > >> RFC8247 does a fine job of specifying algorithms and adding > > > >> information such as status (MUST/SHOULD+), IoT, AEAD and so on, > > > >> information which is not present on IANA. The policy for, e.g. > > > >> Transform Type 1, is expert review and entries have been added > > > >> via draft-smyslov-esp-gont but the IANA entries lack this > > > >> information and, looking at the I-D, I see no such information > > > >> (nor is there any reason for it to be there). Yet > > > >> draft-ietf-i2nsf-sdn... needs this information as references in th= e YANG > module show. >=20 > I am lost what information is missing from the IANA registry.=20 Thanks for the analysis and feedback. I think the deep threading may have confused who said what. The above snip= and all of the snips below are from Tom's assessment of the IANA registry = situation (https://mailarchive.ietf.org/arch/msg/last-call/Cg66LRwtJjhJ5zNe= 8AEBWqKDll0/ and https://mailarchive.ietf.org/arch/msg/last-call/MMO9NsRif_= x1WkGbJFlgKiLOGYQ/)=20 My feedback in the earlier in the part of the thread (https://mailarchive.i= etf.org/arch/msg/last-call/vSU21Yqbczthq9Uii0N0roHQI7c/) was that RFC8247 i= s cited by draft-ietf-i2nsf-sdn-ipsec-flow-protection to describe implement= ation requirements (as represented in the YANG module) and that no IANA cha= nges should be needed. In a follow-on messages (https://mailarchive.ietf.org/arch/msg/last-call/7e= C7LH9_EWHxkA22YbST6Ghc4tc/) which added ipsec@ietf, I was noting that IPSec= me is the WG with expertise and scope that is best positioned to discuss m= anagement of the IKE registries Regards, Roman > The registry do > include numbers from draft-smyslov-esp-gost document. The > RFC8247 says: > ---------------------------------------------------------------------- > 1.3. Updating Algorithm Requirement Levels ... > .... As a result, any algorithm listed at the IKEv2 > IANA registry not mentioned in this document MAY be implemented. > ---------------------------------------------------------------------- > I.e., all algorithms not listed there are MAY to implement. >=20 > But I do not see any reason why the yang module should provide any other > than pointer to the IANA registry, and the IANA registry already has poin= ter to > the RFC8247 to indicate the requirement levels for algorithms. >=20 > > > >> It seems to me that this is a similar situation to that which the > > > >> TLS WG found itself in and which led to a revision of the TLS > > > >> IANA entries to provide what was needed via additional columns. >=20 > There was some requests to modify the IANA registry while we were publish= ing > RFC 8247 and the WG decided against it, and instead decided to provide > pointer to the RFC 8211 and RFC 8247 in the notes section. >=20 > The reason for that is that duplicating information always causes problem= s, and > because there is no (public) history of the IANA registries, there is no = way of > finding out when and why specific change to the registry was done unless = there > happens to be RFC that actually did that change. >=20 > I myself as an IANA expert of those registries do think it is better that= working > group will do RFC that will update the levels, and that will leave audit = trail and > public working group mailing list discussion about the changes. >=20 > > > >> I think that the IANA pages for IKEv2 need revising so that that > > > >> additional information that RFC8247 provides is required as > > > >> additional columns in the IANA entries at least for Type 1, Type > > > >> 2, Type 3, Type 4 and Authentication Method. >=20 > I fail to see why does that information need to be in the IANA registry? = This is > YANG model for IPsec, it should just refer to the IANA registry about the > mapping from algorithms to numbers and other way around, but whether the > algorithm is recommended or not, does not belong to the YANG model, as th= at > is not something that can be modified by configuration or be part of runn= ing > state. >=20 > This document seems to have wierd text in it: >=20 > typedef encryption-algorithm-type { > type uint16; > description > "The encryption algorithm is specified with a 16-bit > number extracted from IANA Registry. The acceptable > values MUST follow the requirement levels for > encryption algorithms for ESP and IKEv2."; >=20 > I do not see what the last sentence of the text is trying to say? Does it= mean > that this yang model cannot be shown of running configuration where someo= ne > is using one the algorithms not considered safe anymore? > In ietf we usually just try to say what implementors are implementing, we= do > not that often limit what adminstrators can configure. If the implementat= ion > happens to implement one of those weak ciphers for example for talking to= one > obsoleted old hardware that only supports them, then I do not see why thi= s > yang model should forbid showing running status of such configuration. >=20 > I think this document should just say that the algorithm numbers are from= the > IANA registry, and nothing more. There might be informal reference to the= RFC > 8221, and RFC 8247 but even that should not be needed, as anybody > implementing IKEv2 or ESP will already follow those and only implement th= e > algorithms from there that they seem proper. In some cases that selection > might include algorithms which are on SHOULD NOT or even MUST NOT, if the > backward compatibility to obsolete hardware is more important than > conformance. >=20 > > > This I-D, as you quote, points to RFC8247 for guidance and that is > > > fine. But security moves on and new algorithms will be needed and > > > this I-D also points to the IANA registry, which is Expert Review, > > > where new entries have been added already; and for those the IANA > > > Registry gives no guidance and the I-D that IANA references for the > > > new entries - written by the Expert Reviewer! - also gives no > > > guidance. Over time we are likely to accrue algorithms with no > > > guidance unless and until an RFC8247-bis appears or we require IANA > > > to have columns for guidance. Currently the new algorithms are GOST > > > and so perhaps of limited interest but on the TLS list I am always > > > seeing new algorithms appear and there the new IANA entry is > > > required to give guidance. My sense is that IKEv2 is a bit slower to > > > take up new ones but, as with RFC8247, it does eventually. >=20 > The original cryptographic algorithm impelemtation requirements for ESP a= nd > AH was published as RFC4305 in 2007. It was replaced with > RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2 we > skipped the 2014 update, as that was not needed. We do have plans to keep > that draft up to date, and update it when there is need for that, most li= kely in > next 5 years or so, provided that implementation status of some of new > algorithms progresses favorably. >=20 > > > I think that users need those extra columns that RFC8247 provides on > > > the IANA website so that when new algorithms are added by Expert > > > Review, then that guidance must be added as well. This is what the > > > TLS WG came round to and I think that IKEv2 needs to do the same. >=20 > I as an Expert does not want to decide whether the individual request to = add > new 3rot13 cipher to the IANA registry should be MUST NOT, SHOULD NOT, > MAY or what. If the field is in the IANA registry then whoever requests t= o add > information to there can request whatever value they want for that field = too. > Of course as an IANA expert I can reject that by saying that 3rot13 is no= t MUST, > but it is MUST NOT algorithm, and then we can have discussion about that. >=20 > I rather have that discussion in the working group when we are updating t= he > requirements document next time. And as I said IANA registries do not hav= e > any (public) history, or any way of finding out why they got changed and = who > did the change. There has happened some changes in the registry where I a= s an > IANA Expert was not aware of at all... >=20 > And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or > when some of those earlier algorithms was renamed, I need to go to my pri= vate > mail archives. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Oct 31 06:12:59 2020 Return-Path: <daedulus@btconnect.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 7B6A13A0AA6; Sat, 31 Oct 2020 06:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 O9g6sjLlbvfs; Sat, 31 Oct 2020 06:12:45 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2107.outbound.protection.outlook.com [40.107.21.107]) (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 ECD653A0AA3; Sat, 31 Oct 2020 06:12:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V+ly9Qqi0YH/bdl7DDFHQIM+xRmUeeQzKPF7MbLPksl/bKzNhcdv8i2G0X0+Y9gYcAg1f3wd3/dW/AFX87gjEUuORvQDHJDRHeqLXpTH4TgHLr7SKK7aMUlang3tmX6e5TeZt3KKf2DiesU1ELEy0N/85p3tAAvJdvXPTIVgcpz/WEYybkImolmdQrkVclCAy1I24MAsdhUpTqPgrWRRGHYF0T2oNzAQ8huaWxUnnjiQiuxPmZSpb1JjKX61SBtEDZh6nC6KTxPdwfef1ywwxmifXbP7s+htjTiw67AaWA46fV+PzSdV4Z3/q/NXy8pD011eGUmduREBEN+bhW4nwQ== 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=3v6o5bsWYpQxXTP2OwWAHMWOwOLh23jzOzjc4oRLERc=; b=Uv/8PGCQgfq/c23ccIvSkVzOExunnN8inMKNWxilEO6oYq+Q+D24QoYMlc8hbaWJtSZ7CgGZSiaS1Up99FwM+YO7cF6DZqc1p0ZwXTdO1NfHeDbC7xLv2pUb8NipvsSUPO0R4T2JTDXnLjPGtRtJg/XP6E8Zf+UxgF5RCoeRF1cBdXf+ABDB2uDAH1Ge5zHbikoWDbQu6YS2DEb75cHj5Y234QA0AWgHE3OkPy6y+1tDBmUytuIAl0zY+3jg5FwjhTK2wyjhqsHBMQK33Vdo/ria3ti/q54R/W9NSFckhe5/FPDKj9aAupmpj7vdjp2XhaiZOe/D6d/YZG6L3y9Y2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3v6o5bsWYpQxXTP2OwWAHMWOwOLh23jzOzjc4oRLERc=; b=YGvS0Ndoq1emXLj5S0u1lAPQjF0QxqU5B+Ne7U8uWlj8JGom+sDeZpBI9OBGAik45rhKbj4S9tN/0YyuXvpz3licWTVhJq/Q70WS/RExbTUCvCuSDfhNl9UIw/LemvuGNowbIk+pRK13jRqvc3HCarvnBaUoED3NryH+6hRj9wg= Authentication-Results: um.es; dkim=none (message not signed) header.d=none;um.es; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB4815.eurprd07.prod.outlook.com (2603:10a6:803:a9::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Sat, 31 Oct 2020 13:12:41 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3541.010; Sat, 31 Oct 2020 13:12:41 +0000 To: Tero Kivinen <kivinen@iki.fi>, Roman Danyliw <rdd@cert.org> References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <EE5AB669-73BB-4517-A6F4-23B7807FB36E@um.es> <5F9815D1.9010303@btconnect.com> <DDE550B1-9A9E-4954-B6F9-C0A33ECE1275@um.es> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, Gabriel Lopez <gabilm@um.es>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>, Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, "last-call@ietf.org" <last-call@ietf.org>, Rafa Marin-Lopez <rafa@um.es> From: tom petch <daedulus@btconnect.com> Message-ID: <5F9D62C0.5030908@btconnect.com> Date: Sat, 31 Oct 2020 13:12:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <24476.38596.868667.906930@fireball.acr.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO2P265CA0271.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::19) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0271.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3499.18 via Frontend Transport; Sat, 31 Oct 2020 13:12:40 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 196b41be-23f5-4562-b420-08d87d9ea5a1 X-MS-TrafficTypeDiagnostic: VI1PR07MB4815: X-Microsoft-Antispam-PRVS: <VI1PR07MB4815E30A850082730C04A78BC6120@VI1PR07MB4815.eurprd07.prod.outlook.com> X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: G2isJ1FlD5iAmuZlWAzkSHuIGtDsKcgPtjgBKrwVe358RMOOBo3sK8NS9bVKJt0gy5aKXIpJoZy1iH0Y3D0OY7WF2xOmV6zAHIuQkXQE6Es1olJ9kedXYEi9GqZJ0GlrLXkXuLibR7JZD9FO83+tFucGlcCm60vcLLzfDWTyFjX1XQNSv1q1HOnu/ZMwMatovU81JtwhQnxhsqrO7itE2gnS849JbwJmBfwnbn6X3IB3K41Vj+fJMC+cjrVhb05SysAbiIMXdZEls+LRtL2u0HfYM3Y9+qxEHQoCli8cdQ56dElQ/8C0zp6BeME62Rv6E6fIkaPbY8KVTk42fSnoFA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(396003)(136003)(346002)(376002)(5660300002)(8676002)(478600001)(54906003)(83380400001)(66476007)(66556008)(6666004)(66946007)(86362001)(87266011)(2906002)(110136005)(8936002)(16576012)(26005)(36756003)(33656002)(316002)(2616005)(956004)(186003)(4326008)(6486002)(16526019)(52116002)(53546011)(15650500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: IE4jIdDfz5JQ5pTy1PHD7POqRRjcEuuFJJxcEsaRvEc4N/r5Ns4M7+uHUTvN5v9+ThbtHXYFhezpuQ82edIolr5ViSYfikpQ0wwSlmmVg7eSTpSN1Ew4a02FmNgCFTSEZycQucwUN4tQguidV0yyJKz4VRpLVxu7IE2YXVnFFg/6LiL/KttUNRoVITEFlk+mdNPZxl+eqH47uqA2uh+JVS0C3XfKKqh4gGjwwhDj5Td/DWpZVv1H9lnmhVZxbFUjrQrTiw4TYBLqLaosYZBfwgW8q0n1riwpq4Gvr71kyn8byhCyIrllttCf/FjHQE5ZtiiK8KVcyuhGZ/5lzWmEdgzvF6RJGLqhuM9DbZ/nngNpSjN06N9v7U3r+5JAPEsccOFQOWBjx3OQwsiQ34YMaIZ8AZafwsPSr+oXMN/u+vNoJqk/JOnEJOnx9mbGoIQUOcezpHBaLDJC/L482N0aJ45hmGo3ZDaj5TzqvugKnekjfwXW4zN9/wFx2DHbrgxE0xhQHApfa3mG/GzxZK2IOLAuEyeicHaHyOOT3kRlzBaM+5arxENAo74lCsUUnDxyEQSfzCuyIZmbKr0nx+s+edLuubdkr5Zej8CKoSAwYV7dQPFGGdPhSew/lDGnEO4Y3FqLDhTnN8foHvRN0lLA0w== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 196b41be-23f5-4562-b420-08d87d9ea5a1 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2020 13:12:41.2467 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: W4nQVdWWf/2iMoCcgO+e69keCa61vZO/okv6VZCTzTAAftQ9ciX3gEg/OMfeZ7S7uWssqP97VUGkzKdSlbzTkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4815 Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/MCKzNTnt1MmL83YKVaR24J4GChw> Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt 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: Sat, 31 Oct 2020 13:12:49 -0000 On 30/10/2020 22:42, Tero Kivinen wrote: > Roman Danyliw writes: >>>>> It seems to me that the IANA entries for IKEv2 are incomplete. >>>>> RFC8247 does a fine job of specifying algorithms and adding >>>>> information such as status (MUST/SHOULD+), IoT, AEAD and so on, >>>>> information which is not present on IANA. The policy for, e.g. >>>>> Transform Type 1, is expert review and entries have been added via >>>>> draft-smyslov-esp-gont but the IANA entries lack this information >>>>> and, looking at the I-D, I see no such information (nor is there any >>>>> reason for it to be there). Yet draft-ietf-i2nsf-sdn... needs >>>>> this information as references in the YANG module show. > > I am lost what information is missing from the IANA registry. Tero Thanks for getting back to me. What is missing from the IANA registry is the guidance as to the status of the algorithm, how highly it is recommended or not. This I-D tells people to go to RFC8247 and the IANA Registry for advice; RFC8247 gives that advice; the IANA web page does not. And RFC8247 specifies which algorithm are AEAD, the web page does not. The YANG module behaves differently depending on whether or not the algorithm is AEAD; YANG implementors need to know, having this information on the web page would make it easier for YANG implementors. And RFC8247 specifies IoT, which I do not think is yet a consideration here. As I said, we are currently ok but as new algorithms get added, by Expert Review, then that information is needed and may not be available as there is no requirement for the Expert Reviewer to make it available. As I said to Roman, the TLS WG found that they needed to add extra columns to their web pages of algorithms. Different columns (e.g. DTLS not AEAD) but I think that the situation is otherwise identical so I am anticipating that in a year or two you will see what I mean:-). In passing, the TLS WG determine by consensus what the status is for a new algorithm but the Expert Reviewer makes it available via the web site whether or not it is in an RFC. I take your point about duplicating data - no relational databases here! - but the answer is to specify which is authoritative and for me that should be the IANA pages as it is for many assignments in the context of YANG and before that SMI going back decades. Tom Petch The > registry do include numbers from draft-smyslov-esp-gost document. The > RFC8247 says: > ---------------------------------------------------------------------- > 1.3. Updating Algorithm Requirement Levels > ... > .... As a result, any algorithm listed at the IKEv2 > IANA registry not mentioned in this document MAY be implemented. > ---------------------------------------------------------------------- > I.e., all algorithms not listed there are MAY to implement. > > But I do not see any reason why the yang module should provide any > other than pointer to the IANA registry, and the IANA registry already > has pointer to the RFC8247 to indicate the requirement levels for > algorithms. > >>>>> It seems to me that this is a similar situation to that which the TLS >>>>> WG found itself in and which led to a revision of the TLS IANA >>>>> entries to provide what was needed via additional columns. > > There was some requests to modify the IANA registry while we were > publishing RFC 8247 and the WG decided against it, and instead decided > to provide pointer to the RFC 8211 and RFC 8247 in the notes section. > > The reason for that is that duplicating information always causes > problems, and because there is no (public) history of the IANA > registries, there is no way of finding out when and why specific > change to the registry was done unless there happens to be RFC that > actually did that change. > > I myself as an IANA expert of those registries do think it is better > that working group will do RFC that will update the levels, and that > will leave audit trail and public working group mailing list > discussion about the changes. > >>>>> I think that the IANA pages for IKEv2 need revising so that that >>>>> additional information that RFC8247 provides is required as >>>>> additional columns in the IANA entries at least for Type 1, Type 2, >>>>> Type 3, Type 4 and Authentication Method. > > I fail to see why does that information need to be in the IANA > registry? This is YANG model for IPsec, it should just refer to the > IANA registry about the mapping from algorithms to numbers and other > way around, but whether the algorithm is recommended or not, does not > belong to the YANG model, as that is not something that can be > modified by configuration or be part of running state. > > This document seems to have wierd text in it: > > typedef encryption-algorithm-type { > type uint16; > description > "The encryption algorithm is specified with a 16-bit > number extracted from IANA Registry. The acceptable > values MUST follow the requirement levels for > encryption algorithms for ESP and IKEv2."; > > I do not see what the last sentence of the text is trying to say? Does > it mean that this yang model cannot be shown of running configuration > where someone is using one the algorithms not considered safe anymore? > In ietf we usually just try to say what implementors are implementing, > we do not that often limit what adminstrators can configure. If the > implementation happens to implement one of those weak ciphers for > example for talking to one obsoleted old hardware that only supports > them, then I do not see why this yang model should forbid showing > running status of such configuration. > > I think this document should just say that the algorithm numbers are > from the IANA registry, and nothing more. There might be informal > reference to the RFC 8221, and RFC 8247 but even that should not be > needed, as anybody implementing IKEv2 or ESP will already follow those > and only implement the algorithms from there that they seem proper. In > some cases that selection might include algorithms which are on SHOULD > NOT or even MUST NOT, if the backward compatibility to obsolete > hardware is more important than conformance. > >>> This I-D, as you quote, points to RFC8247 for guidance and that is >>> fine. But security moves on and new algorithms will be needed and >>> this I-D also points to the IANA registry, which is Expert Review, >>> where new entries have been added already; and for those the IANA >>> Registry gives no guidance and the I-D that IANA references for >>> the new entries - written by the Expert Reviewer! - also gives no >>> guidance. Over time we are likely to accrue algorithms with no >>> guidance unless and until an RFC8247-bis appears or we require >>> IANA to have columns for guidance. Currently the new algorithms >>> are GOST and so perhaps of limited interest but on the TLS list I >>> am always seeing new algorithms appear and there the new IANA >>> entry is required to give guidance. My sense is that IKEv2 is a >>> bit slower to take up new ones but, as with RFC8247, it does >>> eventually. > > The original cryptographic algorithm impelemtation requirements for > ESP and AH was published as RFC4305 in 2007. It was replaced with > RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2 > we skipped the 2014 update, as that was not needed. We do have plans > to keep that draft up to date, and update it when there is need for > that, most likely in next 5 years or so, provided that implementation > status of some of new algorithms progresses favorably. > >>> I think that users need those extra columns that RFC8247 provides >>> on the IANA website so that when new algorithms are added by >>> Expert Review, then that guidance must be added as well. This is >>> what the TLS WG came round to and I think that IKEv2 needs to do >>> the same. > > I as an Expert does not want to decide whether the individual request > to add new 3rot13 cipher to the IANA registry should be MUST NOT, > SHOULD NOT, MAY or what. If the field is in the IANA registry then > whoever requests to add information to there can request whatever > value they want for that field too. Of course as an IANA expert I can > reject that by saying that 3rot13 is not MUST, but it is MUST NOT > algorithm, and then we can have discussion about that. > > I rather have that discussion in the working group when we are > updating the requirements document next time. And as I said IANA > registries do not have any (public) history, or any way of finding out > why they got changed and who did the change. There has happened some > changes in the registry where I as an IANA Expert was not aware of at > all... > > And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or when > some of those earlier algorithms was renamed, I need to go to my > private mail archives. > From nobody Sat Oct 31 07:01:17 2020 Return-Path: <smyslov.ietf@gmail.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 40AF93A0B79; Sat, 31 Oct 2020 07:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 W68WjCbMNIcf; Sat, 31 Oct 2020 07:01:10 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6463A0B76; Sat, 31 Oct 2020 07:01:09 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id y184so9548852lfa.12; Sat, 31 Oct 2020 07:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=j49OLrG+oKpAh9gikEB3vX8qLgfyNMwzP8OFncFM24I=; b=WbsY6CFU4M9W/NPFdYGO+DhkSfXUVevA5lRKoHLpPs8cfHluTHLZ97u+xeM9MaIGzu 2CMLK+QAc0g9Slha5XcEntHjVONi2mpEMr8A8C3tboPuSW1pq4a0jPmXza7VfuywTrX8 OOsuXDgO6QSjMmBHU7HnC5dPwamTkD12dTOSlSOjA6tUD252LSf0hs+o0FIdkxBME+l6 Q91DODLndfgjX5vJZLewsf2aUAlmxxxeNTPAvBHmgJOH0IwwYI50a+cA0uAfAJ1tPDA+ iQT/Y025w6U6zDRyp80n6gqRvZAYpi1O5sXqgzXnxCyowU5IAUhF1QhgrEjcG1lDPx1r ddPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=j49OLrG+oKpAh9gikEB3vX8qLgfyNMwzP8OFncFM24I=; b=JMgHLQhhcDWiEyTpAdx3dB8aMY4yTumHo0cHMwpr7Y14MfWJkJCA0HIqovERBKE+PI VmNEaF4g4EPhUSL1czoefiZb1NF3sGObrh8PztlJxzQxg+U538xKJgeM9UbIQiunSqDN 4M3t4iwfVcXH6auC6Bj4dS2+PNm4fY/ljRQT4iJGUAGKAPi11IZOCOW9fBP7ZcyctJq7 jKaPC5l/HiQvdiGehVLznqDRMH45PAICBiVTAnU53MEyaZUGUHjnFxA70jfS/2DPMyhR vyLf1rX1849tv67NETTAp2+Tc+RMPcROznfkmk3bzPjsQd7sh7ewHxO9yv07qj/gzsCY N7pw== X-Gm-Message-State: AOAM533uzXa780vTxYNzP91zYsC2BCIlZbFBi/6AiKDcme4TboyK+VXK wyHVESHD2rlXFc7yE6aOMXU= X-Google-Smtp-Source: ABdhPJxotGKRU9e0wfabyZf59etV2wJFeUNahwL4ZVIPnzPTqP4d3NJNcqmpWsHROCjC97DOP78h9g== X-Received: by 2002:ac2:5976:: with SMTP id h22mr2556309lfp.507.1604152867939; Sat, 31 Oct 2020 07:01:07 -0700 (PDT) Received: from chichi (37-144-56-120.broadband.corbina.ru. [37.144.56.120]) by smtp.gmail.com with ESMTPSA id y8sm933753lfl.184.2020.10.31.07.01.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Oct 2020 07:01:07 -0700 (PDT) From: "Valery Smyslov" <smyslov.ietf@gmail.com> To: "'tom petch'" <daedulus@btconnect.com>, "'Tero Kivinen'" <kivinen@iki.fi>, "'Roman Danyliw'" <rdd@cert.org> Cc: "'Fernando Pereniguez-Garcia'" <fernando.pereniguez@cud.upct.es>, <i2nsf@ietf.org>, "'Gabriel Lopez'" <gabilm@um.es>, <ynir.ietf@gmail.com>, <ipsec@ietf.org>, <last-call@ietf.org>, "'Rafa Marin-Lopez'" <rafa@um.es> References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <EE5AB669-73BB-4517-A6F4-23B7807FB36E@um.es> <5F9815D1.9010303@btconnect.com> <DDE550B1-9A9E-4954-B6F9-C0A33ECE1275@um.es> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> In-Reply-To: <5F9D62C0.5030908@btconnect.com> Date: Sat, 31 Oct 2020 17:01:00 +0300 Message-ID: <000001d6af8e$43baa2d0$cb2fe870$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIoWC6Ry6044q/zCrCUKcB+KBw60wJiaB/IAqnvI9sBjCP/TgJL0fDJAoEYK+kB00mNbgLfgwdiAuAT4rcCA2fXuQGCTHRUAkPcMRyoSFYCoA== Content-Language: ru Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/687XC0TB6WJj6yy2E54o9yqzcvs> Subject: Re: [IPsec] [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt 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: Sat, 31 Oct 2020 14:01:12 -0000 Hi Tom, we discussed with the chairs the usefulness of adding "Recommended/Not recommended" column (as TLS WG did) into the IKEv2 algorithm registries back in 2018 in Bangkok and I was one who of those who initially suggested this. However, Tero made a very good point that IANA doesn't have any public history. So, in the ipsecme WG another approach was taken - we have RFCs that say which algorithms are recommended/not recommended for ESP and for IKEv2 and these RFCs are updated periodically. > Thanks for getting back to me. What is missing from the IANA registry > is the guidance as to the status of the algorithm, how highly it is > recommended or not. This I-D tells people to go to RFC8247 and the IANA > Registry for advice; RFC8247 gives that advice; the IANA web page does not. As Tero said, the IANA web page references current RFCs (8221 & 8247 at the moment) that list recommended algorithms. Just one more level of indirection. All algorithms that are not listed in these RFC are treated as "not recommended" by default, including newly added algorithms. > And RFC8247 specifies which algorithm are AEAD, the web page does not. > The YANG module behaves differently depending on whether or not the > algorithm is AEAD; YANG implementors need to know, having this > information on the web page would make it easier for YANG implementors. Is is a problem to open corresponding RFC or I-D? Or do you want to say that YANG implementers don't need any other information about algorithms except whether it's AEAD and whether it's recommended? Regards, Valery Smyslov. > And RFC8247 specifies IoT, which I do not think is yet a consideration here. > > As I said, we are currently ok but as new algorithms get added, by > Expert Review, then that information is needed and may not be available > as there is no requirement for the Expert Reviewer to make it available. > > As I said to Roman, the TLS WG found that they needed to add extra > columns to their web pages of algorithms. Different columns (e.g. DTLS > not AEAD) but I think that the situation is otherwise identical so I am > anticipating that in a year or two you will see what I mean:-). In > passing, the TLS WG determine by consensus what the status is for a new > algorithm but the Expert Reviewer makes it available via the web site > whether or not it is in an RFC. > > I take your point about duplicating data - no relational databases here! > - but the answer is to specify which is authoritative and for me that > should be the IANA pages as it is for many assignments in the context of > YANG and before that SMI going back decades. > > Tom Petch > > > The > > registry do include numbers from draft-smyslov-esp-gost document. The > > RFC8247 says: > > ---------------------------------------------------------------------- > > 1.3. Updating Algorithm Requirement Levels > > ... > > .... As a result, any algorithm listed at the IKEv2 > > IANA registry not mentioned in this document MAY be implemented. > > ---------------------------------------------------------------------- > > I.e., all algorithms not listed there are MAY to implement. > > > > But I do not see any reason why the yang module should provide any > > other than pointer to the IANA registry, and the IANA registry already > > has pointer to the RFC8247 to indicate the requirement levels for > > algorithms. > > > >>>>> It seems to me that this is a similar situation to that which the TLS > >>>>> WG found itself in and which led to a revision of the TLS IANA > >>>>> entries to provide what was needed via additional columns. > > > > There was some requests to modify the IANA registry while we were > > publishing RFC 8247 and the WG decided against it, and instead decided > > to provide pointer to the RFC 8211 and RFC 8247 in the notes section. > > > > The reason for that is that duplicating information always causes > > problems, and because there is no (public) history of the IANA > > registries, there is no way of finding out when and why specific > > change to the registry was done unless there happens to be RFC that > > actually did that change. > > > > I myself as an IANA expert of those registries do think it is better > > that working group will do RFC that will update the levels, and that > > will leave audit trail and public working group mailing list > > discussion about the changes. > > > >>>>> I think that the IANA pages for IKEv2 need revising so that that > >>>>> additional information that RFC8247 provides is required as > >>>>> additional columns in the IANA entries at least for Type 1, Type 2, > >>>>> Type 3, Type 4 and Authentication Method. > > > > I fail to see why does that information need to be in the IANA > > registry? This is YANG model for IPsec, it should just refer to the > > IANA registry about the mapping from algorithms to numbers and other > > way around, but whether the algorithm is recommended or not, does not > > belong to the YANG model, as that is not something that can be > > modified by configuration or be part of running state. > > > > This document seems to have wierd text in it: > > > > typedef encryption-algorithm-type { > > type uint16; > > description > > "The encryption algorithm is specified with a 16-bit > > number extracted from IANA Registry. The acceptable > > values MUST follow the requirement levels for > > encryption algorithms for ESP and IKEv2."; > > > > I do not see what the last sentence of the text is trying to say? Does > > it mean that this yang model cannot be shown of running configuration > > where someone is using one the algorithms not considered safe > anymore? > > In ietf we usually just try to say what implementors are implementing, > > we do not that often limit what adminstrators can configure. If the > > implementation happens to implement one of those weak ciphers for > > example for talking to one obsoleted old hardware that only supports > > them, then I do not see why this yang model should forbid showing > > running status of such configuration. > > > > I think this document should just say that the algorithm numbers are > > from the IANA registry, and nothing more. There might be informal > > reference to the RFC 8221, and RFC 8247 but even that should not be > > needed, as anybody implementing IKEv2 or ESP will already follow those > > and only implement the algorithms from there that they seem proper. In > > some cases that selection might include algorithms which are on SHOULD > > NOT or even MUST NOT, if the backward compatibility to obsolete > > hardware is more important than conformance. > > > >>> This I-D, as you quote, points to RFC8247 for guidance and that is > >>> fine. But security moves on and new algorithms will be needed and > >>> this I-D also points to the IANA registry, which is Expert Review, > >>> where new entries have been added already; and for those the IANA > >>> Registry gives no guidance and the I-D that IANA references for > >>> the new entries - written by the Expert Reviewer! - also gives no > >>> guidance. Over time we are likely to accrue algorithms with no > >>> guidance unless and until an RFC8247-bis appears or we require > >>> IANA to have columns for guidance. Currently the new algorithms > >>> are GOST and so perhaps of limited interest but on the TLS list I > >>> am always seeing new algorithms appear and there the new IANA > >>> entry is required to give guidance. My sense is that IKEv2 is a > >>> bit slower to take up new ones but, as with RFC8247, it does > >>> eventually. > > > > The original cryptographic algorithm impelemtation requirements for > > ESP and AH was published as RFC4305 in 2007. It was replaced with > > RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2 > > we skipped the 2014 update, as that was not needed. We do have plans > > to keep that draft up to date, and update it when there is need for > > that, most likely in next 5 years or so, provided that implementation > > status of some of new algorithms progresses favorably. > > > >>> I think that users need those extra columns that RFC8247 provides > >>> on the IANA website so that when new algorithms are added by > >>> Expert Review, then that guidance must be added as well. This is > >>> what the TLS WG came round to and I think that IKEv2 needs to do > >>> the same. > > > > I as an Expert does not want to decide whether the individual request > > to add new 3rot13 cipher to the IANA registry should be MUST NOT, > > SHOULD NOT, MAY or what. If the field is in the IANA registry then > > whoever requests to add information to there can request whatever > > value they want for that field too. Of course as an IANA expert I can > > reject that by saying that 3rot13 is not MUST, but it is MUST NOT > > algorithm, and then we can have discussion about that. > > > > I rather have that discussion in the working group when we are > > updating the requirements document next time. And as I said IANA > > registries do not have any (public) history, or any way of finding out > > why they got changed and who did the change. There has happened some > > changes in the registry where I as an IANA Expert was not aware of at > > all... > > > > And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or > when > > some of those earlier algorithms was renamed, I need to go to my > > private mail archives. > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf From nobody Sat Oct 31 11:28:25 2020 Return-Path: <ynir.ietf@gmail.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 776843A0A1F; Sat, 31 Oct 2020 11:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZYq-u4A6qZdM; Sat, 31 Oct 2020 11:28:19 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178A43A0A1D; Sat, 31 Oct 2020 11:28:19 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id dg9so9995168edb.12; Sat, 31 Oct 2020 11:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rogoc34AoQgRRGmf7+AIwrRVGZGquvGHX+3rKTcfijs=; b=FVznnodqQxlhXxO06b7HIP27QQ9vrN44LDtS6gVEp09YATAxItsihMYE5skSfjFrAh YEyPodtr3Eh7KFAuXT3eJUOo9babibjPBcg6C3g+MGEMMQ9t1LDDNH0KijFLUjMX1RF1 A49TAVPAmEU2FnuqHHrjVLP0oa2v2O9qovas11kKHye7zws+HGjUyb67ZnJVoUHbJ89B P4pL8JQeXo3IlNi1b239HA64bFDl8GmsK7jY0Qp/XtYx59ac3tXCvMIsQpXnc0Ynx6ba //LF8+8DGzfS2e8t0DGhAhYYtn2wjrsxHkkrLMYTgUPtrqn2ENvUJh8Zhoe/PMnGGtwZ 0AtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rogoc34AoQgRRGmf7+AIwrRVGZGquvGHX+3rKTcfijs=; b=XVU21YCAYipQgebU2dOklctaDg9Utwf7kClj5XxuBuloC6OAC7mgNjX5U8YMBvCUkT yrReLHVZ43HZu0e65hDlMpq/5RrsLt3ylwGhA3F0d+mvVvIrA6yyVZnPKmuOAh8kD0uh 3HTH0evf1caWijBsgDS+x0bL0iDFD9m7NSLjldYVZXAS31W3ZSVla4zRxA+3Osu4PKqb SrDDmC3699Uet+xE8+rjSo9YTtvTiNjE0/c1xz9sld3/wDjHkoJum1d4VXm84WjCwftx Rv/Z7gqUt9sEFCno651NS+qnofTVja2Zc8iutIgHNfzHkjcCI6im12GlPfXQ1FxCvaGF qFJg== X-Gm-Message-State: AOAM531C48jDjY/iXXWJJOznVfKWRKQeir/3qFyyOAGl/JrBswJWFa09 54zDrYt7bZmCXn6ii9SqQwg= X-Google-Smtp-Source: ABdhPJwlqemdjGj47soKonBx7DKCacJ4obB00Y+pfizr/z9ri86a67aFlhDpqMPbiUFeA0CwAzQ3fQ== X-Received: by 2002:a50:e087:: with SMTP id f7mr8597169edl.96.1604168897400; Sat, 31 Oct 2020 11:28:17 -0700 (PDT) Received: from [192.168.1.15] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id rn28sm4848615ejb.22.2020.10.31.11.28.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Oct 2020 11:28:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Yoav Nir <ynir.ietf@gmail.com> In-Reply-To: <5F9D62C0.5030908@btconnect.com> Date: Sat, 31 Oct 2020 20:28:13 +0200 Cc: Tero Kivinen <kivinen@iki.fi>, Roman Danyliw <rdd@cert.org>, "ipsec@ietf.org" <ipsec@ietf.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, Gabriel Lopez <gabilm@um.es>, Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, "last-call@ietf.org" <last-call@ietf.org>, Rafa Marin-Lopez <rafa@um.es> Content-Transfer-Encoding: quoted-printable Message-Id: <10736BF3-4833-4129-A3E2-B680696A80B5@gmail.com> References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <EE5AB669-73BB-4517-A6F4-23B7807FB36E@um.es> <5F9815D1.9010303@btconnect.com> <DDE550B1-9A9E-4954-B6F9-C0A33ECE1275@um.es> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> To: tom petch <daedulus@btconnect.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/0tGdchHRnVb01dMr6-cQckdz-ng> Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt 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: Sat, 31 Oct 2020 18:28:21 -0000 > On 31 Oct 2020, at 15:12, tom petch <daedulus@btconnect.com> wrote: >=20 > On 30/10/2020 22:42, Tero Kivinen wrote: >> Roman Danyliw writes: >>>>>> It seems to me that the IANA entries for IKEv2 are incomplete. >>>>>> RFC8247 does a fine job of specifying algorithms and adding >>>>>> information such as status (MUST/SHOULD+), IoT, AEAD and so on, >>>>>> information which is not present on IANA. The policy for, e.g. >>>>>> Transform Type 1, is expert review and entries have been added = via >>>>>> draft-smyslov-esp-gont but the IANA entries lack this information >>>>>> and, looking at the I-D, I see no such information (nor is there = any >>>>>> reason for it to be there). Yet draft-ietf-i2nsf-sdn... needs >>>>>> this information as references in the YANG module show. >>=20 >> I am lost what information is missing from the IANA registry. >=20 >=20 > Tero >=20 > Thanks for getting back to me. What is missing from the IANA registry = is the guidance as to the status of the algorithm, how highly it is = recommended or not. This I-D tells people to go to RFC8247 and the IANA = Registry for advice; RFC8247 gives that advice; the IANA web page does = not. It=E2=80=99s possible to add a column in the IANA registry, but it is = not possible to capture the information from 8247 in such a table.=20 RFC 8247 has =E2=80=9CMAY=E2=80=9D and =E2=80=9CSHOULD+=E2=80=9D labels, = but it also has comments and a bunch of explanation, such as that some = algorithm is a SHOULD for IoT, but not otherwise. I think it=E2=80=99s = better to point people at the RFC where the information is, rather than = post very partial information in an IANA table. Yoav