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:
- Re: soBGP deployment, (continued)
- Re: soBGP deployment Randy Bush (May 24)
- Re: soBGP deployment Tony Li (May 24)
- Re: soBGP deployment Daniel Karrenberg (May 25)
- Re: soBGP deployment Tony Li (May 25)
- Re: soBGP deployment Jeroen Massar (May 26)
- Re: soBGP deployment william(at)elan.net (May 26)
- Re: soBGP deployment Todd Underwood (May 26)
- Re: soBGP deployment Bill Woodcock (May 26)
- Re: soBGP deployment Bill Woodcock (May 26)
- Re: soBGP deployment Steve Gibbard (May 25)
- Re: soBGP deployment Tony Li (May 25)
- Re: soBGP deployment Steve Gibbard (May 25)
- Re: soBGP deployment Todd Underwood (May 26)
- Re: soBGP deployment Daniel Golding (May 26)
- Re: soBGP deployment Randy Bush (May 26)
- Re: soBGP deployment Tony Li (May 26)
- Re: soBGP deployment william(at)elan.net (May 26)
- Re: soBGP deployment Todd Underwood (May 27)
- Re: [s,o]BGP deployment bmanning (May 27)
- Re: [s,o]BGP deployment Randy Bush (May 27)
- Re: [s,o]BGP deployment Lucy E. Lynch (May 27)