Re: [Idr] operator inputs -- route leak solution

"Neil J. McRae" <neil@domino.org> Tue, 21 March 2017 23:36 UTC

Return-Path: <neil@domino.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610D7129409; Tue, 21 Mar 2017 16:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=domino.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 RSBjPzlRqKkM; Tue, 21 Mar 2017 16:36:46 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0130.outbound.protection.outlook.com [104.47.1.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AF2129496; Tue, 21 Mar 2017 16:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domino.onmicrosoft.com; s=selector1-domino-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RZf1ujktFS/b52i+UMplQhDgJTkeScooLEH3ctIlZlI=; b=T8l0RW3yRd0VEhqlxuBcjo8NAKUC9pqwmPqcDVO0cOPSlEVdsC/LMWsAHeyXs2P8KBDT73KUslDt/19y3wL1lFIeQKSUlCE9jh4DcIGRGEuKX/nP8dhchwXH05Cz57iGd7wknJTyzy5eYippOJ9Au1gE67qUG3UDIAQWNeYGiS0=
Received: from AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) by AM4PR03MB1427.eurprd03.prod.outlook.com (10.164.77.157) 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 23:36:40 +0000
Received: from AM4PR03MB1425.eurprd03.prod.outlook.com ([10.164.77.155]) by AM4PR03MB1425.eurprd03.prod.outlook.com ([10.164.77.155]) with mapi id 15.01.0977.020; Tue, 21 Mar 2017 23:36:40 +0000
From: "Neil J. McRae" <neil@domino.org>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
CC: "grow@ietf.org" <grow@ietf.org>, "idr@ietf.org" <idr@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>, "sidr wg list (sidr@ietf.org)" <sidr@ietf.org>
Thread-Topic: [Idr] operator inputs -- route leak solution
Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4wAMKpth
Date: Tue, 21 Mar 2017 23:36:40 +0000
Message-ID: <A0008923-8026-4D18-BCC1-15D78E3D88C2@domino.org>
References: <DM2PR09MB044656C168037D0BEF7A78CB843D0@DM2PR09MB0446.namprd09.prod.outlook.com>
In-Reply-To: <DM2PR09MB044656C168037D0BEF7A78CB843D0@DM2PR09MB0446.namprd09.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=domino.org;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [107.77.224.155]
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1427; 7:tyTnIuVIwh5JEFjo2h+aFF46ANIfZr8wkDh54mlgbmQzX83VfBID0oPU6MXT50MY5CDxN03uB1HWVd9dIr/BvLQwRCPi6zJvm/Ph9L2qR5gxZTqlOXG7JpsCiZBvG/CDEwTwK9aI0kNCFLyvL3o/moi3rA4E4F4jHwQ0G/66y4LPL+q7BFS+J5eLvct3yn67cE8QaJzosn8HFnku86oTzHYO1dRfcJarXv4vFlstwRsd/58ectVZnePEHqX7/p+Rcxaf6mh/PgrlDLQkcMwmnkwOcbu7lh4wTAsUJpFfS1w79mBVf01sEiQUt8unpU+IdoIk0dcsJ2r64gjng7LQCA==
x-ms-office365-filtering-correlation-id: 07f08d1c-a623-471e-07f0-08d470b3201b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR03MB1427;
x-microsoft-antispam-prvs: <AM4PR03MB142724857A4E23CF2E0E95B3AE3D0@AM4PR03MB1427.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(256337837700080);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(2016111802025)(6072148)(6043046); SRVR:AM4PR03MB1427; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1427;
x-forefront-prvs: 02530BD3AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(24454002)(966004)(2906002)(99286003)(5660300001)(8676002)(82746002)(83716003)(50986999)(53936002)(102836003)(122556002)(25786009)(2900100001)(54906002)(6116002)(229853002)(6512007)(86362001)(38730400002)(6246003)(6306002)(66066001)(3846002)(81166006)(110136004)(4326008)(77096006)(6436002)(6916009)(6506006)(3660700001)(189998001)(7736002)(33656002)(54356999)(3280700002)(2950100002)(76176999)(36756003)(305945005)(53546009)(6486002)(8936002)(8656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1427; H:AM4PR03MB1425.eurprd03.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: domino.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 23:36:40.3569 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1427
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zgYRXaHxLkK5qd2UvSrLXTVDO3o>
Subject: Re: [Idr] operator inputs -- route leak solution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 21 Mar 2017 23:36:49 -0000

It seems a reasonable approach as long as it's kept as simple as described here.

Regards,
Neil.

> On 21 Mar 2017, at 18:00, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>; wrote:
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr