mailing list archives
RE: do not filter your customers
From: George Bonser <gbonser () seven com>
Date: Fri, 24 Feb 2012 22:06:31 +0000
From: Leo Bicknell
Sent: Friday, February 24, 2012 1:00 PM
There are plenty of cases where someone "leaks" more specifics with
NO_EXPORT to only one of their BGP peers for the purposes of TE.
The challenge of securing BGP isn't crypto, and it isn't enough
ram/cpu/whatever to process it. The challenge is getting a crypto
scheme that operators can use to easily represent the real world.
It turns out the real world is quite messy though, often full of
temporary hacks, unusual relationships and other issues.
I'm sure it will be solved, one day.
I can think of a way to do it but it would require some trust and it would require that people actually *used* it.
What one would do is feed the routes they are proposing to send to a BGP peer to a RIR front-end. The receiving peer
would "sign off" on the proposal and the routes would be then entered into the RIR. That is the step that is currently
missing. Anyone can enter practically anything into an RIR and the receiving side never gets to "sanity check" the
information before it actually gets written to the database. Once you have this base of information, route filtration
generated from the database becomes more reliable.
In fact, a network might have several "canned" profiles of different route packages registered in the front end. A
"transit" package, a "customer routes" package and maybe some specialized packages for peering at various
private/public exchange points. If you pick up a new peer at a transit point, you select the package for that point,
it proposes that to the peer, peer approves it, and they can both generate their route filters from that information.
It could even highlight some glaring errors automatically to spot what might be a typo or even attempted nefarious
activity. The receiver of a proposed change might be alerted to the fact that the new route(s) being offered are
inconsistent with the database information (routes already being sourced by an AS that the proposed sender is not
peering with) which could be overridden by the receiver (or just ignored) but having something show up in some way that
highlights a possible inconsistency might generate a closer look at that proposal and head off problems later.
But the fundamental problem is that the current system is "open loop".