[150474] in North American Network Operators' Group
RE: do not filter your customers
daemon@ATHENA.MIT.EDU (George Bonser)
Fri Feb 24 17:07:28 2012
From: George Bonser <gbonser@seven.com>
To: Leo Bicknell <bicknell@ufp.org>, North American Network Operators' Group
<nanog@nanog.org>
Date: Fri, 24 Feb 2012 22:06:31 +0000
In-Reply-To: <20120224205950.GA87433@ussenterprise.ufp.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: Leo Bicknell=20
> 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.
>=20
> 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.
>=20
> 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 rout=
es they are proposing to send to a BGP peer to a RIR front-end. The receiv=
ing peer would "sign off" on the proposal and the routes would be then ente=
red 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 data=
base. Once you have this base of information, route filtration generated f=
rom 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 rout=
es" package and maybe some specialized packages for peering at various priv=
ate/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 a=
pproves it, and they can both generate their route filters from that inform=
ation.
It could even highlight some glaring errors automatically to spot what migh=
t be a typo or even attempted nefarious activity. The receiver of a propos=
ed change might be alerted to the fact that the new route(s) being offered =
are inconsistent with the database information (routes already being source=
d by an AS that the proposed sender is not peering with) which could be ove=
rridden by the receiver (or just ignored) but having something show up in s=
ome way that highlights a possible inconsistency might generate a closer lo=
ok at that proposal and head off problems later.
But the fundamental problem is that the current system is "open loop".
