From nobody Mon May 24 12:04:27 2021 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5EA3A326E; Mon, 24 May 2021 12:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 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_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=EvDrlfeN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lPzvvvU+ 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 GsAmSaDPE5cr; Mon, 24 May 2021 12:04:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521CD3A32AD; Mon, 24 May 2021 12:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20598; q=dns/txt; s=iport; t=1621883049; x=1623092649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iaP6hY6R1vSLln0VH1jA5Vo4cCx3kl7OLK0gsuphdAU=; b=EvDrlfeN1ZvtF6KVjJ++bBan86v26LOiEuO2UDyjCJd4/1UVmm3Ls1eY uC6+81BTxwxh/x+WwU2kLfqgh7w+mfnPBCJP3LFCSaTCPjSuxyQ6WUwQZ uKmuWgObsjKsGBIskISofoL1rRPgHJhTouVgVcbDGeIaX3ojNk03drahe w=; IronPort-PHdr: =?us-ascii?q?A9a23=3AsvghYRNaHEXdxeVg6RYl6ncdWUAX0o4cdiYQ6?= =?us-ascii?q?4Zhhr5TIeyv/JXnaUrY4/glzFrERp7S5P8Mje3K+7vhVmoN7dfk0jgCfZVAW?= =?us-ascii?q?gVDhZAQmAotU8uEFQv2IOO5JyA/Fd5JAVli+XzzOENJGcH4MlvVpHD67TMbF?= =?us-ascii?q?hjlcwRvIeGgEY/JhMPx3Oe3qPXu?= IronPort-Data: =?us-ascii?q?A9a23=3A9n8L46iOfLSZBmCSdBqepTY2X161/hIKZh0uj?= =?us-ascii?q?C45NGQN5FlHY01jehtvCm2EPPbbNmKhftkkOt+w9x5V75eBx9NnT1ZrqSFjE?= =?us-ascii?q?35jpJueD7x1DKtf0wB+jyH7ockOA/w2MrEsF+hpCC+GzvuRGuK59yAkiPvUH?= =?us-ascii?q?uCU5NPsY0ideyc1EE/Ntjo78wIJqtYAbemRW2thi/uryyHsEAfNNwpPD44hw?= =?us-ascii?q?/nrRCWDExjFkGhwUlQWPZintbJF/pUfJMp3yaqZdxMUTmTId9NWSdovzJnhl?= =?us-ascii?q?o/Y1x4pDtXgmbHhfwhRBLXTJgOJzHFRXsBOgDAb+Xd0ifh9baFaMBwJ49mKt?= =?us-ascii?q?4gZJNFlt5W0Qg4oMqDkk+UGWB4eGCZ7VUFD0O+YeSXn7pDIkCUqdFOpmZ2CF?= =?us-ascii?q?noeNJcV5u9xCCdP+OAWAD8IZxGHwemxxdqTUellnMk4BM/nLoNZsXZlpRnYA?= =?us-ascii?q?ewOQJ3fTePN/9Aw9DY8nIVFHf/ffdExaDdzYlLHeRInElsNAZwi2ealmne6c?= =?us-ascii?q?jFC7Viave8552/M1xR82/3qMdb9e9GWS4NShEnwjmPL5GvRAxwGOpqY0zXt2?= =?us-ascii?q?nGlivLMtSb6RMQfGKDQyxLAqDV/3UQaDBkQEFC8u/T80Qi1WslULAof/S9Gk?= =?us-ascii?q?ET7z2TzJvGVYvFyiCfsUsYgZudt?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Adl1qTKh+/cplAXZYF42NLLIU83BQXw913D?= =?us-ascii?q?Abv31ZSRFFG/FwyPrOoB1L73HJYWgqN03IwerwR5VpQRvnhPlICPoqTMmftW?= =?us-ascii?q?7dySqVxeBZnMXfKljbexEWmdQtrpuIH5IObeEYSGIK8foSgzPIU+rIouP3ip?= =?us-ascii?q?xA7N22pxwGIG0aCNAD0+46MHfnLqQcfnghOXNNLuvl2iMxnUvYRZ14VLXeOl?= =?us-ascii?q?A1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPQf2FmAtza8yr?= =?us-ascii?q?Sosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcZcsvy5zXUISdOUmR?= =?us-ascii?q?EXeer30lEd1gNImirsl1SO0F/QMs/boW4TAjHZuASlaDDY0L3ErXoBerp8bM?= =?us-ascii?q?RiA0HkA45KhqAh7EqNtFjp6qa/RCmw7xjV9pzGUQpnmVGzpmdnmekPj2ZHWY?= =?us-ascii?q?9bc7NJq5cDlXklXavoMRiKo7zPKtMeRv00JcwmB29yZEqp8lWHAObcFkjbOy?= =?us-ascii?q?32DXTqlvblpwS+rUoJhnfwnvZv60vo3KhNPKWsyd60QJhVqA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQCp96tg/4gNJK1aDg4BAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFGBAEBCwGBUiMuB3daNjELiAUDhTmIbAOBDYkyhQmKN4F?= =?us-ascii?q?CgREDVAsBAQENAQE1CgIEAQGBGIM4AoF+AiU3Bg4CBAEBARIBAQUBAQECAQY?= =?us-ascii?q?EcROFaA2GRAEBAQMBEi4BATAHAQsEAgEIEQQBAQEuIREdCAIEDgUIGoJQglU?= =?us-ascii?q?DDiEBAwucSQGBOgKKH3iBNIEBggcBAQYEBIFIQYMzDQuCEwMGgToBgnqIP3y?= =?us-ascii?q?BLiccgUlEgRVDgV9KNj6CH0ICAQKBKAESAQkaMIMbgi2BWRABLS0CBAINLxs?= =?us-ascii?q?LBCINDAgOAlAvEgcqCCANBQEEAQEBDgwIAQQGHAEmkHuCdwGKKIs5kR1bCoM?= =?us-ascii?q?XigqOBASFYhGDW4sZiwaLUpdUiXmDJI90BIRtAgQCBAUCDgEBBoFqJWlYEQd?= =?us-ascii?q?wFTuCaVAXAg6OHwwWFYM5hRSFBUVzAgE1AgYKAQEDCXyGNS2BBwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.82,325,1613433600"; d="scan'208";a="870507437" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2021 19:04:07 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 14OJ47ge003885 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 24 May 2021 19:04:07 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 24 May 2021 14:04:07 -0500 Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 24 May 2021 14:04:07 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 24 May 2021 14:04:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L/bvH0iGbAlziHpv9LXA8tkGMusx3lt+iBgsDJNgT4UgZd+CeSMtcDrdroQzcFx4W+9dySDI3nEZAXy+U11yWS1k3KK9Vkz6ZyAkZ9xbfhu7CEKAhZ6gsjZP7uQQaE53UTYatYAxv1jbMxgozFy6y3V3OeSa7EzUQm4jM47tZsb2tZnhX7dkCrZC4lMU8be4c8ClwJHlItVQeWpHNcEYYh/jIjGMCa8V0UAiuph/YLbc2zMSyKI7S+Ikmlm2zhN2f88XBVmDhiASW+bbAt0z9+8hnPcqg0WwSJ6EZlPJ4JNYVDZQE6rwPh6SF2Wa40kj6IDS6siKPQOq7ciyupaXiw== 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=r+OTsE6c6uh2n9H50h80CXedf2uxvXaKcjn49nuclqw=; b=DyvIbfQLgdwjwWhEX1BgQULqjRJnDPUB8RBzIbVk2rq9cBjrmxqg0MqZU0acIcV32ushnpIkFgNokJnMMJV1gZadm1h5D1qXO++9YBHFI3Fc9/4JYwKGzKwrTfvJMSu8397fL21I46Qr+wYWAJVAs6xXjTAHFxnhco/aFahWPgPzm4SW2PX17t7QUglOOFq2HgBiUF+0IZrATP4aVXGTj4rMHxw7fsreVnNTgbR2HJivJWlkSjus/YbgjruKoqHV57U8m2f+H6P7CguYT2UosIt8LH8vpqxvQNJkJoINpAkLChUf1MW4ECRqcCgWVR/eE7kY9M6PdKrzowN+O8J9PQ== 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=r+OTsE6c6uh2n9H50h80CXedf2uxvXaKcjn49nuclqw=; b=lPzvvvU+vUaJ87NU3OxGlkwvDU9YfZ42sGJtD4IZRGObP8XyU0Z/CUY7nZ3BVuKbTSFxZQQLUak0m3pnP1HVXWKsa574Q90Kpcxr9cXQTeMd5Bm6ZloFugi24s01aLl/hnZSD9447tr+ct0PS/gJKtKrcNa+tEOZoPtlRro8uaI= Received: from BL1PR11MB5416.namprd11.prod.outlook.com (2603:10b6:208:319::22) by MN2PR11MB4176.namprd11.prod.outlook.com (2603:10b6:208:13b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.26; Mon, 24 May 2021 19:04:05 +0000 Received: from BL1PR11MB5416.namprd11.prod.outlook.com ([fe80::95e1:5bbb:188a:1aed]) by BL1PR11MB5416.namprd11.prod.outlook.com ([fe80::95e1:5bbb:188a:1aed%7]) with mapi id 15.20.4150.027; Mon, 24 May 2021 19:04:05 +0000 From: "Juan Alcaide (jalcaide)" To: Benjamin Kaduk CC: The IESG , "draft-ietf-idr-bgp-flowspec-oid@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" , Susan Hares , "aretana.ietf@gmail.com" Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT) Thread-Index: AQHXSPmSxnaQG1WzEEi7zxQAb51JkarobSewgAYUOQCABHDqUA== Date: Mon, 24 May 2021 19:04:05 +0000 Message-ID: References: <162102145453.12250.16239592060339839431@ietfa.amsl.com> <20210521213840.GW32395@kduck.mit.edu> In-Reply-To: <20210521213840.GW32395@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [83.55.133.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6160679-646e-403a-4686-08d91ee6b3aa x-ms-traffictypediagnostic: MN2PR11MB4176: 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: p6HC3X3sr8q00/SG7Az1q6GH5Yu06NtkgbAzl3Fh28DdkU02e7mueXGAkB5UbwxK+RG1EAbyl/TVDZD8fDFvCTT6HsrmEoFB3p4VthQHMldVMOlRuylSgHL5tzmjb3iYwOhBz28GAofR/W1pPaBMTIGu/93oe1azWy0EQT7X1k9tydC5D0wXRbiu1BTwkMWkxtYGFd3AeWVoT241m/xkuRickF0gLsBkBTGeadw+dCJNC0+GtEzXrqJMHOVGghIy3z6prBu5JAxinbOO4cQQMYphOBz/PQdTyFrig9HYJjrv7NMo2sh/7/e5YzeJjvSFnJxolYa7Rl/yLVtrfW2PNRZcaTMEDhW9ZVP+pp7KPn7OjrNORua7di3P/rgQ5YUoxr4+mXtdMjPd6XlZNojcpUMLyOXG/7h2e5cJCn5yOrK3XmBr1HKDLqB/p+ceRRtSCjRlvTxMKzE2U91/0pq1wpKJ7zDtLT2fWdRqMW/SVlzXWJc46yBCl9g6aTIzd2UQl/Jb+xmzy0YcL2pbT+8aBFZMr484hCos3aa1iK9QhCvyb16+2MTIiOCAZXXQ799DQv+RZEmiGoN50XaM34rh9N3PT7JcrwMaKT6FatvnYNGCVDlepNPIqb0Dar4P5rWY+XZoAmwvxFdN3JahEAMkRVNMeUuKR74Oy7AczcFxtw3cs2yR0bCjmWYEUOfRhmrVXgxTwqG+vHe48RR4oHrhIw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL1PR11MB5416.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(346002)(39860400002)(366004)(396003)(186003)(26005)(66476007)(54906003)(76116006)(8936002)(53546011)(6506007)(52536014)(55016002)(5660300002)(30864003)(9686003)(66446008)(64756008)(66556008)(2906002)(966005)(86362001)(66574015)(6916009)(83380400001)(7696005)(38100700002)(8676002)(316002)(478600001)(71200400001)(4326008)(66946007)(122000001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?vSWuIjkwIm0iZwDR9mSxYGxMxYFnPwksW0lHEptX2xhhXnGl3x+eCuysAK?= =?iso-8859-1?Q?WfQk1DvbApddEexxraUQ7N+ttafj6oRhGvQfY+DeyuG7j/PaaIUEGmO0wI?= =?iso-8859-1?Q?pYj1zl5h3eJBfU0Bxjj+MWe1efAe2ET/+zmOUROPMG+NsYRqyIsey7UCzK?= =?iso-8859-1?Q?nZYZaL6Wt2xa3uXr22J5UvJiNq6Zzlr6f7LM/hYXFIt1kq9evn6Q8UbBNw?= =?iso-8859-1?Q?7d5XM3GNJajM6IyrIVAuZ2VmjwkANRc7pQAlv+ouyHUy5cVti1Iw44Sa2N?= =?iso-8859-1?Q?o2TQaXq6+rJRNLR89Vhf56pQV9WwxCIYN/zXrM4GYH8jsZVdHbF92Jt1/U?= =?iso-8859-1?Q?nogAeqdB7McHP3o810p2XwoX2eQUd5YWrXUTyztd/rGu/OTRUBQQz6Wfc0?= =?iso-8859-1?Q?br9tUJXz9F2s2mUXvB/kyn4DrFOCIkeom58+knlxBbX5TN89dXrwLspTWd?= =?iso-8859-1?Q?v1E1/Za0fjHyacyLzf7/njWWAiOxmFcOAilt0EWsv0Em7mfXnyUj9r7rcz?= =?iso-8859-1?Q?8lunMEfuoOCoW1Lpg5JM6shN21HchPAgCNwslhm4JwuGu+9YyKjhnlYQ/a?= =?iso-8859-1?Q?Sqc6al6B1nMgLXYvMqp2e3tELqhEsBAOPvp0eoPFYn3PU4eIMfPO7u5yRf?= =?iso-8859-1?Q?0YLvimY5SWDCSUAeqr3saEsqjHeaKUWOiOrG79sAtnp9s6quil7FMoRfYi?= =?iso-8859-1?Q?78V805S82yOAQQYKprOGpKHTw+pBRr+tSvYmWir7IKOhsyz5NzkcJ/mG04?= =?iso-8859-1?Q?BhCmQ0mawm8AM9yAqk+Vg6mpc96lMma/BwYaEmNtvzpSJkbDv97H+6/1ck?= =?iso-8859-1?Q?XrVJottowGt8BEpRS6TEoovSrqD1jvo8GgFtw9RXCbFY576XJSB1vWBM98?= =?iso-8859-1?Q?mPzaZ09KarU44BxlC8T3HsIR6UgivrKWxXs0J8wFoJrqiBjFPCsfiJ3HKG?= =?iso-8859-1?Q?4sTyuTLTcSySeBm0Bg2ut3vmtxaxUEqPtR6CXK/qLyu6H30quAIxtaVr+V?= =?iso-8859-1?Q?A/pN6+7carph0iPC+FYcEQtC0YJZqWFPGmRoAUYbWXf9i9ost004eTfKlX?= =?iso-8859-1?Q?dm3uuDuHRNGHA9juZ+P9bnj7YRXm3wM2x+oLrZLlHjOCNZSxfH2Robaeh7?= =?iso-8859-1?Q?qlcKZEDNnz4XF53+RwSI4ETMh9SOHhXl6WpQgr5nbIKTaCfI8daBfxCy4S?= =?iso-8859-1?Q?U8s4xUtQAFEETivDUTGK6tWiqGdAOX+woGUEj/WptHCtO7klk4rgYOP1WJ?= =?iso-8859-1?Q?Myp34aYC8ENIdZlQrg41zHGeDtDk7qgAeNZm/k6MOiTo64kCZZ5+I3X0u4?= =?iso-8859-1?Q?1v6YclFUEkuMdFM1TZFLmHb2CsvPK57M6lVfDINBSRZP+5w=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR11MB5416.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6160679-646e-403a-4686-08d91ee6b3aa X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2021 19:04:05.3326 (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: jvV2yBg2dr8zmyJq19Lvnpn/Un9E5EjId63EGoETLY5aHoPzHZXTWwqHx0Q7Sj46ym/LTPeNzpnSaJHo3eUs0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4176 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 19:04:26 -0000 Thanks for following up with the comments. Please, check inline -J -----Original Message----- From: Benjamin Kaduk =20 Sent: Friday, May 21, 2021 11:39 PM To: Juan Alcaide (jalcaide) Cc: The IESG ; draft-ietf-idr-bgp-flowspec-oid@ietf.org; idr= -chairs@ietf.org; idr@ietf.org; Susan Hares ; aretana.ietf= @gmail.com Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-flowspec-o= id-14: (with COMMENT) Hi Juan, On Tue, May 18, 2021 at 12:49:56AM +0000, Juan Alcaide (jalcaide) wrote: > Thanks Bejamin for all your comments. I'll incorporate them in the draft. > I have however concerns about some specific observations of yours. Namely= : >=20 >=20 >=20 >=20 > About your toplevel comment, I'm not sure if I understand. Both route=20 > controllers and other routers are considered in this document equally=20 > trusted. They are just BGP speakers propagating Flow Specifications=20 > alltoguether. So it doesn't matter which one is more trusted. The overall= trust is always the trust of the weakest link. We tried to add some securi= ty considerations for when an iBGP peer is not trusted for FS. Also note th= at if we don't trust iBGP peers, even with just unicast, the security of th= e network is highly diminished. It's nothing specific to FS. I recognize that it's a common scenario for all BGP speakers in the AS/conf= ederation to be treated as equally trusted. I don't think it's the only po= ssible configuration, though, and I'm pretty sure I have heard of setups th= at give the controller a "first among equals" treatment. My remark here is coming from the bedrock security principle of "least priv= ilege", where we grant just the entities that need it just enough authority= to do what needs to be done. They don't get more authority, and other par= ties don't get authority they don't need. Applied to this document, we're = granting new authority to originate flowspecs without originating the best = route. This is pretty small new privilege, since the other routers can alw= ays originate flowspec if they also originate the best route, and there's b= asically nothing to stop them from doing that. But in some scenarios it can have a leveraged impact, so my proposal is tha= t we allow for implementations/deployments to be able to apply the principl= e of least privilege if it makes sense for them. I am not trying to impede= anyone else from using this document in a way where all the BGP speakers a= re equally trusted. [JUAN]: So your proposal would be for only allowing the route-controller to= originate the Flow Specification? That would be an interesting security i= mprovement, but perhaps it should apply to more address-families than FS. I= t might require more work than just modifying FS validations rules, so I th= ink it's out of scope. >=20 > " > Would there ever be cause to have a knob that allows this condition=20 > only for the empty AS_PATH (and denies this condition when AS_CONFED_SEQ= UENCE is present)? From skimming RFC 5065 I mostly assume not, but have to= ask... > " >=20 > I guess you mean if it's possible that an AS_PATH with just=20 > AS_CONFED_SEQUENCE is not automatically validated (and we have to=20 > still validate with unicast paths). As long as all the peers belonging to= the confederations of ASes are trusted, there is no need to validate with = unicast paths and better not to do this because then the congruent topologi= es assumption described later would fail. > I guess it's conceivable that a confederation of ASes is formed by=20 > subAS not trusted between each other (perhaps during some weird AS adquis= itions?) and you may need a knob. But I'd think this is out of scope. IT's = a bit related to the other paragraph you are having rpboelms with "Using th= e new rule ...". > I'll remove it because it's confusing while discussing just an uncommon c= onfiguration. I don't think you should take my comment as a suggestion to remove the AS_C= ONFED_SEQUENCE case, my apologies if I gave that impression. Part of my jo= b as a security reviewer is to look for edge cases, and this is one that I = had to ask for more data about before I was confident enough to dismiss it = as irrelevant. [JUAN]: Great. Hope it's clear now. >=20 >=20 >=20 > " > This document updates the route feasibility validation procedures for > Flow Specifications learned from iBGP peers and through route > servers. This change is in line with the procedures described in > [RFC8955] and, thus, the security characteristics equivalent to the > existing security properties of BGP unicast routing are maintained. > " >=20 > I think this is explained later. We are assuming iBGP peers as trusted=20 > as a first assumption, but later we explained that if that assumption=20 > is broken, then we actually are introducing a new security risk. I=20 > thought it was clear that way. That's the paragraph you want to=20 > remove, so I am not sure how you want to say both things: equally secure= in the common case where iBGP peers are secure, less secure if iBGP peers = are not secure. I wasn't saying we should remove this text! I just wanted to add a word, s= o that we have security characteristics "roughly equivalent" or "essentiall= y equivalent" to the existing security properties. [JUAN]: Sorry, I was referring to the paragraph that you didn't understand = starting with=20 " Using the new rule to validate a Flow Specification route received from an External Border Gateway Protocol (eBGP) peer belonging to the same local domain (in the case of a confederation) is out of the scope of this document." It's not actually the one you wanted to remove, but the one we discussed in= another thread about removing and we compromised to reword it.=20 Instead of 'roughly/essentially', what about using the last rewrite suggest= ed in the comments The security considerations discussed in ap= ply to this specification as well. <<=3D=3D=3D I'd like to move this paragraph to = the beginning of the 'Security Considerations> This document updates the route feasibility validation procedures for F= low Specifications learned from iBGP peers and through route servers. This change is in line with the procedures described in and, = thus, security characteristics remain essentially equivalent to the existing security = properties of BGP unicast routing, except as detailed below. <<=3D=3D=3D After 'except'= we list the caveats. >=20 > " > route servers may suppose an operational challenge. If the condition > of the peer is unknown, the rule SHOULD not be enforced. > " >=20 > For several other comments, the agreement/compromise was to rewrite it=20 > as follows >=20 > "This risk > is impossible to prevent if the Flow Specification route is received > from a route server peer. > If configuration (or other means beyond the scope of this document)=20 > indicates that the peer is not a route server, that optional rule=20 > SHOULD be enforced. If the indication is that the peer is not a route ser= ver or there is no conclusive indication, that optional rule SHOULD NOT be = enforced. > " This is probably tolerable. (I prefer to have "no conclusive indication" imply "SHOULD enforce the rule" but expect few others to agree.) I was hope= ful that we could use a phrasing that is not specific to just "a route serv= er peer" and instead talked about a peer that is trusted in a specific way,= since that seems to me to be the most important part. Many of the phrasin= gs that I can come up with are pretty long and banal, so I won't suggest th= em. The most promising one I've come up with (which is a relative term onl= y) involves introducing a new logical capability, the ability to advertise = flowspecs without the best route, and then talking about peers that are tru= sted with that capability. It would still be pretty long, though. [JUAN]: Not sure what is your logic.. When you don't know if the peer is a= route-server or a non-route-server, then you **SHOULD NOT** enforce the ru= le. If you enforce the rule and it happens to be a non-route-server, then e= verything is ok. If it happens to be a route-server, then that peering brea= ks.=20 Not sure what you mean 'flowspec without the best route', but I think it's = orthogonal to the recommendation here. We still may modify a bit this paragraph because of some other comments. I'= ll cc you if so. >=20 > I think [RFC9747] describes the behavior of route-servers, and it's=20 > important to 'design' the rules mentioned in this draft. You could say=20 > the same about [RFC5065] for instance >=20 >=20 > I'd like to use eBGP/iBGP as in [RFC8955]. There are other=20 > discrepancies (left-most vs leftmost , ..) using inconsistently on differ= ent rfc. But unlike there is opposition, I'd like to follow the same style = in [RFC8955] for anything where there is doubt. Okay. >=20 > " > Flow Specifications originated in a different local domain sill > need a congruent topology. The reason is that the second > condition (b.2) evaluates to false and only the first condition > (b.1) is evaluated. > " >=20 > We plan to clarify by defining the exact meaning of "Local Domain" I saw the thread with John, it looks good :) Thanks, Ben >=20 >=20 >=20 >=20 > -----Original Message----- > From: Benjamin Kaduk via Datatracker > Sent: Friday, May 14, 2021 9:44 PM > To: The IESG > Cc: draft-ietf-idr-bgp-flowspec-oid@ietf.org; idr-chairs@ietf.org;=20 > idr@ietf.org; Susan Hares ; aretana.ietf@gmail.com;=20 > shares@ndzh.com > Subject: Benjamin Kaduk's No Objection on=20 > draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-idr-bgp-flowspec-oid-14: No Objection >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > John had some good editorial comments; thank you to him for spotting them= , and to the authors for pulling in the fixes. >=20 > It seems to me that the revision to the validation procedures that we des= cribe here may be broader than needed to satisfy the stated use case, and t= hat such broadness has a corresponding weakening of the security properties= of the system as a whole. My understanding is that when central controlle= rs or route-reflectors are used, they tend to be in some sense "more truste= d" than peer routers in the domain (and, correspondingly, more tightly secu= red). So it seems like the system as a whole would be less fragile/more se= cure if "off-path" flow specs were allowed only from the trusted source, ve= rsus from any peer in the same AS [confederation]. Is there a reason why s= uch a procedure is infeasible? (It seems like all peers in the AS could be= marked as "trusted" in this way, if appropriate, which allows for recoveri= ng the current semantics of this draft if needed.) This is, in essence, th= e same topic raised by the secdir reviewer and relates to "fail-closed" vs = "fail-open". I think it gives a clearer picture on what the safe and recom= mended behavior is, if we say to only accept these routes from "trusted pee= rs in the local domain" (but allow all peers in the local domain to be trus= ted if appropriate) than to say to always accept these routes from peers in= the local domain and optionally do strict enforcement if we know that the = peer advertising the route is not a route server. >=20 > Abstract >=20 > This document describes a modification to the validation procedure > defined for the dissemination of BGP Flow Specifications. The > dissemination of BGP Flow Specifications requires that the originator > of the Flow Specification matches the originator of the best-match > unicast route for the destination prefix embedded in the Flow > Specification. [...] >=20 > I'd suggest adding a couple words about "prior to this document requires"= or "as specified in RFC 8955 requires", since that's exactly what we're ch= anging with this document. >=20 > However, the validation procedure will fail in this > scenario. [...] >=20 > Similarly, this could also say "the RFC 8955 validation procedure". >=20 > Section 4.1 >=20 > 2. The AS_PATH attribute of the Flow Specification is empty or > contains only an AS_CONFED_SEQUENCE segment [RFC5065]. >=20 > Would there ever be cause to have a knob that allows this condition only = for the empty AS_PATH (and denies this condition when AS_CONFED_SEQUENCE is= present)? From skimming RFC 5065 I mostly assume not, but have to ask... >=20 > Section 4.2 >=20 > For clarity, the AS in the left-most position of the AS_PATH means > the AS that was last added to the AS_SEQUENCE. >=20 > Thank you for including this; it is a big help for readability. >=20 > Using the new rule to validate a Flow Specification route received > from an External Border Gateway Protocol (eBGP) peer belonging to > the same local domain (in the case of a confederation) is out of > the scope of this document. Note that although it's possible, its > utility is dubious. Although it is conceivable that a router in > the same local domain (both iBGP and eBGP within the same local > domain) could send a rogue update, only eBGP (outside the local > domain) risk is considered within this document (in the same > spirit of the mentioned beforehand AS_PATH validation in > [RFC4271]). >=20 > I'm having (I think) the same trouble John did reading this paragraph. > I'll watch his ballot thread and chime in there if needed; no need to spe= cifically reply here. >=20 > Section 7 >=20 > We could mention again (per =A73) that having this mechanism allows centr= al SOC or controller systems to be able to propagate flowspecs more readily= during attacks and improves the stability/security of the network. >=20 > This document updates the route feasibility validation procedures for > Flow Specifications learned from iBGP peers and through route > servers. This change is in line with the procedures described in > [RFC8955] and, thus, the security characteristics equivalent to the > existing security properties of BGP unicast routing are maintained. >=20 > I would argue that the security characteristics are not (strictly) "equiv= alent", but only "roughly equivalent". With the new procedures, a maliciou= s or compromised node in the local AS can (e.g.) cause traffic to be discar= ded without steering that traffic to/through itself. There are plenty of o= ther ways that such a malicious node can cause harm, not least announcing t= hat prefix and dropping the traffic as it passes through, so the overall pr= operties of the system are roughly equivalent, but there are clear differen= ces of the particulars. >=20 > route servers may suppose an operational challenge. If the condition > of the peer is unknown, the rule SHOULD not be enforced. >=20 > In light of my top-level comment (and the secdir review), I'm uncomfortab= le with a SHOULD-level "fail-open" behavior. Could the default behavior wh= en the condition of the peer is unkonwn be subject to a configuration knob? >=20 > BGP updates learned from iBGP peers are considered trusted, so the > Traffic Flow Specifications contained in BGP updates are also > considered trusted. Therefore, it is not required to validate that > the originator of an intra-domain Traffic Flow Specification matches > the originator of the best-match unicast route for the destination > prefix embedded in that Flow Specification. Note that this > trustworthy consideration is not absolute and the new possibility > than an iBGP speaker could send a rogue Flow Specification is > introduced. >=20 > Also in light of my toplevel comment, it's not clear that this paragraph = adds much value. Specifically, as we note in the last sentence, the level = of trust in a route server is not (in the general case) the same level of t= rust in a generic peer in the iBGP domain, even if both peers are trusted i= n a general sense. So it seems that the core sentiment here is that when w= e get the flowspec from a trusted source, it's trusted, and we don't need t= o be as strict about validating that it's the same source that we would sen= d the traffic to in the absence of a flowspec. >=20 > Section 9.1 >=20 > It seems that RFC 7947 is reference in only one location, and not in a ma= nner that strongly implies a normative relationship. >=20 > NITS >=20 > Abstract >=20 > For an iBGP received route, the originator is >=20 > "IBGP" (with that capitalization) appears on the RFC Editor's list at htt= ps://www.rfc-editor.org/materials/abbrev.expansion.txt but is not marked as= "well-known". So we should probably use the expanded version in the abstr= act and define it on first use in the body. >=20 > Section 2 >=20 > the same forwarding path as the dest-route. For the case where AS1 > has thousands of ASBRs, it becomes impractical to originate different > Flow Specification rules on each ASBR in AS1 based on which ASBR each > dest-route is learned from. The objective is to advertise all the > Flow Specifications from the same route-controller. >=20 > "it becomes impractical" does not flow directly to "the objective is"; I'= d put some transition phrase in, like "to make the situation more tenable". >=20 > Section 3 >=20 > can direct border routers within their AS with specific attack > mitigation actions (drop the traffic, forward to a clean-pipe center, > etc.). >=20 > Maybe "clean-pipe center" is a term of art I'm not familiar with, but the= natural reading would be that a clean pipe is something that is the output= of a scrubbing center, and that pipe-cleaning is the operation performed t= here. This would suggest rewording to something like "forward to a scrubbi= ng center", "forward to a pipe-cleaning location", etc. >=20 > In addition, an operator may extend the requirements above for a > group of ASes via policy. This is described in section (b.2.3) of > the validation procedure. >=20 > I suggest a forward reference ("below" or "in Section 4.1") to contrast t= o the RFC 8955 procedure. >=20 > Section 5 >=20 > If the latter applies, a network should be designed so > it has a congruent topology amongst unicast routes and Flow > Specification routes. [...] >=20 > This "should" does not give any indication of why the network should=20 > be designed in this manner (e.g., that failing to do so would result=20 > in > (b.1) failing). >=20 > Flow Specifications originated in a different local domain sill > need a congruent topology. The reason is that the second > condition (b.2) evaluates to false and only the first condition > (b.1) is evaluated. >=20 > I suggest s/different local domain/different domain/ -- my first reading = of "different local domain" was "a different AS but the same confederation"= , and only by contrasting this statement to the previous paragraph did I re= alize the intended meaning. > Alternately (or additionally?), this could be clarified by noting that th= is scenario will result in an AS_PATH that contains non-AS_CONFED_SEQUENCE = segments. >=20 >=20 >=20