Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT)

"Juan Alcaide (jalcaide)" <jalcaide@cisco.com> Tue, 18 May 2021 00:50 UTC

Return-Path: <jalcaide@cisco.com>
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 F35743A160A; Mon, 17 May 2021 17:50:06 -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=MCD76tJO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UW226oZF
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 cLIJpsq-l-6U; Mon, 17 May 2021 17:50:01 -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 631A93A1603; Mon, 17 May 2021 17:50:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19506; q=dns/txt; s=iport; t=1621299001; x=1622508601; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yT9p6XgfYk/9ywH4dontXy3a7o4gChpg+7P8hj84i6Q=; b=MCD76tJO8DOC5JHUc55pkNAktJ0C/1nzUyI79/WfQ8JFVGvjSkaCUP4A TAAeOUorofOjAzb8d2Q75iWVFtPEpK/DIss1t/ghez6M7V4tZXeG/0+/X 4/5VonOIMiHcRB0BXLI15J/eFYgvnu+/2gpDH4wUC4PWpkOAyVHQ8ruK+ k=;
X-IPAS-Result: =?us-ascii?q?A0AHAABCDqNgmIwNJK1aDgwBAQEBAQEBAQEBAwEBAQESA?= =?us-ascii?q?QEBAQICAQEBAUCBRQMBAQEBCwGBUiMufloSJDELhDyDSAOFOYh0A4ENiTGFA?= =?us-ascii?q?4omgS4UgREDVAsBAQENAQE1CgIEAQGETwIXgV0CJTYHDgIEAQEBAQMCAwEBA?= =?us-ascii?q?QEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFUA2GRAEBAQQjEQwBATAHAQsEAgEIE?= =?us-ascii?q?QQBAQMCJgICAh8RFQgIAgQBDQUIgmkBglUDLwEDC54OAoofeoEygQGCBgEBB?= =?us-ascii?q?gQEgUhBgw8NC4ITAwaBECoBgnqEDoJjgU57gS4nHIFJRIEVQ4FfSjY+gh9CA?= =?us-ascii?q?gECgSgBEgEJGoMVNoItgWotLQIEDy8bCwQiDQwIDgJQLxIHKgggEgUCAQ4MC?= =?us-ascii?q?AEEBhwBkRuCdwFCpixbCoMWigKGUocqBIVaEYNaixOLAYtPlTaCFolwgyKPa?= =?us-ascii?q?gSEbAICAgIEBQIOAQEGgVsCL2tYEQdwFTuCaVAXAg6OHwwNCRWDOYUUhQRFc?= =?us-ascii?q?wIBNQIGAQkBAQMJfIlPLYEHAYEQAQE?=
IronPort-PHdr: A9a23:G+D/Yh8rGfX+jP9uWDvoyV9kXcBvk7D1IkgY5od0w75Nc6H2+ZPkM QSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAAhkCj8hFmg08RsOJFB6zIPvjdSdvG sNEWRds9G26Nk4AHsH4ahXSr3S+4CRUFA/4MF9+J//+HcjZiMHkv90=
IronPort-HdrOrdr: A9a23:nmcvVqrlUbBJVg6i0Marl1oaV5v+L9V00zEX/kB9WHVpm5Oj9v xGzc506farslkssSkb6K+90KnpewK6yXcH2/huAV7EZnimhILIFvAt0WKG+V3d8kLFh5VgPM tbAs1D4ZjLfCRHZKXBkUmF+rQbsaO6GcmT7I+0pRoAPGIaCZ2IrT0JdzpzeXcGIjWucKBJbK Z0kfA33gZIF05nCviTNz0gZazuttfLnJXpbVotHBg88jSDijuu9frTDwWY9g12aUIN/Z4StU z+1yDp7KSqtP+2jjXG0XXI0phQkNz9jvNeGc23jNQPIDmEsHfrWG0hYczGgNkGmpDp1L8Yqq iLn/7mBbUr15rlRBDwnfIq4Xi57N9h0Q649bbSuwqTnSWwfkNLNyMGv/MCTvMcgHBQ4O2VF8 lwrj+kXtNsfGD9tTW46N7SWx5wkE2o5XIkjO4IlnRaFZATcblLsOUkjQ5o+bo7bWnHAbocYa NT5QDnlYBrmFihHjzkV6lUsZSRt1EIb1i7q2Q5y7ioOglt7TlEJhEjtbkid187heUAord/lp b5Dpg=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,307,1613433600"; d="scan'208";a="720571614"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 May 2021 00:49:59 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 14I0nxm6002568 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 18 May 2021 00:49:59 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 17 May 2021 19:49:59 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 17 May 2021 20:49:58 -0400
Received: from NAM02-SN1-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.18 via Frontend Transport; Mon, 17 May 2021 20:49:58 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lhfk+NKWce7/aM37sq9+ek00IR1N2Z4OKdD3yHQEzW3w2j1P5XVaNiNSxNTVQvKzXrm0da+qtFLlnhKnBu2WET+2vqVStWnJEqmbFablhBQd5o4IhAmlGdJF3cLWihk5HuXAkl21CSvDjCaRormbkvNM+TiJynBgSJbqvGzmDBRDRlhZ5hGlVioAP6WfpJDer9ZqRx1rX6e5glYCIKl33KI+rUnrzbmM4k+dR8c9HFhIE/Bq46aCbWatvVVTmkpL3ZW2Bn2/Xa2P3AsWQ/zySpxn+5FCGdgcADYtVPsz7cvDbPsCLNj5fhCG6TPYRcVznMFtqlDdaADGBfc2hDMkQw==
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=yT9p6XgfYk/9ywH4dontXy3a7o4gChpg+7P8hj84i6Q=; b=jE2ONWLGM5tPTOrtY90ZPAGcVsk/ucm8IMmxuZG/c8WQp+KrQ1V9nlhXw6txMs5FgC8eHROY1Zh+1Mpe7I3DYJJAtpaMQzT3MPowxwmT1chhoUW3cVAmyNFomq2HBJwTfHYbDrClP4JWB0dpUyYtq2SQCEqc3iM8IEKhlGe0LcmIqGVM0JmFBQYztG5NscLVaLAan2V/4DFPv7BfKYYdnF7zLIENtcYlO0SxiWTy9PbVl56CN48C2AB+Xg6T7KYWzrYd8f1ifJpjrTIzqlhYAxyKPZfGbrdlCWlwsQpui6aZeznPWgpiGvaG6TkI9kxDUdgtZQKOaIrPOvd+n/Mh8g==
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=yT9p6XgfYk/9ywH4dontXy3a7o4gChpg+7P8hj84i6Q=; b=UW226oZFEBdzOyJQHnJ1n50GPyCwNXr7z0eVfOXWCB0frqal5LuZI6CbKhmaevwde/yi84/+0s6a3Y9DQjfUOJijkx8KR58osPAKrAZtrMNoQQHtDTGQXme4WGnG9AYcJ39iGdomDTfVP0mzxa1it3Mz193Q6MJPF8B3ejbqBGI=
Received: from BL1PR11MB5416.namprd11.prod.outlook.com (2603:10b6:208:319::22) by MN2PR11MB4253.namprd11.prod.outlook.com (2603:10b6:208:18d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.28; Tue, 18 May 2021 00:49:56 +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.4129.031; Tue, 18 May 2021 00:49:56 +0000
From: "Juan Alcaide (jalcaide)" <jalcaide@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-idr-bgp-flowspec-oid@ietf.org" <draft-ietf-idr-bgp-flowspec-oid@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT)
Thread-Index: AQHXSPmSxnaQG1WzEEi7zxQAb51JkarobSew
Date: Tue, 18 May 2021 00:49:56 +0000
Message-ID: <BL1PR11MB5416E108FB35105DFDB020E0CD2C9@BL1PR11MB5416.namprd11.prod.outlook.com>
References: <162102145453.12250.16239592060339839431@ietfa.amsl.com>
In-Reply-To: <162102145453.12250.16239592060339839431@ietfa.amsl.com>
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.38.90.229]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8932fdcf-033c-4f13-725d-08d91996db55
x-ms-traffictypediagnostic: MN2PR11MB4253:
x-microsoft-antispam-prvs: <MN2PR11MB42535043F2171BD6A7CC3C35CD2C9@MN2PR11MB4253.namprd11.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: QsgBqzYx2gt/sfTJsN52SLublZ69IGfRBqbdyg7LIJqpARzoISr3BUS8fcVqT9dG7l9ZmWLsYErI1W5IRrDrMZu+R25+jhGYJFm0Cy4WA3ytcy3+FMb5wXGs3utj14hLzFZjtCLGebRwRI6363cb0PvVC7vx4yXdDy3oBeMy6rrNtb8Ci7IKZt1yHFPqU8LR87yRE2oVm+sRY1pDzMFU93K0KL1eDBLZ86vIcwQFKhTi4nqKRyp+5FFi+xcLqwQLM2H0v8BWJqRE8Pt4ELvgoaBzQtEVFhaZIm/UJIxTP8CNg1Fzb6cYBIVZELsHNHPU6lyJJUbCsW8g8vXCRolGpB8H9bm0/SZeZIbQoP0kzYh7K7IzYbIWh0ilKAqh14kZMy4NE1NLGBekQ15nUFLUQhp9hnflKMItSu6gpYtmg9PfbMP9xVQZ+xcZC2cwCPWpeO+8CeuGDSsBERT6C5PaDr/5cMrFvQslCcqmQXzH3lQT6R+0kzLaMvoMHhH+SZuflRqiONiB6UcaCCGGNi++n3EhoCg4Qfp7zoknOBSdt85Mdw4K+LUUjDfzkuecYbYTs2QC5kNCo0fEpGMolYPQr5ejRiHyxSM2rt9G3yu+oKUjQj2BfI/7PPk88JaPY2vIkDARCBuDsVJ+GWIqenQjDmo8QcFB22YD19+bU3Ih2JhnCzBovIxeKP6eCUqkCU2xaWOHUvafKJCWQRNM/thtXvd9mJwHQQ8nnHSbONnap/g=
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:(396003)(346002)(366004)(39860400002)(136003)(376002)(66476007)(66446008)(66556008)(966005)(122000001)(86362001)(76116006)(66574015)(33656002)(52536014)(53546011)(83380400001)(66946007)(478600001)(30864003)(71200400001)(316002)(9686003)(7696005)(38100700002)(5660300002)(26005)(2906002)(4326008)(186003)(8676002)(64756008)(55016002)(8936002)(6506007)(110136005)(54906003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?OXlWdmNIY3hrK1dIWURkZE5VMmg0bzJvcXV6K1pmV2RhM3FkejNXbVlTNk9Y?= =?utf-8?B?UG4ySjRReU0yVENPMDdYdjE1ci9nM2xzZnpSSWpzazdoOFRIQVVwMXhBb0Yr?= =?utf-8?B?Zll5aGhKRFppSkhZYzlVVjJpa3FuSzFVeVBJcllRWk1lSlg4YVFEdnFzSm55?= =?utf-8?B?eFY0d3UxTTQ3dHhTd2lLRWg1L1o1QStUUVRFMEZIUVRzalhOTFN6dDJ6WWYx?= =?utf-8?B?UTdxNFN1NlFmZytqUkpUU3VXYkkwVGIyL25VSUhCQk4vZ2ZGQzRJMk1XckRV?= =?utf-8?B?VEtXQ0Z3dGpiRDZPQm8vTS9QKy9pZ2dKamlTZEx4Sko4eEkxblA3QUhvTWN4?= =?utf-8?B?NUNDd1ZWOHdIVllnNlRjTHBaL0NYSHZGOVBSMUwrMFQvZUgvdmtZN2JaVlht?= =?utf-8?B?Q0ZGY1FpaCtxR2ZWMnZQSmo4VkVBNjU5WkVSQkw4TzVwNnZ3UFhRNjdzd1Vo?= =?utf-8?B?QXRnaUlVWDZWYUVrOVMwQXdyNGU5MTBiNWdoQUx1U1hEVXpDQWJ6WTlvQlhX?= =?utf-8?B?cGNkcTdPY3Q5UmQ3OTBEbFhRSnpSK2dHZ09jM21WeDFMZHhJd1JCVmpKWW9i?= =?utf-8?B?UkE0SERwVmFGTXB6TUxPdWhuTFVaWFpPalAyU2ZtSHp1NlFlT1RLMHhWTmZM?= =?utf-8?B?dWVOMmEyak5pcDBxT1JBK2FQYktjMW1zWFJLY2hnVmU5dFBkb1pEcG82cEtR?= =?utf-8?B?QUdaUVdOdjZCYkk5YkdCUWVtb1F0TEUxQzkzSUZZeEFLcFhyNVJXSTAycDMw?= =?utf-8?B?dWhzUDlFOW83T1ZScWExWFVQeCtuVzYxNFBMdEVQYXg1MVZ6RzdmdXBJWEJw?= =?utf-8?B?c1MzUXRDdTRQMVBnNzJ4eDFyR05IMEc1by9QRllVQmNOcUJCeUtzTktxc2dO?= =?utf-8?B?dGliQ2haMm81OUZBRHJkcGRMbVFjYVduMmdJK1pLSG05NEVwdldxNHdydDFK?= =?utf-8?B?cElzQ2VrVW5TcGs5RDlwMDdXd2V3K01TNDY2bjZQTXZDaGppNG9BQ25ZMVRL?= =?utf-8?B?eW5wcDJwVXUwalRzaDFJMm5vb2FUbU1RSnZEMUFGTkxPV0VMRC9uRXcyOWg4?= =?utf-8?B?TVJkTm05MkJmK3VVc2kyQjBHOEhJUVlZUEpyOVVxdEY1YnV5cktyR3B2dFcz?= =?utf-8?B?aldXYkZIVjVPSDBJWTh5eDBUUDVoNjM4UnIvekp1djIvZFBGZ0pnT1h3Tnho?= =?utf-8?B?M0JMcTBlb2k5N0FyZEZ5cXFPUm5VYnB6S1I3V2l6dVh5QTdlUzZSS3lmTHdq?= =?utf-8?B?TXFaU0R6M0hWMTZxdmNIZ0JhUUdTK1pMVlQ5VzVwSi9FWWR4TEdEeWxvSkt5?= =?utf-8?B?RFJ1bEhWSWxmS3VOd0hlWW5aQTBZRG81WVdrR2h5TTZVaHlnbmM2NFNzcWJq?= =?utf-8?B?NmlBMzJJQ2dIaEdOSGRyWG54Z01WcDJMY2tsR2pXelBZYjVNWGU1aEdVL0RV?= =?utf-8?B?aXMxWmdabEg0Tkg0NnlvejFzL2U0WWI1UndUMUJhaHh3eU9VOVd2UlV0bXNQ?= =?utf-8?B?bkdKYXFYTnZ1bXNqOStCZ3VBTzBvbWw5bjdOMWFsU3JRdDJhZ3dPMTRtL2th?= =?utf-8?B?bmRBRUUxSVZ2M0tmYVdBOVg3Z3FxcDNnd3hMd0lwQnhpaHhWcnpxcTNVU0ZW?= =?utf-8?B?c2RmYkVROWpyWmw1c1ZIdGQyc0t2QUhxcXpIRHpzeWRScEdtYlUzZnlSbEJ6?= =?utf-8?B?Nk5kWmFLVm1Tdi80MHlNVGZYNThFRVk3cWxCamZsWDhFa2p6TTYyZTdlTHRy?= =?utf-8?Q?aHabR7MT9QHugr4KSU=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 8932fdcf-033c-4f13-725d-08d91996db55
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2021 00:49:56.4677 (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: CjpL0jWkbQZmG80mvPMVqCgXOpDzp+NFaUZLeKe4IC1HlcVH5n/cD3pfDZEbh3bK5jvLH0HJnmFKMNiuUy8r/w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4253
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TY3OQlutdnTJ-ZZcejvb6MctDV0>
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 <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2021 00:50:07 -0000

Thanks Bejamin for all your comments. I'll incorporate them in the draft.
I have however concerns about some specific observations of yours. Namely:




About your toplevel comment, I'm not sure if I understand. Both route controllers and other routers are considered in this document equally trusted. They are
just BGP speakers propagating Flow Specifications 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 security considerations for when an iBGP peer is not trusted for FS. Also note that if we don't trust iBGP peers, even
with just unicast, the security of the network is highly diminished. It's nothing specific to FS.


"
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...
"

I guess you mean if it's possible that an AS_PATH with just AS_CONFED_SEQUENCE is not automatically validated (and we have to 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 topologies assumption described later would fail.
I guess it's conceivable that a confederation of ASes is formed by subAS not trusted between each other (perhaps during some weird AS adquisitions?)
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 the new rule ...".
I'll remove it because it's confusing while discussing just an uncommon configuration.




"
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.
"

I think this is explained later. We are assuming iBGP peers as trusted as a first assumption,
but later we explained that if that assumption is broken, then we actually are introducing 
a new security risk. I thought it was clear that way. That's the paragraph you want to 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.


"
   route servers may suppose an operational challenge.  If the condition
   of the peer is unknown, the rule SHOULD not be enforced.
"

For several other comments, the agreement/compromise was to rewrite it as follows

"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) 
indicates that the peer is not a route server, that optional rule 
SHOULD be enforced. If the indication is that the peer is not a route server or there is no conclusive indication, that optional rule SHOULD NOT be enforced.
"


 I think [RFC9747] describes the behavior of route-servers, and it's important to 'design' the rules mentioned in this draft. You could say the same about [RFC5065] for instance


I'd like to use eBGP/iBGP as in [RFC8955]. There are other discrepancies (left-most vs leftmost , ..) using inconsistently on different rfc. But unlike there is opposition, I'd like
to follow the same style in [RFC8955] for anything where there is doubt.


"
      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.
"

We plan to clarify by defining the exact meaning of "Local Domain"

-J




-----Original Message-----
From: Benjamin Kaduk via Datatracker <noreply@ietf.org> 
Sent: Friday, May 14, 2021 9:44 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-idr-bgp-flowspec-oid@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Susan Hares <shares@ndzh.com>om>; aretana.ietf@gmail.com; shares@ndzh.com
Subject: Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-bgp-flowspec-oid-14: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

John had some good editorial comments; thank you to him for spotting them, and to the authors for pulling in the fixes.

It seems to me that the revision to the validation procedures that we describe here may be broader than needed to satisfy the stated use case, and that such broadness has a corresponding weakening of the security properties of the system as a whole.  My understanding is that when central controllers or route-reflectors are used, they tend to be in some sense "more trusted" than peer routers in the domain (and, correspondingly, more tightly secured).  So it seems like the system as a whole would be less fragile/more secure if "off-path" flow specs were allowed only from the trusted source, versus from any peer in the same AS [confederation].  Is there a reason why such 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 recovering the current semantics of this draft if needed.)  This is, in essence, the 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 recommended behavior is, if we say to only accept these routes from "trusted peers in the local domain" (but allow all peers in the local domain to be trusted 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.

Abstract

   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.  [...]

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 changing with this document.

                However, the validation procedure will fail in this
   scenario.  [...]

Similarly, this could also say "the RFC 8955 validation procedure".

Section 4.1

      2.  The AS_PATH attribute of the Flow Specification is empty or
          contains only an AS_CONFED_SEQUENCE segment [RFC5065].

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...

Section 4.2

      For clarity, the AS in the left-most position of the AS_PATH means
      the AS that was last added to the AS_SEQUENCE.

Thank you for including this; it is a big help for readability.

      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]).

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 specifically reply here.

Section 7

We could mention again (per §3) that having this mechanism allows central SOC or controller systems to be able to propagate flowspecs more readily during attacks and improves the stability/security of the network.

   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.

I would argue that the security characteristics are not (strictly) "equivalent", but only "roughly equivalent".  With the new procedures, a malicious or compromised node in the local AS can (e.g.) cause traffic to be discarded without steering that traffic to/through itself.  There are plenty of other ways that such a malicious node can cause harm, not least announcing that prefix and dropping the traffic as it passes through, so the overall properties of the system are roughly equivalent, but there are clear differences of the particulars.

   route servers may suppose an operational challenge.  If the condition
   of the peer is unknown, the rule SHOULD not be enforced.

In light of my top-level comment (and the secdir review), I'm uncomfortable with a SHOULD-level "fail-open" behavior.  Could the default behavior when the condition of the peer is unkonwn be subject to a configuration knob?

   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.

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 trust in a generic peer in the iBGP domain, even if both peers are trusted in a general sense.  So it seems that the core sentiment here is that when we get the flowspec from a trusted source, it's trusted, and we don't need to be as strict about validating that it's the same source that we would send the traffic to in the absence of a flowspec.

Section 9.1

It seems that RFC 7947 is reference in only one location, and not in a manner that strongly implies a normative relationship.

NITS

Abstract

                For an iBGP received route, the originator is

"IBGP" (with that capitalization) appears on the RFC Editor's list at https://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 abstract and define it on first use in the body.

Section 2

   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.

"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".

Section 3

   can direct border routers within their AS with specific attack
   mitigation actions (drop the traffic, forward to a clean-pipe center,
   etc.).

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 there.  This would suggest rewording to something like "forward to a scrubbing center", "forward to a pipe-cleaning location", etc.

   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.

I suggest a forward reference ("below" or "in Section 4.1") to contrast to the RFC 8955 procedure.

Section 5

                If the latter applies, a network should be designed so
   it has a congruent topology amongst unicast routes and Flow
   Specification routes.  [...]

This "should" does not give any indication of why the network should be designed in this manner (e.g., that failing to do so would result in
(b.1) failing).

      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.

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 realize the intended meaning.
Alternately (or additionally?), this could be clarified by noting that this scenario will result in an AS_PATH that contains non-AS_CONFED_SEQUENCE segments.