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

From: Danny McPherson <[email-masked]>
Date: Sun, 1 Dec 2013 21:16:59 -0500

On Nov 26, 2013, at 4:24 PM, Geoff Huston <[email-masked]> 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

---

From: Jared Mauch <[email-masked]>
Date: Mon, 2 Dec 2013 06:31:05 -0500

> As I seem to be the only one interested in an answer, I give up.

At $dayjob, we have a list of ASNs that we shouldn’t see from our customers.  We work to update
our AS_PATH filtering to match these as the network evolves.  Our AS_PATH filtering may be
different than your list.

The biggest problems I’ve seen/observed are:

a) People put stuff into an IRR and it never comes out
b) Routers lack sophistication in configuring policy (or the configured policy blows out its config/memory/structure space)
c) Customers will pay to not be filtered at all
d) Networks don’t care to address issues (e.g.: AS-FLAGT expands to how many routes?)

This is a hygiene issue like showering and brushing your teeth.  Vendors figure it’s an operator problem (then freak out when we show them the scale).  Customers and peers don’t address the tragedy of the commons.

We’re left with little traction to put ourselves on a trajectory for a fix as the average BGP speaker is an IOS devices that still today sends/receives all routes learned by default with no policy configured.

- Jared