To be clear: IANA and RIRs allocate or assign address space
today, they don't control any routing on the Internet (and
their own internal ASNs and IPs don't count).
And that gets to the heart of the issue that I raised. Since
the RIRs allocate ASnums and IP address blocks, they are in
a position to validate who has the right to use the numbers.
And if you want to validate who has the right to announce a
specific address prefix, you really want to start by determining
who owns the prefix, and then go to them and find out what rights
they have delegated.
This puts the RIRs at the root of the validation chain. Although
you could attempt to build the rest of the system, without formal
validation by the RIRs, you still have holes that you can drive
a truck through. That is the experience of projects like IRR/RADB
etc.
Rather than rushing off and hacking up some code, is it possible
for a group of network operators to meet formally, in some venue
or other, and set out the requirements for such a system and the
architecture of such a system?
No really, the reason for some leaks isn't because so-and-so was
never a customer, they were. 5 years ago. nobody removed the routes from
the IRR or AS-SET or <insert method here> and now the route is learned via
some other location and it's bypassed your perimiter security and
infiltrated your BGP.
The issue of cleaning up legacy state for former customers applies to
many things beyond route announcements - though the latter may be one
of the more visible remnants. I suspect relatively few companies can
accurately and completely track the state associated with a customer
such that it can be removed once the customer billing stops. (Or they
stop paying.) This really needs to be automated and the backend
databases need a way to associate records with particular billing
entities, or else you will find yourself slowly cleaning up after past
customers at inconvenient moments for years.
No really, the reason for some leaks isn't because so-and-so was
never a customer, they were. 5 years ago. nobody removed the routes
from
the IRR or AS-SET or <insert method here> and now the route is learned
via
some other location and it's bypassed your perimiter security and
infiltrated your BGP.
I agree, how many of you folks that use IRRs have
ever deleted an IRR object? Heck, some ISPs even
add them based on existence of advertised routes.
Agree, IRR objects do get dirty and require cleaning up,
The company I work for makes a good effort at this which
starts by measuring how dirty they are:
The problem is caused by a combination of both us and our downstreams
not cleaning properly.
Over the past few months I've been working on a personal project to
clean our IRR objects by making the system which generates them talk
closer to the system which bills people. (*)
Part of this work has meant going through the pain of providing an
internal WHOIS service since we decided that it was the best way of
storing data without re-inventing the wheel.
This said, if you are not using IRR (at least for your customers) then
PLEASE START DOING SO, you'll have plenty of time to worry about keeping
it up to date once you can get you or your organisation to grips with it.
Dave.
* if you are interested you can compare AS-CLARANET macro in the ripedb
with AS-CLARANET macro in the ripe testdb (test-whois.ripe.net), This
object will launch in the next few weeks.
No really, the reason for some leaks isn't because so-and-so was
never a customer, they were. 5 years ago. nobody removed the
routes from
the IRR or AS-SET or <insert method here> and now the route is
learned via
some other location and it's bypassed your perimiter security and
infiltrated your BGP.
I agree, how many of you folks that use IRRs have
ever deleted an IRR object? Heck, some ISPs even
add them based on existence of advertised routes.
-danny
Even better, how many have tried to get another provider to remove legacy
objects from days gone by when someone was adding objects on your behalf? I
have objects that date back to 1998 that are completely bogus and I can't do
squat about it.
On that topic, how do you delete IRR objects when the person who created them used a unique maintainer object and is no longer around to provide the password for the maintainer object?
Absent any kind of network wide enforcement, why don't you just roll participation and compliance with this into your peering contracts, with propagation? Require your peers to have it, and ask that they pass the requirement on. This isn't rocket science, clearly, because even I understand it. All it takes it a couple of larger entities to set the bar, and drag everyone up. Some of this may amount to teaching your peers to fish, but if everyone wins, thanks for contributing.
Require peers to support IRR objects.
Require them to have an alias that points at an always existing human.
Require them to maintain their entries.
And then do it yourself so they can see how it's done.
Absent any kind of network wide enforcement, why don't you just roll participation and compliance with this into your peering contracts, with propagation? Require your peers to have it, and ask that they pass the requirement on. This isn't rocket science, clearly, because even I understand it. All it takes it a couple of larger entities to set the bar, and drag everyone up. Some of this may amount to teaching your peers to fish, but if everyone wins, thanks for contributing.
Require peers to support IRR objects.
Require them to have an alias that points at an always existing human.
Require them to maintain their entries.
And then do it yourself so they can see how it's done.
The business process would read:
"New procedures will reduce the operational cost of our operations by xx%".
"All peering contracts renewed or executed after [date] will comply to document xxxx".
Revised customer IP provisioning procedures:
"Insert new customer IP info into our local IRR. Customer IPs will not work if this is not done."
"Press here to cause us to spin our configuration builder."