Re: [Pce] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

"Acee Lindem (acee)" <acee@cisco.com> Wed, 11 August 2021 17:18 UTC

Return-Path: <acee@cisco.com>
X-Original-To: expand-draft-ietf-lsr-pce-discovery-security-support.all@virtual.ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 003C43A1D7A; Wed, 11 Aug 2021 10:18:13 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-lsr-pce-discovery-security-support.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-lsr-pce-discovery-security-support.all@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFE53A1D77; Wed, 11 Aug 2021 10:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 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_NONE=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=T1ks6ZKE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eVmkiy89
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 0qyBHhlO_rMG; Wed, 11 Aug 2021 10:18:07 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2263A1D6E; Wed, 11 Aug 2021 10:18:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14078; q=dns/txt; s=iport; t=1628702287; x=1629911887; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v3sJh/YtTxFu3cWev0NGSs/orgit/9sYN50lOtdLHV4=; b=T1ks6ZKE/iUuY0j9D5bdCZSygWvsf2UOTiYupTf9wvQ4fb8QLjtrShwq P+9vgZAtCzdNT8wd3gw+U0gCOCX8drRrFr0Lm5xtmRTTcYX5C9nKGnLay iXNEJiUnhAwphgqmwR+03V9vRQpixklfCxl5NoB0YOCEKqMl6vKVINy8m w=;
X-IPAS-Result: A0ALAwB8BRRhl4kNJK1aHgEBCxIMQIFOC4FTUX5aNzEChEWDSAOFOYhpA4paj1uBQoERA1QLAQEBDQEBKgsMBAEBhFkCF4JPAiU3Bg4BAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBgQiFaA2GQgEBAQECAQEBEBERDAEBJQQDCwEPAgEGAhUBBAIjAwICAh8GCxQBEAEBBAENBSKCTwGCVQMOIQEOjk2PNAGBOgKKH3qBMYEBggcBAQYEBIUqDQuCNAMGgRAqgn2ED4EYgVKDeiccgg2BFAEnHIJiPoIgQgEBgSsBEgEJPoJxNoIugn5bBjIyBA0VIRBbJFUBAgMKBhgCDxQBBA4DlTWnDztdCoMomGkEhWAFJoNli2ADlyiWEI90j3svgXaDCQIEAgQFAg4BAQaBdiNrcHAVOyoBgj5QGQ6LR4JYDQwJg1CFFIVKcw0rAgYBCgEBAwmIeAEB
IronPort-PHdr: A9a23:sqB0iB9XC3TNp/9uWMfoyV9kXcBvk7/oNQkT7Jcsl/RFdaHwt5jhP UmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBXhMIk4MaygonBsPWA1HwK/jsYicmW s9FUQwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=
IronPort-HdrOrdr: A9a23:BC7Vra/n12J1wOnbcqJuk+GOdr1zdoMgy1knxilNoENuE/Bwxv rBoB1E73DJYW4qKQ4dcdDpAtjmfZtFnaQForX5To3SIjUO31HYbr2KjLGSgwEIfhefygcz79 YaT0ETMqyUMbE+t7eH3ODaKadk/DDkytHTuQ629R4EJmsGB9ACnmVE40SgYzBLrWJ9dPwE/e +nl7J6Tk2bCA0qh6qAdx04dtmGg+eOuIPtYBYACRJiwhKJlymU5LnzFAXd9gsCUhtUqI1StV Ttokjc3OGOovu7whjT2yv49JJNgubszdNFGYilltUVEDPxkQylDb4RHIFq/QpF5t1H2mxayO UkkC1QZPibLEmhJF1dlCGdgjUIFgxetkMKh2Xo3UcL6vaJNQ7SQ/Ax9b6xNCGptHbJeLpHof N2N6XzjesIMfqIplWO2zCDPSsa5XacsD4sl/UegGdYVpZbYLhNrZYH9EcQC5sYGjnmgbpXXN WGIfusrsq+S2nqIkwxf1MftuCETzA2BFOLU0ICssua33xfm2141VIRwIgakm0b/JwwRpFY76 CcW54Y2o1mX4sTd+ZwFe0BScy4BijERg/NKnubJRDiGLscM3zAppbr6PE+5f2sepYP0Jwu8a 6xH29wpCo3YQbjGMeO1JpE/lTER3i8Ry3kzoVE651wqtTHNfHW2O24ORgTeu6b0rQi6+HgKo KO0aNtcrbexDHVaPN0NiXFKu5vFUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.84,313,1620691200"; d="scan'208";a="754850406"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Aug 2021 17:18:06 +0000
Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 17BHI2YE014147 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 11 Aug 2021 17:18:05 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 11 Aug 2021 12:18:04 -0500
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 11 Aug 2021 12:18:03 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 11 Aug 2021 12:18:03 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kO70SHsNnoJIbqzZPjvuimiUSRuLNk+yZ+nPZ6zSbt8J1BB/DPJZxj1egswb7zOR/e9uciIC4Up/glZLEu9zvZbXj0PUV4f6gEXW/GDElqf9JPZ1Yc5JkEF5eAPg6kfIDpi20rJE5Qw1uqy1CBmuynZBzdEL9sGlyUQsR7Q/QWM2uZxDl3Yr/RDd6pmWAzq5vcfcUZ84pi568nsmExTQKV2PFCTCoZxBSKoQW+2hSyc8rZhDHthd7Cliu+Xqphyo1E6cWUMOkYSJhOp19BXhrAhbeGp0BR+iV+UMU4tuiE5IVday0NOi2XglNEYnBAgz3xcoRumaSVK4RuxqR9QkUw==
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=v3sJh/YtTxFu3cWev0NGSs/orgit/9sYN50lOtdLHV4=; b=C2jj19AM0w8OBtrQwXSIW7kJoUQtlmNiSCtMpoDSJESaCwSj1Kw7XQxB0O7xhHH2KhKc59n9h+vFuKMixsQFGgOuANNJQWScaFcNFk/FN4kfc3Dq2i5juA8+qpVu3kO3Aq2VHs1nJo/qHhMKUT3j1HpmS27NIQs3KxQt4OIwvJCCGrXO9ZZIhpnZaxEdkmP/y3H5YxbZhmaj6s2DmWl7AP9j8QSkx86bCUPPhceoh0D+GlV3JR/X7hTOJ/R9Mpw4BT/FPnUxc5PQgT9MZTlWdHoQ3jPM4Ut1HJwEYD00xaUhVi1hrkB0Mfqm5Skjqn2hfIJ43DERUPMmmn3DPcjg1w==
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=v3sJh/YtTxFu3cWev0NGSs/orgit/9sYN50lOtdLHV4=; b=eVmkiy89iUY55Jks9jgm2AkAsGlh4lplPQYic9r3NzABrPPr/3PE39VrNQxO+v5gG8V+N/hO6R4iqMXcmxIlD9G/fqq0nvCza5hNw3qNNDFN8uD+6X8AthAjqSgTDj/ti61pkOkRY1TDWi0U7BrTIdDv0M9rkuIJZ4HDwbjCAWc=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3015.namprd11.prod.outlook.com (2603:10b6:a03:86::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.18; Wed, 11 Aug 2021 17:18:01 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::a19c:e0ca:19d9:19e2]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::a19c:e0ca:19d9:19e2%3]) with mapi id 15.20.4394.023; Wed, 11 Aug 2021 17:18:01 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: tom petch <ietfc@btconnect.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Qin Wu <bill.wu@huawei.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-lsr-pce-discovery-security-support.all@ietf.org" <draft-ietf-lsr-pce-discovery-security-support.all@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
Thread-Index: AdeN3D1bao4BcToNQmG4p4waGPgvAwAE3DaAAANt8yEALXoBgA==
Date: Wed, 11 Aug 2021 17:18:01 +0000
Message-ID: <22005B23-E43D-442A-B11C-7AAC6DB85D73@cisco.com>
References: <728cb9ce17b44bed8a4ab059a9656620@huawei.com> <CE9B9F20-ED31-4DFB-B718-A3613126D29D@gmail.com> <AM7PR07MB624867062C8479E132784CA8A0F79@AM7PR07MB6248.eurprd07.prod.outlook.com>
In-Reply-To: <AM7PR07MB624867062C8479E132784CA8A0F79@AM7PR07MB6248.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.51.21071101
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ac9b9fb4-e3e5-41f6-fac3-08d95cebf91c
x-ms-traffictypediagnostic: BYAPR11MB3015:
x-microsoft-antispam-prvs: <BYAPR11MB3015E5DA14C79A178C0F0DB8C2F89@BYAPR11MB3015.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G2pvgcKbdkY3azRnUoSoGan7OaaNM4pAMB2HqeJNcALRGDJ1bUZPpFCrAPaQQF6uaM0LkclHyA39FDFRWdEuH5QTDKnQzcvCTZT+QcUAF/hEi1J98R+QhkqMR+zJ2urRfDiY7nXDNC7fjHT0wMgRy8Tlp+qdFT6Jbls0/Z8aYbUrdbruvXR0BSJqLkwEnpHYvq06HTcpptOKbtLHhUEz17CNoA3Dq6Reh9QlTNMIpYW2Q8psMHfJgis4/5v06VEShXhEbF4lwZydEoXO/M+Js+PyypMHmHHzX/0JdE6EKkxJPZtOFr19eFRFeAPufgFQCxL7944C/kPeB1bM9prVGvAnw2MfSvzkELus4DX/gF5iRkMij3MYXwgnh/8MmuLvQ5dWlaQHLFKcaWnTumh7sDkkR62COB1sxjNEKLqdHVYIlTSH6c60B7U/+72MsPENGZBXV2K0M0JfJDjxEh2zs4TVnaJFGMSmGQihrYbeGnt2ikpJT84AeGBZIfv9Uw+jfBxIYI+pB3VemW6IyZSVIeRW9nBTQOaJ2rMyPJX2VZNmyZpM6q11aHCm1d5596Ce8m1OsDNaVKA7sOv7dN28gI4XhyMyIpR1dxpLu0nKGRtTSZsOcLTWMbbrYHmgc1wBemnBbr3V68bnvZ2H3B/gVZ6ebewkksAGb/JGU3DzGx5CHZTs3+FzMi8mncXoKds1NT2QUV4rqUVu6U9xWqYRJkIvHoHnlkVv5n6d0BYI+Eh5HOrYMtIdiv2dxRy3QE3B659BiGbC3nxYTH0xadUWqJxwpupScdKNQv4uIim6Pfoyy1bu/eXOsZNkJiMHrWdm
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(366004)(376002)(346002)(396003)(86362001)(83380400001)(2616005)(110136005)(2906002)(15650500001)(71200400001)(296002)(33656002)(316002)(6512007)(8936002)(26005)(64756008)(66556008)(38100700002)(478600001)(122000001)(66446008)(36756003)(5660300002)(8676002)(966005)(53546011)(6506007)(4326008)(66476007)(6486002)(76116006)(66946007)(38070700005)(186003)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: JNxFuAaBk7EdXMhE61924C+3QLtKUtJDQ/lbNUVE0JflXqnxsD25isxMOsVKEnYIFrxVbSg7QK+Ubd3G2CTH4iUNf0Eam4cRu6oZ4uZv/ItKgrE59/oxvhxmmevoXBkHJgjcjQQXETsJFTSxi58kd411Ted9r0PsWJNhYkfZrKMP4diFHue25MbDoWJ0YIusIpi9pJUsX6JgLhkXM52/hCXRVE3aBvBeiJKf4ARF6ceDOuWA0hIDXgX6hTKxkQQpHdsnLDnxWCHEvt/gzbOyd/4ONfabwfEBYUuyFcOcDVM7/uVvtxM2phQQYgUlcDEpkHF+Y+AvBAlqGtIt3fooprXTk1CNcLUD7s0Z178Qss+1fH7evUjYxNjTOUQZXvGOGgm47TLiljpNPtKN+jPd3R2KklfiplbVCYM24mUf/lOrssk4YsheE06OD0LrDLwYd13XABnxswhW5qhalkYj/Xrcjv3dikVEy9ag2/e1t5AI9y27hzOub+4AhqlUux0jQ+tupPiM8Ow96s11C6qY5DclmtHxdRshgqUJg3+xTT+XQVBlrhTha871DJd6zM5LjJzCPbNFbSmUfCw6qoaeU5dmmOONEkFuzkkikocKOQT3Z5D0CJrK9nMk+F9I1jBWjvJ6XeLgRvC+X08xnzcTc93RRV4xrjiG58KR+GLSW2qPEQWYFwyaw9ZzPhRjvGTNGfziwUgH1DjyD81sXNGPbkNTSafvFhJhTR2cvx2sRmtKDKLkA/PE3b2Txq8qY33zbm63RNb7aaE8PwKMj5ZQV8po/Ak1nZj8HnR3gskj1hSA53uVpAm1LspCo5o1DjhJt5+bLpoiosMPoHr5q475m2NbRcZaFL0MecHkaegu4de1lE9VmeZJCwtoWHppkPsJt6BXUpJMb6qUMGacWP2duMNRAGTA1LL1DNh3PMhatJG3Kdba6xCLYHlMXKKe+hYxkm7vPL3QtLodUnvcNymIgFl7jMPY/teuS4wxMA94nLr9j23xWJPxu3dovR2dtiwqbodbvDPaPXiaGSooGCx1g4VWQPC7uNke9CIhrnRAOjkxhkVH191sa9cfMicaVDk0T5pl/Is28H2QzXGJQ3Ior8PY9poPXoSWOM+pPzaplONqHgwFRsUTxj6UQJI0asj7L607YF+HoEzFWNpE685A2aNuMztFp1s78vVwwRqYR7d3MnFjc4m19S7OPVhD5D1Wk1/iovmvTQwIESUl4ZzMEZ/BXt8RHgHQYmB3xn/HoXBe9/Znus7WvNUAZ7ddpe1KKP8zqdC0/mecR1e7gCs0nmTDn9W3/J+VvM+IM2sk8g4IB4a9KkVuu1vF60ljP3zC
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <F851E565EBD9B44D8FA9E38E64A3392E@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ac9b9fb4-e3e5-41f6-fac3-08d95cebf91c
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2021 17:18:01.4662 (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: t+lV0TO+OyX3yUzPJHut8gPQRW6yM2hLOJLbAHiATqDpf7pmUAuc76NqUcffExVU
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3015
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Resent-From: alias-bounces@ietf.org
Resent-To: yingzhen.ietf@gmail.com, dhruv.ietf@gmail.com, lsr@ietf.org, diego.r.lopez@telefonica.com, bill.wu@huawei.com, chopps@chopps.org, pce@ietf.org, daniel@olddog.co.uk, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, jgs@juniper.net, maqiufang1@huawei.com, acee@cisco.com
Resent-Message-Id: <20210811171814.003C43A1D7A@ietfa.amsl.com>
Resent-Date: Wed, 11 Aug 2021 10:18:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/ArIt8NvCqNEpat1gKYTNDtx5_cs>
Subject: Re: [Pce] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Aug 2021 17:18:14 -0000

I'd also recommend changing, "key names" to "key-ids or key-chain names" since this is what is actually being advertised.
Thanks,
Acee

On 8/10/21, 11:53 AM, "tom petch" <ietfc@btconnect.com> wrote:

    From: Lsr <lsr-bounces@ietf.org> on behalf of Yaron Sheffer <yaronf.ietf@gmail.com>
    Sent: 10 August 2021 14:57

    So let me suggest:

    <tp>
    An offlist suggestion for you to consider

    OLD
        Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP protects the authentication and integrity of the PCED TLV using the mechanisms defined in
        [RFC5310] and [RFC5709], if the mechanism described in this document is used.

        Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not provide any encryption mechanisms to protect the secrecy of the PCED TLV, and the operator must ensure that no private data is carried in the TLV, for example that key names do not reveal sensitive information about the network.

    NEW

     Thus before advertising the PCE security parameters, using the mechanism described in this document, the IGP MUST be known to provide authentication and integrity for the PCED TLV using the mechanisms defined in  [RFC5304],  [RFC5310] or [RFC5709],

        Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does not provide any encryption mechanisms to protect the secrecy of the PCED TLV, then the operator must ensure that no private data is carried in the TLV, e.g. that key names do not reveal sensitive information about the network.

    Tom Petch
    </tp>

    Thanks,
            Yaron

    On 8/10/21, 15:01, "Qin Wu" <bill.wu@huawei.com> wrote:

        Yaron:
        Thank for clarification. I agree to keep the last sentence in the second paragraph of section 7 as is.
        But I prefer to add the addition references in the previous sentence as follows:
        "
        Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP is
        protected for authentication and integrity of the PCED TLV,, with the mechanisms defined in
        [RFC5310] and [RFC5709] if the mechanism described in this document is used.

        As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect
        the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration.
        "
        If you better wording, please let me know.

        -Qin
        -----邮件原件-----
        发件人: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
        发送时间: 2021年8月10日 19:26
        收件人: Qin Wu <bill.wu@huawei.com>; secdir@ietf.org
        抄送: draft-ietf-lsr-pce-discovery-security-support.all@ietf.org; last-call@ietf.org; lsr@ietf.org
        主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

        Hi Qin,

        Sorry, but I find your latest proposed text very confusing, because we should be focusing on integrity protection and not privacy (=secrecy) of the TLV. So I would prefer to keep the text as-is, with the addition of a reference to the IS-IS and OSPF security mechanisms that were discussed on this thread.

        Thanks,
            Yaron

        On 8/10/21, 05:00, "Qin Wu" <bill.wu@huawei.com> wrote:

            Hi, Yaron
            -----邮件原件-----
            >发件人: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
            >发送时间: 2021年8月9日 21:44
            >收件人: Qin Wu <bill.wu@huawei.com>; secdir@ietf.org
            >抄送: draft-ietf-lsr-pce-discovery-security-support.all@ietf.org; last-call@ietf.org; lsr@ietf.org
            >主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

            >Hi Qin,

            >Thank you for your response.

            >* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 still uses HMAC-MD5, which would be considered insecure nowadays.
            >* RFC 2154 is very old and Experimental (and only supports RSA-MD5 signatures). I'm not an OSPF expert by any means, but I'm willing to bet that there are no production implementations of this RFC. (I'm willing to be proven wrong).
            >Is there another RFC that define a protection mechanism for OSPF?

            >All in all, there appear to be no good options for the IGP.

            [Qin Wu]Yes, we do have alternatives, see Les's response in the separate email
            "
            On 8/9/21, 23:36,"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> wrote:
            For IS-IS security please also see RFC 5310.
            For OSPF security please see RFC 5709.
            "
            >To your last point, when I mentioned decoupling the mechanisms, I was suggesting to use the extension you define even if the IGP *cannot* be secured. If you think this is reasonable, please add such text to the Security Considerations.

            [Qin Wu] Okay, how about the following change
            OLD TEXT:
            "
            As stated in [RFC5088]
            and [RFC5089], the IGP do not provide encryption mechanism to protect
            the privacy of the PCED TLV, if this information can make the PCEP
            session less secure then the operator should take that into consideration .
            "
            NEW TEXT:
            "
            As stated in [RFC5088]
            and [RFC5089], the IGP do not provide encryption mechanism to protect
            the privacy of the PCED TLV, if this information can make the PCEP
            session less secure then the operator should take that into consideration
            when getting the mechanism described in this document deployed.
            "
             >Thanks,
             >      Yaron

            >On 8/9/21, 16:09, "Qin Wu" <bill.wu@huawei.com> wrote:

              >   Thanks Yaron for valuable comments, please see my reply inline below.
                -----邮件原件-----
                >发件人: Yaron Sheffer via Datatracker [mailto:noreply@ietf.org]
                >发送时间: 2021年8月6日 3:25
                >收件人: secdir@ietf.org
                >抄送: draft-ietf-lsr-pce-discovery-security-support.all@ietf.org; last-call@ietf.org; lsr@ietf.org
                >主题: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

                >Reviewer: Yaron Sheffer
                >Review result: Not Ready

                >This document defines a mechanism (a TLV) to advertise the PCE Protocol security required (use of TCP-AO and its key ID, or alternatively use of TLS) within the routing protocol being used.

                >* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. Especially given the strict client behavior defined later.
                [Qin]: I believe "SHOULD advertise" is consistent with client behavior defined later, i.e., we apply SHOULD NOT language to the client behavior.
                I am not sure we should change it into strong language with MUST. Since if IGP advertisement doesn't include TCP-AO
                 support flag bit or TLS support flag bit, NMS may fall back to configure both PCC and PCE server to support TCP-AO or TLS. That's one of reason I think why we choose to use SHOULD language.

                >* Sec. 3.1: should we also say something about the case where both methods are advertised, and whether we recommend for the client to use one of them over the other?

                [Qin]: It is up to local policy, which has bee clarified in the end of section 3.1. Hope this clarify.

                >* Sec. 4: typo (appears twice) - "to be carried in the PCED TLV of the for use".

                [Qin]:Thanks, have fixed them in the local copy.

                >* Sec. 7: this phrase appears to be essential to security of this mechanism: "it MUST be insured that the IGP is protected for authentication and integrity of the PCED TLV". I would expect more guidance: how can this property be ensured in the relevant IGPs?
                [Qin]:I think mechanism defined in [RFC3567] and [RFC2154] can be used to ensure authenticity and integrity of OSPF LSAs or ISIS LSPs and their TLVs. Here is the proposed changes:
                OLD TEXT:
                "
                   Thus before advertisement of
                   the PCE security parameters, it MUST be insured that the IGP is
                   protected for authentication and integrity of the PCED TLV if the
                   mechanism described in this document is used.
                "
                NEW TEXT:
                "
                   Thus before advertisement of
                   the PCE security parameters, it MUST be insured that the IGP is
                   protected for authentication and integrity of the PCED TLV with mechanisms defined in [RFC3567][RFC2154] if the
                   mechanism described in this document is used.
                "
                >* Also, a possibly unintended consequence of this requirement is that if the IGP cannot be protected in a particular deployment/product, this mechanism would not be used. Please consider if this is likely to happen and whether we want to forego PCEP transport >security in such cases. My gut feel (not based on experience in such networks) is that the threat models are different enough that we should decouple the security of IGP from that of PCEP.

                [Qin] I agree IGP security should be separated from PCEP security. IGP extension defined in this document is used by the PCC to select PCE server with appropriate security mechanism. On the other hand, Operator can either use IGP advertisement for PCEP security capability or rely on local policy to select PCE. If operator feels IGP advertisement is not secure, he can fall back to local policy or rely on manual configuration. Hope this clarifies.







    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsr