nanog mailing list archives

Re: soBGP deployment


From: Tony Li <tony.li () tony li>
Date: Wed, 25 May 2005 15:51:25 -0700




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


Current thread: