Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

Danny McPherson <danny@tcb.net> Mon, 02 December 2013 02:16 UTC

Return-Path: <danny@tcb.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EFD1AE2CD for <grow@ietfa.amsl.com>; Sun, 1 Dec 2013 18:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.002
X-Spam-Level:
X-Spam-Status: No, score=-100.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, USER_IN_WHITELIST=-100] 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 Fyxaz-OsdULI for <grow@ietfa.amsl.com>; Sun, 1 Dec 2013 18:16:40 -0800 (PST)
Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id A27541AE2AE for <grow@ietf.org>; Sun, 1 Dec 2013 18:16:40 -0800 (PST)
Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 8907A300050 for <grow@ietf.org>; Mon, 2 Dec 2013 02:16:38 +0000 (UTC)
Received: from dul1dmcphers-m1.home (pool-173-72-146-107.clppva.fios.verizon.net [173.72.146.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id A0FA0300049; Sun, 1 Dec 2013 19:16:36 -0700 (MST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B84B7386-793F-4A0B-9C08-41DBA0B9DDC3"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <F19C0DE3-FC3C-432B-B2E0-BF14F45DFA54@apnic.net>
Date: Sun, 01 Dec 2013 21:16:59 -0500
Message-Id: <C7820AD8-3B71-4F5C-B6A7-A80B66E030AE@tcb.net>
References: <20131118230146.22016.28407.idtracker@ietfa.amsl.com> <77143901-5DA3-4937-8162-509B62A61594@apnic.net> <CAL9jLabPjvXaAUaSEyQXdFvSDPZ_bJX4rjGxOGd0BqYhQcQYdg@mail.gmail.com> <FDFB46E9-ECD0-4CFF-A846-2E6FE9F8C9D7@apnic.net> <CAL9jLaaFszKUR0oZe-3gxR8JeFyTAjoe1BmD2ixXnjhvU7Mv5A@mail.gmail.com> <3EEF9354-766C-4687-8DD4-55759B9826CB@apnic.net> <CAL9jLaaEGpJ-B75EAOCCJDG14B8ZWJQ2FK7=AgXt1WQe=5geiQ@mail.gmail.com> <CAL9jLaa5-f4tmPZXSvZXDn640wm6VkfbYqS5qDBdZDVBZuJkXg@mail.gmail.com> <F19C0DE3-FC3C-432B-B2E0-BF14F45DFA54@apnic.net>
To: Geoff Huston <gih@apnic.net>
X-Mailer: Apple Mail (2.1816)
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Sun Dec 1 19:16:38 2013
X-DSPAM-Confidence: 1.0000
X-DSPAM-Improbability: 1 in 98689409 chance of being spam
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: 529bed8642073629792251
X-DSPAM-Factors: 27, 2013+at, 0.40000, WGs+from, 0.40000, I+#+searching, 0.40000, pre+plotted, 0.40000, between+intended, 0.40000, to+#+#+#+to, 0.40000, to+#+#+announcements, 0.40000, to+#+#+#+world, 0.40000, intended+#+announcements, 0.40000, policy+#+#+The, 0.40000, the+policy, 0.40000, and+#+#+#+have, 0.40000, still+cannot, 0.40000, this+#+SIDR, 0.40000, the+mailing, 0.40000, the+#+#+#+announcements, 0.40000, knobs+#+#+routers, 0.40000, something+#+significantly, 0.40000, allow+#+speakers, 0.40000, trying+#+#+productive, 0.40000, routing+#+#+considerable, 0.40000, by+#+folk, 0.40000, one+#+in, 0.40000, Nov+#+#+#+4, 0.40000, announcements+#+#+#+allow, 0.40000, to+#+the, 0.40000, to+#+the, 0.40000
Cc: "grow@ietf.org grow@ietf.org" <grow@ietf.org>
Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 02:16:42 -0000

On Nov 26, 2013, at 4:24 PM, Geoff Huston <gih@apnic.net> wrote:
> 
> I reviewed the mailing lists of all three WGs from November last year, when this came up.
> and I was searching for a proposed methodology of defining requirements, proposing mechanisms
> and standardising one of more candidate technologies relating to the issue of path
> control of the propagation of BGP announcements in order to allow BGP speakers
> to detect unintended announcements. My search of the list archives was unsuccessful.
> 
> As I seem to be the only one interested in an answer, I give up.
> 
> geoff
> 
> 
> (Of course the net value of the entire effort in "securing" a routing protocol that still cannot
> discriminate between intended routing announcements and all forms of routing lies is in
> itself another interesting question, but maybe that's best answered by those folk who will,
> or will not, turn on this particular set of routing control knobs in their routers.)

Indeed…

I’d like to solve the routing security problem and at least get back to where we were circa ’95 (see the IRR policy considerations draft).  The routing security issue IMO is ultimately a routing policy issue (coincidentally, as is the inter-domain anti-spoofing problem).   The reason people don’t do these things is because they didn’t have some form of resource certification to manage staleness/integrity/automated configuration/etc, etc..

As Russ points out we tried to address this in SIDR and it wasn’t in their carefully crafted charter.  BGPSEC work ignores the policy aspects, tightly couples resource certification with inter-domain routing, and slams RPKI directly into the routers and routing system, introducing considerable new external dependencies and overhead and little capability for autonomy and “buffers", and IMO, will be “challenging” to in the real world.  I’ve burned enough cycles trying to be productive there, all to no avail.  I do believe that eventually, the only way a global resource certification infrastructure will be fully employed is if it’s only loosely coupled to the routing system.

I would like to see the IETF address the routing system security issues in a manner more cognizant of operational, business, and geopolitical realities, but have found immense cycles ineffective at influencing a carefully pre-plotted course, and until something changes significantly I know of at least one operator that will focus elsewhere with other mechanisms and our resources.

-danny