[sidr] operator inputs -- route leak solution

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Tue, 21 March 2017 18:00 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09027129C58; Tue, 21 Mar 2017 11:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com
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 Xq7E8riBEcZw; Tue, 21 Mar 2017 11:00:38 -0700 (PDT)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0114.outbound.protection.outlook.com [23.103.200.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403C6129C43; Tue, 21 Mar 2017 11:00:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MtlZXKhMN2w6ttqnjcOR4pO7BvG72Tnzd7z/mUAwiB0=; b=d/VjByct7fNy3HPQRLOhbeaRpRHJIE9t7pfX97ajE6cOhG4pOjSavqOHUu9ijepaHi9xn+1XnEKkiPcGREicjJOT60OnuIfFZwcKq8ZGBcitzm2IYiWYiS8X+saU0NmQjOxphOGlX4pw+TYEoRimptGpdYDyNl88qdyNFKYZKtM=
Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 18:00:36 +0000
Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.019; Tue, 21 Mar 2017 18:00:36 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: "grow@ietf.org" <grow@ietf.org>, "idr@ietf.org" <idr@ietf.org>
CC: "sidr wg list (sidr@ietf.org)" <sidr@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" <draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org>
Thread-Topic: operator inputs -- route leak solution
Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4w==
Date: Tue, 21 Mar 2017 18:00:36 +0000
Message-ID: <DM2PR09MB044656C168037D0BEF7A78CB843D0@DM2PR09MB0446.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [129.6.110.145]
x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:xBQU71LM1+X3o0+Ty1/UwWlrOxncq+oJt+62mY5tIjRUmVCwGVQXIHZSBKkAqv27yEORlnSHP/t2qyis88m6fPo0AEOR51q3CpIH/HhBi6Qne7E21djlT8YEKgYZUlIt+mlN2YhFsLqzhyilxM88LemjTUvwMFpoLJiYbT8Oacg+9Ugs8PJzFksOesYoQsyO10C0G4A8oPkyRJr5bRgGsq0g9JDs2HvulqryB6sxTFuuE6YA9y7Zg8ORXhybY9Q6FeM9tCcNwO1WAjT0olpg28Zi48HvrsgLRnQMZRM1rrj09CCqaMzF7oW5yZomtbOs1GdDcccXwn28l5rrCbN3ZA==
x-ms-office365-filtering-correlation-id: 7ba95e3f-b4b6-4025-082b-08d470842d66
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0445;
x-microsoft-antispam-prvs: <DM2PR09MB0445990FB3A7070883644534843D0@DM2PR09MB0445.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(256337837700080);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445;
x-forefront-prvs: 02530BD3AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39840400002)(39410400002)(39860400002)(305945005)(86362001)(3280700002)(7736002)(74316002)(3660700001)(6506006)(38730400002)(2906002)(2900100001)(54356999)(50986999)(66066001)(7696004)(33656002)(5660300001)(6436002)(55016002)(966004)(53936002)(9686003)(99286003)(54906002)(6306002)(77096006)(122556002)(8936002)(189998001)(8676002)(81166006)(3846002)(6116002)(2501003)(102836003)(4326008)(25786009)(450100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
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-originalarrivaltime: 21 Mar 2017 18:00:36.3476 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/mP3yfhpkyNj2VokMZSCnyVTxif8>
Subject: [sidr] operator inputs -- route leak solution
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 18:00:41 -0000

Inviting comments especially from GROW WG folk (network operators). 
Please look at this and address the question posed at the end. Thank you.

The most common form of route leak occurs when multi-homed 
customer AS-C receives a route from its transit provider AS-A
and leaks it to another transit provider AS-B.  
[RFC 7908  https://tools.ietf.org/html/rfc7908  ]

Customer AS-C is often the single point of failure.
AS-A and AS-B may be doing intra-AS community tagging etc. 
perfectly well to prevent route leaks, but AS-C does not and ends up leaking.
The leaked route propagates via AS-B to the rest of Internet 
due to prefer customer route policy.
(Example: Google/Hathway/Airtel leak -
https://bgpmon.net/what-caused-the-google-service-interruption/   
see many more examples in RFC 7908 )

A solution component for this has long been discussed in 
SIDR/GROW/IDR and well documented in IDR (see Section 4) 
( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06  ). 
The solution involves AS-A setting a field (in an optional transitive attribute)
in BGP update to indicate that 
(1) it is sending the route to a customer AS (or lateral peer), and 
(2) the route SHOULD be considered a leak if subsequently received
from a customer or a lateral peer.
This is one component of the overall solution.
It has been presented and discussed and I believe accepted
in SIDR/IDR/GROW over the last few years (at least since 2014).

Question: 
>From an operator point of view,
are you willing to place a piece of relationship info (as stated above)
in the BGP update for the significant gain of a route leak solution
that works well to detect/stop route leaks that do happen,
and prevents single point of failures in incremental/partial
deployment scenarios?

Sriram 

P.S. There is already immense BGP-derived public data out there on AS peering relations:

http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=3356&data-selected-id=39 

http://bgp.he.net/AS7018#_graph4