Re: [Sidrops] Call for SIDROPS WG Agenda Items

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Tue, 10 July 2018 18:25 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 25498131041 for <sidrops@ietfa.amsl.com>; Tue, 10 Jul 2018 11:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 S3pijqlWabec for <sidrops@ietfa.amsl.com>; Tue, 10 Jul 2018 11:25:45 -0700 (PDT)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0135.outbound.protection.outlook.com [23.103.201.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30623131038 for <sidrops@ietf.org>; Tue, 10 Jul 2018 11:25:44 -0700 (PDT)
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=S3tA2GhKRKqMTj/0iZjmO8MHq+MN2MjUgn8M0P5zJAI=; b=S9Q3FVKxZzMyVWslDd5mtWr4EL38X14uVYlQRT+ubBO1ybtxBjVm4+9ner8kvPU4xcc458kHIwa3PLCZerTBYmj8xF/lQL9CkknL4ZPbs3M8ghVMSHI9J/OzA/3zl3j/3EH/xmR9srq+oRRnL11Hjb43Sq/6LbrFczNYcQlJRQk=
Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2365.namprd09.prod.outlook.com (52.132.115.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Tue, 10 Jul 2018 18:25:41 +0000
Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::3488:a44a:a9ce:6db7]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::3488:a44a:a9ce:6db7%6]) with mapi id 15.20.0930.022; Tue, 10 Jul 2018 18:25:41 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: "tim@nlnetlabs.nl" <tim@nlnetlabs.nl>
CC: Alexander Azimov <aa@qrator.net>, Keyur Patel <keyur@arrcus.com>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: Re: [Sidrops] Call for SIDROPS WG Agenda Items
Thread-Index: AdQYebDo5HUre4uJSriccjT1enEZAQ==
Date: Tue, 10 Jul 2018 18:25:41 +0000
Message-ID: <SN6PR0901MB23660F996F53FB206785AF5F845B0@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.140.122]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR0901MB2365; 7:zJ7CFFbBsKtTCQs/rlQJaw1KC8wkm/ab7Dw3qloSoJf/UbWfhXzfeSUC3ivGL5vm1jawLsZ4Rr9JbXccMBbvo03dGK7rs7EFeFAHeSVDX/Tf+Zye2oFcDyj4Jkca0RzRQQhMQMmw6REcdva3E6ZFhYgee0DmEt4op7//r1UkmMX5YAQBL693VXA34EdbVe62ZWAYn53nqCAzfig75mqMBY67hzwMOGDIb1EF4PWs05R167O8iW1sMi6R7vzIPeVo
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 8f4d39b1-9fa1-4b5b-7f2c-08d5e6928b3e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2365;
x-ms-traffictypediagnostic: SN6PR0901MB2365:
x-microsoft-antispam-prvs: <SN6PR0901MB236555241B8A6BAEF60692EF845B0@SN6PR0901MB2365.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:SN6PR0901MB2365; BCL:0; PCL:0; RULEID:; SRVR:SN6PR0901MB2365;
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(136003)(376002)(39860400002)(199004)(189003)(486006)(26005)(476003)(6436002)(55016002)(4326008)(229853002)(81156014)(99286004)(7736002)(186003)(5250100002)(6306002)(966005)(14454004)(53936002)(2900100001)(1730700003)(6246003)(97736004)(2501003)(8676002)(6506007)(9686003)(81166006)(102836004)(478600001)(68736007)(6916009)(74316002)(3846002)(6116002)(7696005)(2351001)(5640700003)(2906002)(54906003)(106356001)(305945005)(256004)(105586002)(66066001)(14444005)(8936002)(25786009)(316002)(5660300001)(86362001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2365; 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-microsoft-antispam-message-info: fxs4Qj71xP7PSRGkjwQl9J0JUip6HChKjp62X3DkTGT1sqGUbFlfTsPVCJ7CDbFsR4Br4L7lb71EHiQty2SaaTLqllWRcySh28lzQwOMtzRJyyIpJd9962X0/zAXHmg90BMeXBzP1kk9GkeAslwKuK7nLCPKUGq4YBKJPHhn8m4Ju2z3kS+ngd4yCxwUXWk7XGGUSPb710vyMR81xjq5fW8ECGofUr9wenrrlnCkLolEGqCfFX78z6B6iyKolygnUn6j6oKlEZk5vueZUvtDvmJdiEGKFrM3rXcp87H7h8auaAp7hl31roHvV3iAAhowQDHD8cZSPcCWbu310GHiaSx6CEhdUeXADOAF62/aif8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f4d39b1-9fa1-4b5b-7f2c-08d5e6928b3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 18:25:41.7545 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2365
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Xxod-fcnisj_rSjBWAX7-r4tWTs>
Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 18:25:50 -0000

Tim,

>IMHO one of the big issues with BGPSec deployment is that 
>it's all or nothing, so there really is no incentive to deploy until everybody else has done so.

IMO, these are two different goals: (1) All AS hops must be valid for the update to be valid, 
and (2) the benefit of BGPsec for early adopters with incremental deployment.
BGPsec is successful on meeting both goals.

SIDR path validation always had the requirement that the AS path in the
announced update MUST be provably valid; not merely feasible
(see 4.2 in RFC 7353). 

SIDR WG ruled out partial path validation because that would
keep the door open for cut-and-paste or forged path attacks.

Without BGPsec, the following can happen.
Even with checking all AS hops in the update against a database
that provides a white list of peering relationships 
(e.g., proposed ASPA, CAIDA peering data),
an update with forged path is still possible. For example, consider a prefix that is
multihomed and has two RAOs with ASNs of two different providers,
and the prefix is only announced through one provider.
An MITM attack is possible that exploits the other ROA and the white list
to forge a route consisting of only valid AS hops (end-to-end).

Regarding, (2) the benefit of BGPsec for early adopters and incremental deployment,
please see Section 6.3.2, RFC 8374 ( https://tools.ietf.org/html/rfc8374#page-26 ):

6.3.2.  Discussion

   The partial-deployment approach to incremental deployment will result
   in "BGPsec islands".  Updates that originate within a BGPsec island
   will generally propagate with signed AS paths to the edges of that
   island.  As BGPsec adoption grows, the BGPsec islands will expand
   outward (subsuming non-BGPsec portions of the Internet) and/or pairs
   of islands may join to form larger BGPsec islands.

The ASes within each BGPsec island are backward compatible with
traditional BGP ASes that are outside the islands (see Section 4.4 of RFC 8205).  

Sriram