On Wed, Aug 13, 2008 at 04:52:46PM -0400, Patrick W. Gilmore wrote:

On Aug 13, 2008, at 4:48 PM, Jared Mauch wrote:

...

On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote:

...

The italian courts seem to have told ISPs there to block ThePirateBay (bittorrent tracker), and this evening (CET) LLNW (AS22822) originated 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of Europe.

Basically same thing that happened when people tried to block YouTube a few months back (afghanistan?).

How do we hinder this in the short term? I know there are a lot of long term solutions that very few is implementing, but would the fact that these mistakes are brought up into the (lime)light by a public shaming list make ISPs shape up and perform less mistakes?

I am still waiting for a response from LLNW NOC on the issue.

Sure. I'd also like to see providers actually just shut off customers that originate stuff like ms-sql slammer packets still. But it keeps flowing. I'm sure there are smurf amps and other badness still going. codered anyone?

these are all issues, but operational? depends.

I beg to differ, this is absolutely operational.

So, I should shut down or depeer networks that continue to originate the crap to me? (packets, announcements).

...

If LLNW is not being filtered by telecom italia, time for 6762 to fix that. If they persist, will you depeer them as a security risk until they clean up their act?

De-peering won't help if someone is propagating it as a transit customer route. Filtering the prefix is all you can do.

Taking this example, if I were to depeer 6762 becuase they can't keep their routing table clean to me, I suspect they would look at how to fix the issue. I could just filter their as-path globally until they contact me to resolve the issue. I'm not saying I would actually do that, but there is a question of what level of action should be taken to resolve these issues, and a timescale for their resolution. I've found some networks excellent to work with, and others "we'll stop leaking to you in a few days once we finish escalating the issue to our tier-n NOC in XXX city". Honestly, I find that to be kinda lazy considering how critical the routing infrasturcture is for our survival as an industry.

P.S. Obligatory BCP38 shout-out, even though it's not exactly on-point.

I can't agree with this more, If you're not doing u-RPF on your customer interfaces (t1, ds3, ge, fe, colo, etc..) you should be. The only excuses are broken software or incapable hardware from your vendor. Sadly those last two seem to impair the ability to take these basic network security requirements into account for a network of any size. It'll help reduce the possible attack home-base for various spoofing attacks (including some DNS one, did you hear about it?) - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Wed, Aug 13, 2008 at 05:14:43PM -0400, Patrick W. Gilmore wrote:

Saying something is Operational (and on-topic for nanog) does not mean you should de-peer them.

If it's active and persistent, it would qualify as operational. Then I can classify the risk. I'm openly wondering if there should be more aggressive "turn the bad stuff off" happening.

That said, I will not stop you from de-peering a network who can't keep its table clean. Your network, your decision.

I'm still seeing persistent leaks, generally over 10k/day that are unresolved after a year of collecting this data.

You wield a much bigger hammer than 99.999% of the people here, and you know it.

I'm not posting as my employer, nor purporting to represent them, but at the same time, wonder what the impact would be if there were more consistent actions taken by networks when there was badness, either routing leak or otherwise.

While I doubt "shame" will work in all but the most extreme cases, I believe brokeness does, eventually have an impact. Let's just hope that impact is not blunted by (for instance) monopoly power, so that "voting with your wallet" will force network to fix things.

I certainly agree on the impact. If there were clear and predictable reactions to the brokeness, would people actually take actions to repair the problem? eg: 200.1.15.0/24 2914 6762 27648 3561 5511 6505 27782 What If I were to respond with a bgp notify (invalid as-path) to 6762 when they send this route to 2914? Doesn't matter if they're a customer or a peer, i may not want to get 3561 routes from you.

Just thought I'd say "BCP38" again.

Router#conf t Router(config)#interface customer0/1 Router(config)# ip verify unicast source reachable-via rx - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.8 (Darwin) Comment: http://getfiregpg.org owFdVAtsFFUUbRdaZRIoQfkUxLzwaRHWbgtIC0RA8YNfsEBAIJTZmbe7r52ZN857 s8tWgSIoUiqoAUUQlE8aAxYrgUpbqKCQEotSykeCKRLoR2qBQspXqN43uy3iJvub ue/cc849dz7q2inGFbtZH3r58It/SbFFnZd5E9OGp2WkD89IHT1iZPoon9/0Z3Hd fIFoeNLWKR+bsqVSA+lhRPwGtWRDwW4kM0SQLoeRQTkKyEGMeAAjPN/EFsFQgbJ0 yngWoj4UpjZSqUQMpwRNnYIUquu2QXg4JUWSvDZ3o1AgjELU1lQjmSNGdcwDxPAj jeRg5KOWLmtaGFn4LZtYcF1SbMahyGIeE4tPDqwY4cyDuYI4jRCyZNWLqDcbK5wJ vjJKjiBgHRs8WQJcJI4DoKcdEHn9JmLYChIFM0kiEfayheG0gUOoo042VOcWA0+Q bQqS4qwbEY4IQ4qGZUsLS4zLHKsoql2hBjBVQK/zL4rlMS0aJCqACnqYcaEc9LN2 IpIOlWA2MTi8OyQJfcLAKDgxoJmmIUAD7gyY+B5oAzPA7P64/uuOW4rIZoxQA4Cx 6IVYwOYqDYE8gxPNwepgGgTbfATwHJ5ghuTHBrZALEM+onEYCgoRHkCWyeAopZok MVnHyC9ItDvPUlIQaQ+ImHx0Ph1GOXMTlEGYZGAeolYOg1o3yhaWtJcTy0KeBwRF eFEDOxn1wheFOgijLJmgzY0gdVAjQwcneoKYCA5TLGJyRxGSbfBN5mAJ0JQkAAIc kc0ImOASySwkA2YMp+G+KnrCT2ww23IMg41A4CKoDRBTEsAq1rDfARaMDFv3OrNn 1LZgciIsQkuEIxGIgioxchzCUqSlQwWpxOcjiq2JDXIuEz7eSa0mW34A7bBMVmWT R0j+b7uEUZCVaAcTU1PD0R6QJ4uLIz6qaTTkLD2kILqpkRgZFCkBCiEFRopsM1hw UXKfpQIiqM+HfBbVkYItJ8IWtbnYLyVgEci7bEjwWu56rHNMrCsmPs4lHjsxUpfu 7U+p2pXdY75SFkw+sun0cy1fr8lM/nxYy8XqtsqB42d7PIfVYxcaugz+YntLQlLL kJwjeyuaTTm9sltXd9PBM32nHm1a96d747WaksYt+/6+caX+6oTzK0mBJOUdLFnU q/fD5rvo6MWGTzJLty8Z8PLc87HNavbapJrcn/tfdI2cdS63Z1v5zSmZcROWZyT0 Oj33UlvtvYlLdi3Ox+xkuPX4zpl3d1c9m/HmjTv6zazc1Y2XTzTUlI1uXVx6+OSq 4s+qV2zdv35m0TjfvarypfUHnnu6esGovWOK59zZU53Xv++oc0m329K7zPhDrs3O rnlm4uC6hvz0D07FVaQeK/zuajCnZMSXiSvrfqnaOzmp6PrQ+cWDzu6c/cqR3AsD 4u9OOr79UM9riwt6lO7Zb259Ku/x0etKEwb3PacU9tbDtn0w0A03DfNuejVYeaso Z/rYK7OW5GZe/SF/w+59q6f1KziwZmBqn22tg25nTGupO3PiypyU4K45aYGCIWWP bk4oWVRc2Hxt16eb0/plNZsnvlk7fE1i2q1izyOX3rlZGfj2cn3F1NCCspcS/Xzc 6t/jY8sXxldU9yx86P15bzTX//jkoaE/uV6L37cjY9l7qQs7xbW2VpV5l45Z9XZt UfeJeuPrfda6zuaFq3L92+zG8tRt10/N80+/x71jd1yy19ecbdqy7vtFckz6zBnm 6X+S5i37sFeP5/NPbazb0Gnhiid8v/72Lw== =TITY -----END PGP MESSAGE----- On Thu, Aug 14, 2008 at 11:03 AM, Randy Bush <randy@psg.com> wrote:

ok, i can not hold my tongue. sorry.

might there be a formally rigorous approach to this problem? we keep having it. perhaps there is something solid and real we could do, as opposed to temp hack after temp hack.

randy

but, why wouldn't something like formally requiring customers/peers/transits/etc to have radb objects as a 'requirement' for peering/customer bgp services

'Cause there ain't nobody out there to "formally require" this. Other than ISPs, of course. And that means there will be umpteen different sets of rules, one set for each ISP.

if you are a new customer and you sign up for bgp, it is clearly stated in the contract, the customer/provider requesting this service must maintain objects radb..

In that case, no problem. But what about the contracts that do NOT state this? Who will change them? What language will they use? Who will coordinate the changes so that there is something halfway consistent? This is the problem Randy refers to when he talks about formal rigour.

if larger networks adapted to something like this, i think people would start to follow, as they would have no choice because they would be cut off from certain routes

Larger peers started this way back about 15 years ago. Very few followed suit. What makes you think this will change? Operationally, the Internet is an anarchy. There is no formal organization of network providers that will set up working groups to define best practices in routing, in peering, etc. Instead, we have some areas where there *ARE* organizations applying formal rigor like email with MAAWG but that only happens with the real hot button issues. Everything else is left to simmer away in the anarchy. In Europe, the network operators that are also in the telecoms business, formed an organization called ETSI http://www.etsi.org to address a whole raft of inter-operator issues primarily focused on standards. There is no good reason why operators with Internet transit businesses should not form a similar organization to tackle the problems that come back again and again on the NANOG list, with only half measure and short term bandaid fixes being developed. You will note, that when ETSI was formed there was already an international telecom standards organization in operation called the ITU. But it had issues, and so folks went off and set up something that was more workable. When will NANOG participants smell the coffee and do likewise? The FCC will not rescue you. --Michael Dillon

On Aug 14, 2008, at 9:02 AM, Randy Bush wrote:

bottom line: the irr is a hack, not a formal solution.

I don't think the IRR is so much a hack (it's a tool), but we're lacking the process and infrastructure to vet/validate that a given ASN is *authorized* to originate a prefix, and all of the policy bits (which the IRR has if you use it) associated with which ASNs should propagate the prefix, etc... We're lacking the authority and delegation model that DNS has, I think? -b

On Thu, Aug 14, 2008 at 11:47 AM, brett watson <brett@the-watsons.org> wrote:

We're lacking the authority and delegation model that DNS has, I think?

Depends who you ask. Some think applying the dns model to bgp (i.e. within protocol) will ultimately place too great a burden on routing hardware & associated 'state' infrastructure. I tend to agree with that position. Perhaps the model we ought to be considering is something more akin to an external mechanism that automated systems (i.e. things to crank out prefix-lists/as-path lists) could draw from during 'refresh' periods, solely dedicated to authorizing prefixes against origin asn and/or as path (or name your $permutation_here). I.e. if said new system were to fail, it'd be great if it didn't affect routing in any way (we can live with a few days of stale lists, I think). Greene/Schiller, pipe up - this is your torch, right? -Tk

On Aug 14, 2008, at 11:30 AM, David Conrad wrote:

On Aug 14, 2008, at 9:47 AM, brett watson wrote:

...

We're lacking the authority and delegation model that DNS has, I think?

If one were to ignore layer 9 politics, it could be argued the authority/delegation models between DNS and address space are quite analogous.

TODAY IANA has an operational role in DNS, they don't have an operational role in Internet routing. This is certainly not layer 9, and most certainly the most fundamental change to the Internet routing system that RPKI or similar systems would introduce. 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). -danny

On Aug 14, 2008, at 10:59 PM, David Conrad wrote:

Yep. IANA does indeed have a limited operational role in the DNS (in that currently IANA directly operates .int, ip6.arpa, urn.arpa, uri.arpa, and iris.arpa) and no direct operational role in routing.

Of course, the statement was about the authority and delegation model, not about operational roles. ... Not sure it is 'the most fundamental change', but it is indeed a significant change. That's sort of the point: RPKI is designed to allow for validation which isn't possible now. ... Indeed. And if RPKI is deployed in a way that is useful for validation of routing announcements in real time, this will obviously change, regardless of whether there is a single root for the address space or multiple roots. However, it seems to me that the decision as to whether there is a single root or multiple roots is deeply rooted (pun intended) in layer 9.

But perhaps that's just me.

OK, so we were talking past one another. I agree with everything you said above, and simply meant to highlight the fact that RPKI validation will change things (quite necessarily, IMO), and folks need to be paying attention to this. -danny

michael.dillon@bt.com wrote:

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?

--Michael Dillon

You might want to take a look at the IETF SIDR working group's efforts. Robert

On Aug 14, 2008, at 11:13 AM, <michael.dillon@bt.com> <michael.dillon@bt.com

wrote: ARIN holds the top of that authority and delegation hierarchy because they give out the ASnums and IP address blocks.

And here I thought IANA handed out ASnums and IP address blocks to ARIN (and RIPE and LACNIC and AfriNIC and APNIC and the IETF for specific protocol requirements)... Regards, -drc

On Aug 14, 2008, at 12:15 PM, <michael.dillon@bt.com> <michael.dillon@bt.com

wrote:

...

And here I thought IANA handed out ASnums and IP address blocks to ARIN (and RIPE and LACNIC and AfriNIC and APNIC and the IETF for specific protocol requirements)... We are talking Internet operations, not Internet politics.

Indeed.

People don't care where the numbers came from, they care who actually got the rights to use them, and then what those orgs did with the rights, i.e. an IP addr block owner may delegate the rights to announce a subset of their space to a specific ASnum holder.

Yep. And as with DNSSEC, you, as a network operator, get a choice. You can configure a single trust anchor corresponding to the actual address allocation flow and follow a chain of authority down to the leaf (end user or ISP) allocation or you can configure a number of trust anchors and figure out how to deal with cross-certifications resulting from the multiple roots. Ignoring politics, the technically and architecturally cleaner approach is obvious to me. However, as I mentioned, it is challenging to ignore the layer 9 politics. Regards, -drc

On Thu, 14 Aug 2008 22:42:04 -0400 Jean-Fran__ois Mezei <jfmezei@vaxination.ca> wrote:

Pardon my ignorance here, but wouldn't it be much simpler if the so called "tier 1" networks were to do the filtering work so that none of downstream BGP peers would see the bad announcements ?

If some network in italy sends out some bogus route for a site, this should be blocked by a few tier 1 networks instead of by everybody at the bottom of the tree. Yeah, that would mean that folks in italy and whoever would have direct connections to that italian network would accept those bad BGP announcements, but the rest of the world would continue to work.

"tier 1" networks like to brag about their importance within the internet, perhaps filtering bad announcments should be a responsability assigned to them, and which would further differentiate them from lesser networks.

Many of them -- most of them? -- do filter, to the extent that they can. However, they're in a poor position to do a complete job. If your peer is an end site, it's easy to filter what they send you; you know (or should know) what address blocks they have. (Verifying that they actually have the right to announce such blocks is a separate and difficult question, but I won't get into that here.) But what if your peer is another Tier 1, or even a lower-level ISP? How can you filter then? Another ISP can, will, and should announce routes to all of its customers, and it's quite hard (impossible, really) for the Tier 1s to track their peers' customers. Worse yet, some of these customers may themselves be ISPs, with their own customers. And if the peer of a Tier 1 is another Tier 1, it's not even possible to imagine how they'd know. --Steve Bellovin, http://www.cs.columbia.edu/~smb

On Thu, 14 Aug 2008, Steven M. Bellovin wrote:

Many of them -- most of them? -- do filter, to the extent that they can. However, they're in a poor position to do a complete job.

What I would like is to be able to filter prefixes on the basis of the AS-path/prefix combination, and have this in a signed fashion. So let's say an ISP has AS1 and their upstreams are AS2 and AS3. They have 10.0.5.0/16. They will then publish a routing policy that AS* (any AS) should only accept 10.0.5.0/16 originated from AS1, and no more specifics, but AS2 and AS3 should accept more specifics down to /24 (for granular traffic control). For this to be secure, I guess the announcement needs some kind of cryptographic verification, but I don't know much about that, but that should be used as well, but even without it we stop the possibility of human error announcing breakouts or that /16 by someone else. Now, building existing prefix/AS-path lists based on the above information isn't feasable. We have ~30k ASN live and 270k prefixes so the amount of lines in a config is just unfeasable, which means we need some kind of new strategy to handle all this policy information. I guess having some kind of policy server which receives routes and then can tell routers to ignore them if they don't adhere to policy might work if the routes seen which is not according to policy are few, but if they become many then we run into the same scaling problem again. So perhaps this problem can't be solved by anything existing, but instead we need new functionality in our routers to handle this problem? So time to market on this is in the years, but if we don't start work on it it'll never get done. But I do feel that any long-term solution needs to be distributed and implemented on a per ASN basis, where participating ASNs doesn't have to be directly connected to each other... -- Mikael Abrahamsson email: swmike@swm.pp.se

but, why wouldn't something like formally requiring customers/peers/transits/etc to have radb objects as a 'requirement' for peering/customer bgp services

Step 1 : Enforce IRR for customers *now*. Step 2 : Enforce trusted replacement for IRR when available Step 3 : Profit Not progressing to step 1 today because you think IRR isn't the best solution is like not deploying IPv6 because you sat on your arse not deploying it all these years and justify yourself by denouncing the protocol on every mailing list and IRC channel at every available opportunity. Dave.

On Aug 14, 2008, at 11:21 AM, David Freedman wrote:

...

but, why wouldn't something like formally requiring customers/peers/transits/etc to have radb objects as a 'requirement' for peering/customer bgp services

Step 1 : Enforce IRR for customers *now*.

Right, but I think the bigger issue is not just that "data is in the IRR" but rather "the data is there, and "some organization" has validated that 1) the "owner" is authentic, 2) they own the prefixes they entered, 3) they are authorized to originate the prefixes, and 4) the policies they entered are valid and agreed to by the other parties." We have to be able to *trust* the data in the IRR, which I assume is one of the biggest impediments to being used by everyone: who's going to validate all that data and how will they do it? -b

On Aug 14, 2008, at 1:09 PM, Jared Mauch wrote:

You're missing a step:

janitor.

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

...

janitor.

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. Mike

On Sun, Aug 17, 2008 at 03:44:40PM -0400, Jon Lewis wrote:

On Thu, 14 Aug 2008, Danny McPherson wrote:

...

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.

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?

This is what the human at most db-admin aliases is for. I know that we staff humans behind our alias to respond to such queries. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Sun, 17 Aug 2008, Jared Mauch wrote:

...

...

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.

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?

This is what the human at most db-admin aliases is for.

I know that we staff humans behind our alias to respond to such queries.

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. - billn

Jared Mauch writes:

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. Joe

On Wed, 13 Aug 2008, Mikael Abrahamsson wrote:

We have prefix-filters on our customer bgp sessions, so that should be fairly safe, but I see no good way of doing this towards peers as there is no uniform way of doing this, and there is no industry consenus how it should be done.

Read your peering contract with the other ISP. It should cover what to do if this happens. What? you don't have a peering contract with the other ISP. Well I guess there is no requirement to keep the peering session established if the peer does stuff you don't want on your network. If it hurts when you do something, why do you keep doing it?

On 2008/08/13 11:11 PM Randy Bush wrote:

...

Can't IANA give $100000 stupidity tax

perhaps those of us in glass houses should not suggest a major throwing of stones? :)

