do not filter your customers

Fri Feb 24 22:06:31 UTC 2012

> -----Original Message-----
> 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".