Re: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13

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

Return-Path: <jalcaide@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155053A1A74; Mon, 3 May 2021 17:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.615
X-Spam-Level:
X-Spam-Status: No, score=-9.615 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=OXpZvkzd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XhRZe9j6
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 gRYscPsp1BU3; Mon, 3 May 2021 17:17:51 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958093A1A72; Mon, 3 May 2021 17:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50468; q=dns/txt; s=iport; t=1620087471; x=1621297071; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kRLLvlvM787LIzm3IrYi0IPoJCEpw/TwtYXCd7qtKZE=; b=OXpZvkzdMnBebSulM7xe5vN/kpAhwfZDwa9TPwy45awfezxHjEwEW0ua sZQUWZIfd0Lix0QTTJBiA5V8CH9BWlR8qg04j3E4fwvkiGWPxLJtkKCKF P5VQogN7otxwoomiNADbSryzauN3Zmg8lvoMX8mp8CHTW0+UIVg56Ecs6 g=;
IronPort-PHdr: =?us-ascii?q?A9a23=3AoWB0uxS98aaoXo+4UeeThPBbStpso0/LVj590?= =?us-ascii?q?bIulq5Of6K//p/rIE3Y47B3gUTUWZnAg9pLjuPXt+brXmlTqZqCsXVXdptKW?= =?us-ascii?q?ldFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrXi77DpUE?= =?us-ascii?q?RL6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02j?= =?us-ascii?q?BDOpyggRg=3D=3D?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AtFenP60f6Y2090uhRJ55lgqjBeB2eYIsi2?= =?us-ascii?q?QD101hICF9Wvez0+izgfUW0gL1gj4NWHcm3euNIrWEXGm0z/9IyKErF/OHUB?= =?us-ascii?q?P9sGWlaLtj44zr3iH6F0TFmNJ1/ZxLN5JzANiYNzdHpO7x6gWgDpIEyN6I7K?= =?us-ascii?q?iniY7lvghQZCtBApsQiDtRIACdD0FwWU1iDZ02CJKT6qN81kSdUF4Qadm2AW?= =?us-ascii?q?RAYvjbq7Tw5dzbSDMlJzpi0gmBiju09KX3eiL54j4yWy5CqI1SilTtvBf+4s?= =?us-ascii?q?yYwpSG4z/ak1Te9pFH3Obmo+EzePCkrugwBnHShh2zZIJnMofy/QwdhO208l?= =?us-ascii?q?4lnJ3tjn4bTr5OwkjcdG20vhfhsjOIuF1FhhOSqi77vVLZrcP0Xz48AcZa7L?= =?us-ascii?q?gpDyfx0VYqv913zctwrgSknqdXFh/JkWDc4NXFRnhR5zKJiEciiuIagjhjV5?= =?us-ascii?q?IfYtZq3PUi1X5Sea1weB7S2cQCKq1DHcvc7PFZfRexdHbCpFRix9SqQzAaAg?= =?us-ascii?q?qGalJqgL3U7xFm2FRCi2cIzs0WmXkNsLgnTYNf2ujCOqN00JlTU84ta75nDu?= =?us-ascii?q?tpe7r1NkX9BTb3dE6CK1XuE68Kf1jXrYTs3bkz7Oa2PLsF0YU1g5aEdF9Dr2?= =?us-ascii?q?Y9dwbPBKS1rd922yGIZF/4cSXmy8lY6ZQ8kKb7XqDXPSqKT01rnNCnp/kZH8?= =?us-ascii?q?3HS/e+MJ9bGJbYXC/TMLcM+ze7d4hZKHEYXsFQkM08QUiyrsXCLZCvtuGzSo?= =?us-ascii?q?eVGJPdVRIfHk/vCHoKWzb+YO9a6FqwZ3P+iB/NH3fkekn1+4NsALHXltJjjr?= =?us-ascii?q?QlB8lpiEw4mF657saEJXlpqaotZnZzJ7vhj+e8vmm5/WHB6m1zIRpDBkNJ4L?= =?us-ascii?q?HtOkk64DMiAgfRS/Iuqt+fcWdd0D+sPRlkVf7bFwZZuhBq466tNoeRwiojEt?= =?us-ascii?q?qjNWqfgxIo1Su3ZqZZvpfGydbue5s+AJpjZbd4Eh/TEQdp3Sxwrn1YVQMCTk?= =?us-ascii?q?jDNz/nhKm/lqYIDOXHe9QUunbyHedk7Vbk8WSVv4UGW2YSVT/Ga7/nvS8eAx?= =?us-ascii?q?5vwmBX34BaqryagjqrIXY4m40DQS1xQVXSJqlHAgSDbJhTgZbxdmhLPDy3rA?= =?us-ascii?q?3frQ0vcWz38EhXoWrtIUSvCKz2K2sYnGxE2aD3914xTEGhRgZbb3B3tpAVLx?= =?us-ascii?q?Wdhl96zfKLaq2v02GYd1sFxaUHPCvYZCYJSzketOyfxVqbni2PGm4hwYhrNu?= =?us-ascii?q?vBDK47e7WWwX+1LpaU/Jt2UsN87dJgNNr0tPUMXv/acwiJLCngA+dB4X3fml?= =?us-ascii?q?81fC11omIji/XmxVns63W5xmc2Bb7XLE59T78WZ9Ga4G6MfYfD7LxpydY0t/?= =?us-ascii?q?C3KGP/d5qPzrzWdSdKLlfLunGtJttY36x8rOY3rv9+DpPbWTzH2DVO2wg/Nt?= =?us-ascii?q?79kAcbTL5g6L7MN4dzd6UpCm5k10tskM7KIFogswTwDON7Z10rgnPBN96C4r?= =?us-ascii?q?bDq9MUcwW8jRq1PUPa/zxW/v/DUSfGyKUTDLgoJ39KLEc783Zv8Yq5BsLtIR?= =?us-ascii?q?Tvc/sG+lW0MnWwKuAADKeEHKgdtRZ87ZWDmfSNey/xxQDXun96L8t1ghKaaN?= =?us-ascii?q?L3BBjJH+hCt8G+MxCLhKCh5caoljf5STehcS0j9MR4XF1Vat4GkyUoiY08zz?= =?us-ascii?q?O7RaP2qF80ilc220ATqnf9noy9pHrBFU5IMQfFkoxbUDlaPH+Pl9nE+4GjpQ?= =?us-ascii?q?PAySkA34LCGkdWdsxPHNZVTpGfFVYdFfQt?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAABMkpBg/4sNJK1aGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYIGAwEBAQsBgSIwUQd3WjYxC4Q5g0gDhTmIcgOKM4U?= =?us-ascii?q?Bih2BQoERA1QLAQEBDQEBKggCBAEBhFACF4FkAiU3Bg4CBAEBDAEBBQEBAQI?= =?us-ascii?q?BBgRxE4VQDYZEAQEBBCMEBhMBATcBDwIBCBEEAQEhAQYDAgICHxEUCQgCBA4?= =?us-ascii?q?FCIJqgX5XAy8BAws+nTkCih96fzOBAYIEAQEGBASFQQ0LghMDBoE6AYJ4hAw?= =?us-ascii?q?BAYEThUYnHIFJQoEVQ4FfgQA+gh5CAQECAYFDAhorCYJhNoIrgVkQWwYBAWI?= =?us-ascii?q?BAyIZCAgGAoEFDAcqCDoOAQsNSZBEAYNeh3qDVokzkFc5WwqDEIl5jXOFWRC?= =?us-ascii?q?DVKFOl0WJaYMdj08KhGsCBAIEBQIOAQEGgSNHJIFZcBWDJFAXAg6OHwwWg06?= =?us-ascii?q?FFIVJcwI2AgYBCQEBAwl8iU0CAiQHgQcBMl0BAQ?=
X-IronPort-AV: E=Sophos;i="5.82,271,1613433600"; d="scan'208,217";a="866152931"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 May 2021 00:17:49 +0000
Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 1440HnYS011746 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 4 May 2021 00:17:49 GMT
Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 3 May 2021 19:17:49 -0500
Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 3 May 2021 19:17:48 -0500
Received: from NAM04-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 3 May 2021 19:17:48 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YE26XVs32YMKQVup3mWyHX1FZE30Sb2ikm8XMOuEa8VnkLziuNK93qqZ9qRYKogw88iZghHGrbmtScL+xr4uzvEjd5tuJkEdOssbcxU59GgLItij2G0WUPJqtTxsGdJ9VCczXThKMvT7fOI7wVQP5s3lTewDbfClG93Xxx+97XRGnH+ZAHouJKr1gSS2hFboYxJd91iAjrS0WBfsLbgT3asEJSOz1whch3NSTph27HYXc4MjcKLV7Bndmu49VN3L4AZa/ykNr1m1jigWvwNUi+2/vYY9ysAvwoVNGg/IeQGJNiWwdhTETTxfXY8NlXKnlpk8EYgpAxPA8LV3gxvNAg==
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=kRLLvlvM787LIzm3IrYi0IPoJCEpw/TwtYXCd7qtKZE=; b=AFEf+HHNbtNchoAZcbajNEtOvhzXb4v+MTSuRmqiqrGsKMn3AJa11WCfkgD9xnWkBLaailHHfMwh8WhupajLPmLJciX4Gab0iaXXj9hq5MSf89pGRlGhzh0NPOe6KRHkikbFQizouYjOEQ3GZ//KqGXNDFY1nWMztMDFVPsdvpOtzdlf1q8iaYtS+ePXJDNdjVANPZMoghzZFU457VOJ1vBJxgINMdiA/fonN6jdYWTiceSfYtHarN6zjszy885FUqQuxj1gy1ATwRSmWto1FO53+j38FXaZBoG57IlobARqIBxxQj2oJF/2eAICe4q/tMFm/yVavDCz5dOkdgHvYQ==
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=kRLLvlvM787LIzm3IrYi0IPoJCEpw/TwtYXCd7qtKZE=; b=XhRZe9j6FdlWxGN3SdYAW2b51uVep8T0+bDXy4zPqKtCrzw3x+juMmDR9ecoTZ/17Gr8Hmsc0H06i030bRFfGSLhd5ElNo6St0GZwpshhcES0is6gKjwHYShdlHkdVwG+QVe/aJxGAFHGel3EOwJmSDXww0G6KN/otHyOFk8a28=
Received: from DM6PR11MB3194.namprd11.prod.outlook.com (2603:10b6:5:5c::25) by DM6PR11MB4233.namprd11.prod.outlook.com (2603:10b6:5:14f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.35; Tue, 4 May 2021 00:17:47 +0000
Received: from DM6PR11MB3194.namprd11.prod.outlook.com ([fe80::e4e0:cf18:7be1:8019]) by DM6PR11MB3194.namprd11.prod.outlook.com ([fe80::e4e0:cf18:7be1:8019%7]) with mapi id 15.20.4087.043; Tue, 4 May 2021 00:17:47 +0000
From: "Juan Alcaide (jalcaide)" <jalcaide@cisco.com>
To: =?utf-8?B?TWFnbnVzIE55c3Ryw7Zt?= <magnusn@gmail.com>
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-idr-bgp-flowspec-oid@ietf.org" <draft-ietf-idr-bgp-flowspec-oid@ietf.org>
Thread-Topic: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13
Thread-Index: AQHXP9b+AhhGGu0YA0eUTG7ppR6g/arRhrnQgAChcQCAAEs4UA==
Date: Tue, 4 May 2021 00:17:47 +0000
Message-ID: <DM6PR11MB3194CDD275DFB08A7CF91DBCCD5A9@DM6PR11MB3194.namprd11.prod.outlook.com>
References: <CADajj4ZQnWkjKdWpBgsB0oyX8_Kzj6HOL-Vkm=TrByBQMEJfPw@mail.gmail.com> <CADajj4bCTF5EeF6DZkCHpP0_GTnUYQtqa0OE3qf3Z5_AmKWfyA@mail.gmail.com> <CADajj4YxgdNXkWX7dLP0nBDWXLSKFa8M_KWWCPCgfCibYtWkAw@mail.gmail.com> <CADajj4Yw13QWbSqF_hd+P_fcNA4_YvdwqF=OgJ4pdS_1vrWphA@mail.gmail.com> <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com> <CADajj4aoBaSYTFFnvAjcL7mTnfoUJOWzvve=NRhgB3qe5X8uWQ@mail.gmail.com> <CADajj4ZTBoCHo2=RJhYFNMi+5L5JJwc_EqBkeyYUUfYsVk-vVw@mail.gmail.com> <CADajj4aN=cr-sxjMrmiSxsptwpOZWcH73dWhrtPrruahEQcNJg@mail.gmail.com> <DM6PR11MB3194503DF53A14C12FC749E4CD5B9@DM6PR11MB3194.namprd11.prod.outlook.com> <CADajj4bSyqcfGU7JoXz73mgGV+N71gkb2O060Kk2672JcE6VGg@mail.gmail.com>
In-Reply-To: <CADajj4bSyqcfGU7JoXz73mgGV+N71gkb2O060Kk2672JcE6VGg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; 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: c2ce23cf-c5da-4664-391d-08d90e920bcb
x-ms-traffictypediagnostic: DM6PR11MB4233:
x-microsoft-antispam-prvs: <DM6PR11MB423397B8031AF1E364F91FADCD5A9@DM6PR11MB4233.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: unltvO590vOIY+CdsYV7jYqdaDdEHIbblRu36hir9VK4Q0J1W7gXRqqmPcbY423GGt59vX0VQfR9tI+TyctZOBlYUaiokoXM1tOCJtnj9Eq+qIO1EqMRA6UZJ5MjTUaDFuko85zz0MnJWlAmtiQCS9dOhVE93+nmRIA9zorWsJLpdrKFdHD3bcgrhLmuwfv1oQscO0M3vsayVE0IyBZMPOVmqDaDyWefCnXk2YNTQvBSg2i2wAf7Jgtv6OH138uHD2KvilWyMnqvRCNd7tGCoZrlLS1Uhnnn6OfqJeVnCL19Wkrd8TzOF2nF8EwClylfcfCv2yyHzWPyRZcM4IIS3/LJUaOYN3w2yEotDwa1I6LNzm0e3W4a1eK4uJYsl9zaTxAW0pihZrTIij+DngoVfgV+IE164kJ6OsR2L0GLjyKbv6CY7oxN71mIc3TksnM2qje10OtkJff4lhkAjGh7PH5vCshxV9Qsd6Pl+p6mqhYwpx2Pwj2gbHlg6NF0qkPSOTORXdio9eq11VdbVhzDwHX8G+Hf5lZGZwHORZa3EBSeLfkgyLNQNkfObzn/mncd+m+ldRiPEOtX90cRbobPsQpUmktYmuZKQpX/blrDd9YlAJcY1U7UyKDJuvMd/DbVWWaeiSTnWRSgj/vfR+uoVXSVGFs0AGj/tJZxOtbctp0mlehlCVPdy4Hn46OwlE/I
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3194.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(346002)(366004)(376002)(39860400002)(54906003)(64756008)(2906002)(66476007)(316002)(122000001)(38100700002)(5660300002)(76116006)(66946007)(66556008)(66446008)(26005)(4326008)(86362001)(66574015)(71200400001)(33656002)(52536014)(166002)(478600001)(6916009)(83380400001)(8936002)(7696005)(55016002)(53546011)(6506007)(8676002)(186003)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?UUdCRmd6dWNSSHdPVlVnUTdpQk5SSVdhTlpzMkU4U1p5YzAzUGZ5dkNYcHNp?= =?utf-8?B?KzFMb0IrK2FXSWNBdnluK0NTM0xTZnVjaE5PTjZ0MktNU1dEdHhlOEJhaG1E?= =?utf-8?B?em8rRGVnQnZZaVFsOWx5TmpIalNLQkhYbmF6aUw1ZHZuWXlTQS81d0gxWm1z?= =?utf-8?B?SkE2KzFhZzZRdW1LcnVuYzlYOHU0RWhWekdPektzR3ZaU2tQUStmSFBlY3Na?= =?utf-8?B?c2FWRGhWWlVlbUkzcWk5KzBoZ21VSm5wVklNTDd6cU9FMTFBRGExZEJVM0tF?= =?utf-8?B?R2Q5eHBBaUtZYnF2bFFWV3hWQWpveGZ3UHR0YU9yVFNqcE9oQVBOcm5MeGdL?= =?utf-8?B?YnJEL3BJWU9UdGxRb2JxWFFxZFdYcklEc3ljZlg2L2hxZTlhcjN5RFBITEdw?= =?utf-8?B?RGV1TlJmOW95NUZHaFRLa2NXQVVuQU91ZEwvb3hwY2lKbkh0REl4OVREOWxK?= =?utf-8?B?aEZzMHJCL0pKelJrcUNvZTFteFNjcElpTzJ1U1BwMStTRVhaYnJXWGdveWxM?= =?utf-8?B?ZDhVRTMrQWpoc25MYnJXN0dmN2tVR2VaVk92NUZQN2kyZURoTXVldEoxeGg1?= =?utf-8?B?TUg0SS9PZ3g5WUxTNG52ODlLd04zZmJSV2JDTElFQmZvLytmN3ljR1JqRUgz?= =?utf-8?B?TGthN0srczlXQ1FmOHQzN3cwOXl3Wm05U2VnZlBFRC9OWis0RllPMmtXd1Fk?= =?utf-8?B?bXE0anBtQVV3V3pUVG5KaERyRDdRV1hpZCtmUkYvS2ozUUgzRk4xdUx5MWJO?= =?utf-8?B?d1NPdHJlS0tGT0xOd2lWTzdHaTlpa1hEblcvRzBmRXVHRXpUbHRvQUdoUkZ2?= =?utf-8?B?dUcyNm1ON1AvVkFIOUUvalBaTGo0NjRjMkpyNCtROE9odWt2b083ajZ5M3pX?= =?utf-8?B?T1h1MFQ2RERja0hkcDJYcFZjQUNJTk5rUkFua3UzRU51a1AwSWVrK2YwK3dI?= =?utf-8?B?OGVwYjJUVFlzU0dFbnJiM1BTTjR2RGcrUVk4UmowQkNQbGx1T1A1OTU2RnlB?= =?utf-8?B?WS83SjNlZGFteE5YVU9nQmhiMW1SNmh5eW5kcTN1Vlo4RytscEc0TVg2MzVX?= =?utf-8?B?dHkxTVRiTzdDTjF6WEQ0bnNuMElaYUNoUmswVStWVzRtMFMzQkozQ2ZYTzYy?= =?utf-8?B?NU5sc0d3Uk42SW1GdE5WRWYxbVZ1M3l2QVJPZkpsNm9Oc2lENTBOeHNvWDFx?= =?utf-8?B?ZDhFQURVWWZKRnVCUlVaUjBVOGdRWDdET2crZjNLcHFuZjczTmN4cnVicmZX?= =?utf-8?B?NjgwR2dJVHBqTjRyanluNURpaTNab0ZuRjNoaXl6cVV2NC9KUGF5RnpLRWpy?= =?utf-8?B?Um5uaFRlOVpFbERkVTdjd1FsZVkvNHRhQ01HQW8xaGtOaXliZEJ1Y0UrZFJl?= =?utf-8?B?d0pOa1JGYlB2QUwybFlEWEdYMmRvTEZhRG5BdnBidExibWh6TVJVdkRTSTdI?= =?utf-8?B?NU5RaE5XWGxOcG5jWWtlTlZ0bVZDM2wydHR4WTZVUStaK0VpbmhuWC94Uisr?= =?utf-8?B?Y0hpaHhiT0gwYng4KzF6ZUNYRzRVZithRUpnMVNNYmZhend1RG9nSVY5bGVl?= =?utf-8?B?ZG9USTh2MDdLOHVjc1VIbzJKd29tcXZ3bVJVTUpvZFNJS1JlM1IrSEVWUHli?= =?utf-8?B?Wm1WdFVkNkZxMkNIOWdJQTBzcFcyMFJBeml0b2V2dzlScFlOQStmM2R0TVhI?= =?utf-8?B?R2ZZVDZmVVZia3ZKL0tuU2wzQmVneWp1aFFTWG5RY2xkaTJhL1V3dHgzSWx0?= =?utf-8?Q?swb2dlkXTVyv35ejCs=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3194CDD275DFB08A7CF91DBCCD5A9DM6PR11MB3194namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3194.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c2ce23cf-c5da-4664-391d-08d90e920bcb
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2021 00:17:47.4808 (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: KtauYpcHSHa9Zitd1dIZUWXnj05zc58/dnlskcCagoDTrFDCQXjpiy6Jm1+ARSz94SHf6sl+UksBaBM1hq8BeQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4233
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/HFBghVbhdv0okFKrYQ4bQh_XFKw>
Subject: Re: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2021 00:17:57 -0000

Magnus,

Yes, they’ll be opening to risk. It’s the risk described in the draft. But this risk is necessary for route-servers to work with flowspec. And as mentioned, perhaps route servers can be configured to avoid that risk.


I wanted to use the term ‘remain’ instead of ‘become’.. We went from RFC4271 (rule optional) -> RFC8955 (rule mandatory) -> this draft (rule again optional)
Would the below make sense (I changed the first sentence):

   This document makes the original AS_PATH validation rule ([RFC4271] section 6.3) again optional
   (section 4.2) for Flow Specification Address Family (the rule is no longer mandatory as it was specified by [RFC8955]).
   If that original rule is not enforced for Flow Specification it may introduce some new security risks.
   A peer (or a client of a route server peer) in AS X could advertise a rogue Flow
   Specification route whose first AS in AS_PATH was Y (assume Y is the
   first AS in the AS_PATH of the best-match unicast route).  This risk
   is impossible to prevent if the Flow Specification route is received
   from a route server peer.  If that peer is known for a fact not to be
   a route server, that optional rule SHOULD be enforced for Flow
   Specification routes. Note that identifying those peers that are route servers may suppose an
   operational challenge. If the condition of the peer is unknown, the rule SHOULD not be
   enforced.

   A route server itself may be in a good position to enforce the AS_PATH validation rule described
  in the previous paragraph. If a route server knowns it’s not peering with any other route server,
   it can enforce the AS_PATH validation rule across all its peers. If, in addition to that,
   the route server is trusted, the security threat described above disappears.




From: Magnus Nyström <magnusn@gmail.com>
Sent: Monday, May 3, 2021 9:39 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: secdir@ietf.org; draft-ietf-idr-bgp-flowspec-oid@ietf.org
Subject: Re: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13

Thanks Juan.
For the editorial ones, agree on the first one and I think the second you could change to "with this memo, becomes optional." or similar.
For the new text, perhaps I am misunderstanding something, but this sentence:
Note that identifying those peers that are route servers may suppose an operational challenge. If the condition of the peer is unknown, the rule SHOULD not be enforced.
Is it correctly understood, that you're saying that if a validator is unable to determine if the peer is a route server, they should not enforce the rule? If so, doesn't that mean "failing open, i.e., opening themselves to risk? Sorry if I misunderstand.


On Mon, May 3, 2021 at 3:36 AM Juan Alcaide (jalcaide) <jalcaide@cisco.com<mailto:jalcaide@cisco.com>> wrote:
Thanks for your comments, Magnus

Inline..

From: Magnus Nyström <magnusn@gmail.com<mailto:magnusn@gmail.com>>
Sent: Monday, May 3, 2021 6:44 AM
To: secdir@ietf.org<mailto:secdir@ietf.org>; draft-ietf-idr-bgp-flowspec-oid@ietf.org<mailto:draft-ietf-idr-bgp-flowspec-oid@ietf.org>
Subject: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document describes "a modification to the validation procedure defined for the dissemination
of BGP Flow Specifications." More specifically. the memo describes a mechanism which relaxes  the existing validation rule that requires Flow Specifications to be originating from the originator of the best-match unicast route, and now allows such specifications to be originated within the same AS as the validator. As a result. the Security Considerations section does call out: "The original AS_PATH validation rule ([RFC4271] section 6.3<https://tools.ietf.org/html/rfc4271#section-6.3>) becomes  hereby optional (section 4.2<https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-13#section-4.2>)2>). If that original rule is actually not enforced it may introduce some security risks. A peer (or a client of a route server peer) in AS X could advertise a rogue Flow Specification route...." and "If t[the originator of a rule] is known for a fact not to be a route server, that optional rule SHOULD be enforced for Flow Specification routes."

It is not clear to me how a validator would now "for a fact" that a peer isn't a route server, and thus that it would have to enforce the now-optional path validation rule. It seems some clarity on this would be good such that implementations have less of a risk of accepting flow specifications from unauthorized parties, even if they are on the same AS.

[JUAN]: This paragraph was not intended to pressure the operator to know if the peer was a route server, it was just a ‘if’. Note it’s the same case for RFC4271 :

If the UPDATE message is received from an external peer, the local
   system MAY check whether the leftmost (with respect to the position
   of octets in the protocol message) AS in the AS_PATH attribute is
   equal to the autonomous system number of the peer that sent the
   message.


Note that the same challenge of identifying route servers applies for other address-families.
Note also that the route-server itself may enforce the rule.

What about for clarity:

   The original AS_PATH validation rule ([RFC4271] section 6.3) remains hereby still optional
   (section 4.2) for Flow Specification Address Family (changes introduced in [RFC5575] are cancelled).
   If that original rule is not enforced for Flow Specification it may introduce some new security risks.
   A peer (or a client of a route server peer) in AS X could advertise a rogue Flow
   Specification route whose first AS in AS_PATH was Y (assume Y is the
   first AS in the AS_PATH of the best-match unicast route).  This risk
   is impossible to prevent if the Flow Specification route is received
   from a route server peer.  If that peer is known for a fact not to be
   a route server, that optional rule SHOULD be enforced for Flow
   Specification routes. Note that identifying those peers that are route servers may suppose an
   operational challenge. If the condition of the peer is unknown, the rule SHOULD not be
   enforced.

   A route server itself may be in a good position to enforce the AS_PATH validation rule described
  in the previous paragraph. If a route server knowns it’s not peering with any other route server,
   it can enforce the AS_PATH validation rule across all its peers. If, in addition to that,
   the route server is trusted, the security threat described above disappears.



Anybody feel free to reword the two paragraphs above if it helps them for clarity.



Editorial:

  *   "Let's consider the particular case where the Flow Specification is originated in any location within the same autonomous system than the speaker performing the validation (for example by a centralized BGP route controller), and the best-match unicast route is originated in another autonomous system." - should the word "than" be replaced with "that" here?
[JUAN]: Thanks for pointing that out. A few googling tells me the even better grammatical choice would be ‘same as’ in this case. I’ll be using ‘same as’ unless  you disagree.


  *   In the security considerations section, "becomes hereby optional" could probably be simplified to "becomes optional" or similar, and "actually" could be removed.
[JUAN]:  Hmmm, I thought that it was important to emphasize it becomes optional because of *this* draft redefinition of rules. Don’t you think it’s important? (whatever wording you want to use). Regardless, refer to my new reworded 2 paragraphs above for that section .




Thanks,
-- Magnus



--
-- Magnus