soBGP deployment

Tony Li tony.li at tony.li
Wed May 25 22:51:25 UTC 2005




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




More information about the NANOG mailing list