Re: [Idr] Route Leaks and solutions

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Sun, 05 July 2015 16:06 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DDC1A8978 for <idr@ietfa.amsl.com>; Sun, 5 Jul 2015 09:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Hk9zCT7ySBE1 for <idr@ietfa.amsl.com>; Sun, 5 Jul 2015 09:06:19 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.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 3C64E1AC411 for <idr@ietf.org>; Sun, 5 Jul 2015 09:06:19 -0700 (PDT)
Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by BLUPR09MB007.namprd09.prod.outlook.com (10.255.211.150) with Microsoft SMTP Server (TLS) id 15.1.213.10; Sun, 5 Jul 2015 16:06:17 +0000
Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Sun, 5 Jul 2015 16:06:16 +0000
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Susan Hares <shares@ndzh.com>, 'idr wg' <idr@ietf.org>
Thread-Topic: Route Leaks and solutions
Thread-Index: AdCygvgZdEuODf/jSQ2DVCW8x4wMngEnwHhu
Date: Sun, 05 Jul 2015 16:06:16 +0000
Message-ID: <CY1PR09MB079346B06E1D2C85FAFFF62684940@CY1PR09MB0793.namprd09.prod.outlook.com>
References: <005901d0b283$ea07bd20$be173760$@ndzh.com>
In-Reply-To: <005901d0b283$ea07bd20$be173760$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nist.gov; dkim=none (message not signed) header.d=none;
x-originating-ip: [129.6.218.169]
x-microsoft-exchange-diagnostics: 1; BLUPR09MB007; 5:+pbmO41D07vafgE5qcv34HyIi57iMabdkUoTpa6PBKOF4IXrCUWhI3OTDVwnwvUYBKR9MQwzM0bCrw6PYw89s5DiwM6YV84tz2eNH/IoWpvATJsVwpGHXGHaGURnoKrdjAA03FnpYCwy7ja+mEa1Yw==; 24:kjPQBq36o6MgHeiZKRArozFfeRZnUtvyfEw9CnX5ohXoE1DLMn4uI/5ujXEcnNKP1qtCDAvEhjIZDM5qSUunf9Vo9pNk+1rbaomOgIkDAGA=; 20:Tf9H/ixtotFa2n5erUUUXcyr7x5PwMn80jTIYAVVrhAhWd/LpemYnf1jBd+ZInLs7VYQLCQb/l1acIrjiZP4bg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB007;
blupr09mb007: X-MS-Exchange-Organization-RulesExecuted
x-microsoft-antispam-prvs: <BLUPR09MB007CDD0FC181961EDC14DF684940@BLUPR09MB007.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR09MB007; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB007;
x-forefront-prvs: 062899525A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(50986999)(54356999)(189998001)(76176999)(74316001)(5001960100002)(99286002)(33656002)(5003600100002)(19580405001)(19580395003)(5002640100001)(46102003)(66066001)(87936001)(2656002)(77156002)(62966003)(2900100001)(2950100001)(122556002)(86362001)(15975445007)(102836002)(76576001)(5001770100001)(40100003)(92566002)(77096005)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB007; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2015 16:06:16.3977 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB007
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/LjrKeLh3PndBlA6VaVwQ0YlendI>
Cc: "Montgomery, Douglas" <dougm@nist.gov>, "bdickson@twitter.com" <bdickson@twitter.com>
Subject: Re: [Idr] Route Leaks and solutions
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 05 Jul 2015 16:06:21 -0000

Sue,

Thanks for this summary and questions based on the IDR interim (6/29) presentation/discussion.
Responses follow inline below.

>Sriram and Doug: 
>During the interim the following questions asked about the solution in 
>draft-sriram-idr-route-leak-detection-mitigation-00
 > 1. Does the IDR WG think Route leaks should be deployed in two modes:
> With BGPSEC and without BGPSEC?
> Without BGPSEC, Sriram suggested that  it could accidental route leaks, but not malicious route leaks. 
> Is this useful to operators?

In the updated draft (-01 version) that we just posted, we have talked about
of deploying it 'without BGPSEC' and then advancing further to 'with BGPSEC'.

Randy asked on the IDR list if "without bgpsec, is it an attack vector?"
IMHO, the worst case damage of using it as an attack vector is quite limited, 
especially when weighed against the benefit. 
We have tried to discuss this question carefully in Section 5.1 of the updated -01 version:

https://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigation-01#section-5  

As Jeff Haas rightly pointed out during the interim (6/29): Realistically, BGPSEC may take 
a much longer time being deployed than origin validation (OV). 
So if the operators, already actively engaged in preventing  mis-originations 
and route leaks using prefix filters and OV, express a further sense of urgency for
a substantial route leak solution (with OV, without BGPSEC), 
then yes, there would be a need to work on it now. 

Danny McPherson had strongly urged for a solution for route leaks:

http://www.ietf.org/mail-archive/web/sidr/current/msg00920.html

Jared Mauch had also expressed strong concerns about route leaks in the same thread.

Plus, we regularly see trade-press and mainstream news headlines (route leaks related):

"What caused the Google service interruption" March 2015
"Massive route leak causes Internet slowdown" June 2015
"Why Far-Flung Parts of the Internet Broke Today" September 2014
"The New Threat: Targeted Internet Traffic Misdirection" November 2013
"How did Dodo break the internet?" February 2012

So, possibly operators would want to use a route leak solution (without the BGPSEC protections)
for the interim. But yes, it would be good to hear from them directly!

> 2. If we think it is useful without BGPSEC, should it be deployed in both forms (BGPSEC and non-BGPSEC)

I think this is already addressed above.

3. Would deploying ROA and route filtering, find this another useful addition?

By "this" I think you mean a solution without BGPSEC for interim use.
I think operators would want to combine it with any existing
solutions based on deploying ROA-based origin validation (OV) and route filtering.
I think deploying OV and route filtering would be very useful but 
not adequate to solve the route leaks problem, as discussed in Section 5.2:

https://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigation-01#section-5  

We've also discussed the utility of AS path ORF in Sections 4 and 5.

Sriram






  

 















From: Susan Hares <shares@ndzh.com>
Sent: Monday, June 29, 2015 11:54 AM
To: 'idr wg'
Cc: Sriram, Kotikalapudi; Montgomery, Douglas
Subject: Route Leaks and solutions 
  

Sriram and Doug: 
 
During the interim the following questions asked about the solution in draft-sriram-idr-route-leak-detection-mitigation-00
 
1.       Does the IDR WG think Route leaks should be deployed in two modes:  With BGPSEC and without BGPSEC?  
Without BGPSEC, Sriram suggested that  it could accidental route leaks, but not malicious route leaks.
Is this useful to operators? 
 
Without BGPSEC, this could be deployed as an optional transitive path attribute or an extended community.  
With BGPSEC, this information could be part of the signed path attributes. 
 
2.       If we think it is useful without BGPSEC, should it be deployed in both forms (BGPSEC and non-BGPSEC)
3.       Would deploying ROA and route filtering, find this another useful addition?
 
Could you comment on these questions and discuss the value of route leaks on the list? 
 
Sue Hares