[81105] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: soBGP deployment

daemon@ATHENA.MIT.EDU (Tony Li)
Wed May 25 18:52:22 2005

Date: Wed, 25 May 2005 15:51:25 -0700
From: Tony Li <tony.li@tony.li>
To: Steve Gibbard <scg@gibbard.org>
Cc: nanog@nanog.org
In-Reply-To: <20050525113700.K27132@sprockets.gibbard.org>
Errors-To: owner-nanog@merit.edu




Steve,

> I know all the issues up there are real, since I've occasionally heard
> about them happening.  I understand the devastating consequences of
> somebody finding a sufficiently well connected unfiltered BGP session
> and using it to announce some important prefixes.  I fully agree that it
> should be fixed.
> 
> And yet, in the nine or so years I've been working on network
> infrastructure stuff, spoofed BGP announcements have never been a major
> cause of problems for me.


That's what we can say so far.  Do you really want to wait until we have
a major problem?

The time to replace the cockpit doors was PRIOR to 9/11.


> Therefore, when somebody tells me they're going to make the Internet
> more reliable by adding more things that need to be done right to make a
> BGP announcement work, I get a bit apprehensive.  When they further tell
> me it's going to get centralized, such that I'd no longer be dealing
> with multiple peers or upstreams maintaining multiple sets of filters
> that can be expected to not all break at the same time, I get even more
> nervous.
> 
> I hope any solution that finally gets settled on for this is done with
> the recognition that the goal is to reduce outages overall, rather than
> trading one outage cause for another.


Once again, I ask you to look a bit harder at the details before passing
judgement.  Incremental deployment of any authentication scheme can and
must be done so that there are three classes of BGP paths:

	authenticated paths (highest preference)
	unauthenticated paths (next, still used)
	authentication failures (recorded, dropped, alarms triggered)

If one does NOTHING, then your prefixes remain unauthenticated and used.
 Thus, there is no additional work to making a BGP announcement work.
The additional work is only to make the announcement _secure_.

Further, we will need to use multiple certificate authorities (for
redundancy alone), with various certificates flying around from
differing places along the AS path.  So there's nothing about these
schemes that is centralized from an operational sense.  If your concern
is that address space allocation is hierarchical, rooted in one of the
RIR's, then this is not a new issue.

Tony


home help back first fref pref prev next nref lref last post