Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification
"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Thu, 28 February 2019 16:16 UTC
Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49057130EF1; Thu, 28 Feb 2019 08:16:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 GiaCS3JrLM0u; Thu, 28 Feb 2019 08:16:08 -0800 (PST)
Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd00::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E70130EB4; Thu, 28 Feb 2019 08:16:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PUd+mD5t266JUR0flSzXjDAWTLJbFkcXvY75nLZhoqo=; b=y+BL4S6FW6ogFTzbcsew3dSEErPSz3T0KPwV61sA43PRXkNiQDw3153bNxCqV2lI3x0KEEpIgztZaDlFQVhgfS3QQje/2oyT9KQsZtxM+OK0TgRWnbqhNPvlcdX1oXaaWfikowbsPMGEX1V2q7/AQpds1I2hKxreuWJs+f4U3EU=
Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2367.namprd09.prod.outlook.com (52.132.115.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Thu, 28 Feb 2019 16:16:06 +0000
Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85%5]) with mapi id 15.20.1643.019; Thu, 28 Feb 2019 16:16:06 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Alexander Azimov <a.e.azimov@gmail.com>
CC: "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification
Thread-Index: AdTPfU3OunYiYNKQQ16BjWmmsPxDng==
Date: Thu, 28 Feb 2019 16:16:06 +0000
Message-ID: <SN6PR0901MB236620AD0F6209170C9BD9A384750@SN6PR0901MB2366.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov;
x-originating-ip: [129.6.252.155]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 403f11a4-a7f0-40ae-5208-08d69d980ae4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2367;
x-ms-traffictypediagnostic: SN6PR0901MB2367:
x-microsoft-exchange-diagnostics: 1; SN6PR0901MB2367; 23:5qan8O+Czl/V5UBL7Vb1WTG8uNlYnx5skk7wVHXIv1qscXQBmbtLa8w1BthZ62IW9ZBppLlcdru17WwUw2Fth2H0sW1CtFAoASZvZchvMkT2FouxXDN5GYyydWk5rfc2nW8kdS0r/bviXuP8mkKun9dB4TN7kjuV75Uy/O8prtZbH8z/Xfc0wm+QFEj59Upb2VLkQhai/fD9dsMI/inX/uPX6bJ5EqRPBwa1IUA74kpYmZfnNk1rwoWCJlRMQGlHNj50glJF2stvCxvQMld1fOCipZLoDm0DNFTjnbWi1oK5b6WYNwTVr8z/cqgZ4aO8qNF79Ryr6lvzKQc5txveAOXKAj4NjHY8AJT6EG6PVzEtyNRC/vXW8VPUfNi6bbTmUa5lvfW4cbV2EupX5KPJsIUB5mlzWKOrEmPtQAa3PcAvyHdo1m8y67mgmH4gZO9mgPQB0uCOJpArvy9cGqQghEOsp7uEsd1P2NhLFyUIapOXTrvXnMui0lV/RbsdL8OxUb7QhMxK05Q6fHtbUppAjieZqchPbEKg5YwKtxxQDWxWPOav6rFaKA7KS+9HmrMbhTUsdQJC7MddVCeUJ8noYM0nQAwVrT4HSw8XPnFWG3JKYx/70k10CCL8ELMDCWRgjjJNmT29MI4UynqmVg6Eelmn1SDzsfcMT8Jkpg7Ti986r9wzFJhpVSVjqCrZIHuz3Co0IuOAbFeWLYO3FEUONQdon4h1KbkKa0OnzgWvnj8WCxj513pQ+Q0Qx3n9KrXWjK12nFl48E02vWIJGyuKG5GP11XA6lh5BlUQqrZZiQBCCTn4eVQ93EboULtl64cF9zqfd4tnaDHTwMG+fLH5h2RZRk5wToCJSyn8c63JSeJdtZiMPLFOHE0Wm30gRMiQaeeWGo1VGoZxL5xblsaIFSwmkABV7ImcSxaybEXLBFfF7FKxUpouDatmVFROwmkgOHub33373V2KcJvXv7vvje22TQHHadea6MxALkCkDK3rWdGMamzCIOy2tIk0LbKrDfWC6wUwEx3+urh7EwpbYA0ntdScKpin+xn0ckPovHtkgXKO12ERgm5ZGTP/1/AkIfBLjGMtFMLCgdJzzN63EfdDW3jktVEZNu31eIU3T4yRfqj7OdARhB9dHy6SmOifQj4dlZcVaTvWC8q2z636k1wmn88CUjVDoTWuVdHIH4SEVuRn3MfHj8u4kwKjrCBv/A2O8ZPpfXKFTcqQbZPQrHEpY+hf3HWT1IMo31RDQin4meIh1VvcipN6ZHGlsZxklYJP5y42nGGEWn7KdTVTxfZ7hQ8o9FdWZUYbnmo+Z9f6GCl4eyi6jHhBgxMVVNjaSsGEHwFfi5558ZplckmtgxR/ac/YdcAfegFQDbcGaed+eEF2fRzXB0EATydUBS71
x-microsoft-antispam-prvs: <SN6PR0901MB23679BD23C038FB28B0C121484750@SN6PR0901MB2367.namprd09.prod.outlook.com>
x-forefront-prvs: 0962D394D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(136003)(346002)(43544003)(199004)(189003)(53936002)(74316002)(7736002)(102836004)(5660300002)(15650500001)(8676002)(9326002)(6116002)(68736007)(476003)(81156014)(81166006)(486006)(26005)(8936002)(186003)(6916009)(97736004)(10710500007)(2906002)(66066001)(4326008)(71190400001)(71200400001)(25786009)(6506007)(86362001)(316002)(105586002)(229853002)(55016002)(14444005)(54906003)(2420400007)(256004)(106356001)(966005)(6436002)(6306002)(52536013)(478600001)(99286004)(6246003)(7696005)(33656002)(54896002)(9686003)(561944003)(790700001)(3846002)(14454004)(49910200004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2367; H:SN6PR0901MB2366.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: p98YTDRLJIG3la+SNb36Ss77QKOv1lU8xKRXk4UVTxekLPVL8dgRK7mdMrq+cI7iHJg4J3GP/QVPf6TGMrKK2TKcOx1oYVphyKFK7ZiUEqQ95mBSIQ52wTRPq+RuWyLewOJUPYmWbkNFaDXuf6S2Y9x8Am3VNUmOeHzxgx9bANJ3lpd12oqUXh0kA5OwFytvTRFEotpYcLckDfBdiu9Nh2MbewUrJZP4Qu3ZJwenouOr0VBwXxjrCSawc0qd6kUcfLTEFXRuYKZZDUR+DUnGleLR7sFYCr4BM9tBBZe1qhGofxlcfvTdZ1BpHlLVCqNLGeKzddFEH2ME1HMZd6wxiqt5aSVKfIfsrKanJSVOrSyPLZ2GTJZHON3zaplCKSPz+SAt8FyHWHyWcKl+hu+jdFvg+X+gAiHpb8zTuplE0aE=
Content-Type: multipart/alternative; boundary="_000_SN6PR0901MB236620AD0F6209170C9BD9A384750SN6PR0901MB2366_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 403f11a4-a7f0-40ae-5208-08d69d980ae4
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 16:16:06.1958 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2367
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/xiEe0knabMtwR6OoWUDm5iMUUOk>
Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 16:16:13 -0000
Hi Alex, I'll be happy to support but can you please take care of comment #1 prior to completion of the adoption call. And while you are at it, comment #6 would be also easy to incorporate. They should take no more than 10 minutes in all. My other comments are important as well, but they only need discussion for now. Comment #1: I would strongly suggest deletion of the last two sentences of the second paragraph in the Intro section. You talk about downgrade attacks with BGPsec there. The two sentences in question are inconsistent with how incremental deployment of BGPsec really works. Please read RFC 8205 Section 7.9 -- the idea of contiguous BGPsec ASes. Regarding your attacker downgrading BGPsec comments, John Scudder also suggested to you in IETF 102, "It is not necessary to make that extreme claim for your proposal, if I were you, I wouldn't." See video at ~48 minute mark: https://www.youtube.com/watch?v=LnXLB_MlpAs Comment #2: Improvement of the algorithm for detection Consider this topology example: AS3 AS5 / \ / AS2 AS4 / AS1 The peering relations are C2P going up and P2C going down (in the pic). AS1, AS2 and AS4 have created ASPAs. AS3 has not created ASPA. Let us say AS4 accidentally leaks to AS5 the route received from AS3. The route's AS_PATH is AS4 AS3 AS2 AS1. I think your algorithm (section 5) would fail to detect the leak. But I would suggest a modified algorithm which is as follows: At AS5, when it sees that AS3 does not have ASPA, it then considers the ASPA of the next more recent AS in the path which is AS4 here. >From AS4's ASPA, AS5 determines that AS3 is a provider of AS4, and hence successfully detects that the update is a route leak. So, I think the algorithm in section 5 needs to be modified per suggestion above. Comment #3: In the figure below, AS1 originates p1 and AS2 originates p2. AS1 is a provider of AS2 for p1 and AS1 is a customer of AS2 for p2. AS1 announces p1 to AS2 as P2C. AS2 announces p2 to AS1 as P2C. AS3 is provider of AS2. ---------P2C-------> p1 AS1 ---> -----p1 AS2 AS1---> AS1------------------(hybrid/complex)----------AS2---------- C2P ----------->AS3 <--- p2 AS2 <---------P2C------- AS1 creates an ASPA: {AS1, AS2, IPv4} AS2 creates an ASPA: {AS2, AS1, IPv4} Now consider AS2 leaks route for p1 to AS3. Then AS3 is unable to detect the leak. AS3 looks at the ASPA: {AS1, AS2, IPv4} and determines that AS1 is a customer of AS2, and hence determines incorrectly that the Update: p1 AS2 AS1 is not a leak. The ASPA scheme fails to work in this case for leak detection. This is a limitation of the ASPA scheme because ASPAs are per AFI and not per prefix. Comment #4: Not all malicious leaks / hijacks are detected In the topology below, AS2 leaks the path it learned from its peer AS4 to its provider AS3 with path modification to avoid route leak detection, or one may think of it as a hijack with feasible path insertion. In either case, the Update: p2 AS2 AS1 from AS2 to AS3 is illegitimate but defies detection despite all ASes participating in ASPA. AS3 AS5 \ p1 AS2 AS1 / \ p2 AS2 AS1 / \ / \ <----p2 AS4 AS1-- / AS2 -------p2p----------AS4 \ / \ p1 AS1 /p2 AS1 \ / AS1 (p1, p2) Comment #5: Path verification vs. path feasibility Based on the above examples, in the draft, perhaps it is better to say that the path is assessed feasible rather than say that the path is verified. Comment #6: In paragraph #1 in the Intro section, [I-D.ymbk-idr-bgp-eotr-policy] is referenced. Based on WG consensus, we merged [I-D.ymbk-idr-bgp-eotr-policy] and [I-D.idr-route-leak-detection-mitigation] and the latter is the WG document that we are working on together since April 2018. So, [I-D.idr-route-leak-detection-mitigation] is the more appropriate document to cite for the ongoing WG effort. Thanks. Sriram
- [Sidrops] WG Adoption call draft-azimov-sidrops-a… Chris Morrow
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Ruediger Volk
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Oleg Muravskiy
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Tim Bruijnzeels
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Nick Hilliard
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Randy Bush
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Andrei Robachevsky
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Alexander Azimov
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Alexander Azimov
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Alexander Azimov
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WG Adoption call draft-azimov-sidro… Christopher Morrow