Point taken ;)

On Thu, Aug 14, 2008 at 08:03:28AM +0200, Mikael Abrahamsson wrote:

On Wed, 13 Aug 2008, Mikael Abrahamsson wrote:

...

How do we hinder this in the short term? I know there are a lot of long term solutions that very few is implementing, but would the fact that these mistakes are brought up into the (lime)light by a public shaming list make ISPs shape up and perform less mistakes?

My thoughts on the prefix filtering issue would be that we need some kind of system that works along the same principles as DNSSEC and SPF, ie a holder of IP space can publish that they would like everybody to filter in a certain way for announcements for that perticular prefix, and then the other end can do so if they want to. This needs to be automatic and quick, ie a change in RADB policy should be reflected in the real world in minutes (preferrably) or hours (more realistically perhaps) and not in days or months.

There was an idea years ago about utilizing a domain (rdi.int) for this. eg: dig any 267.rdi.int.

This might already be in place, I don't know other than RIPE, but in RIPE you can register a route object with a certain IP space, and IP space can have multiple route objects. The thing here is that to implement this

Herein is the value, the RIR (RIPE) is also the holder of the policy. With ARIN, this is not the case, there is RADB and a number of other RR's that are out there for varying reasons, some personal and some business.

policy in IOS creates *huge* rulesets that are really cumbersome and cluttery. Also, people tend not to rebuild these very often, so for customer routes, doing a handover between ISPs when moving PI space might involve outages and days of limited connectivity. Also, change of policy doesn't isn't reflected unless a route is cleared (soft though) which involves re-hashing a lot of routes very often if filters are updated often.

I think in this web 2.0 world, everything you're speaking of can be a challenge but not be impossible. The problem I see is there are no good tools. Take http://prefix.pch.net/ for example. This can help you audit the routes that are going to be placed in a prefix-list. How do you integrate something like this into your business policy? Have customers submit a web form for their routes? It's easy when your customer is AS267, but what if your customer is something larger like telstra?

Perhaps it's too late for IPv4 in this aspect, but it might be feasable for IPv6? Fewer prefixes and (hopefully) no break-outs, would mean PA

I think it's a matter of having a semi-uniform industry policy that is generally agreeable. I don't want to see the ANS-days case where you could not route without RADB and some fancy scripts probing their bay networks devices with snmp sets. But I do agree that we need a better toolset built. Now the question is, who can/will do this? How can it be shared? If I can make this backend uglyness called "RADB/irrd" invisible to my customers, will that help?

blocks could be filtered hard, and if larger ISPs do hard filtering based on RADB, ISPs getting into IPv6 would need to get their prefixes properly registered there before getting IPv6 working to any extent.

Anyhow, as people are continuing to use null routes to enforce regulatory demands (likely cause for the latest outages) this problem will most likely escalate.

This would also help with <http://eng.5ninesdata.com/~tkapela/iphd-2.ppt> problem I guess.

Yeah, the challenge here is those that are unwilling to take action threaten the entire industry as it only takes a few bad actors to disrupt the network currently, and if you do it correctly, who is going to trust the infrastructure that we operate? - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.