On Monday, February 06, 2012 01:14:20 PM Christopher Morrow wrote:
o not having filters at all (pccw/pktel)
Well, we know what this leads to (part of the reasons you find some eBGP sessions carrying /25's or longer + RFC 1918 space is because of this).
o filtering using old/stale data (ntt/l3)
Well, we think that this problem resolves itself rather well: o If a customer is not getting traffic hitting a prefix, they'll check with their upstream on if their prefix is being received and propagated. o If a customer is not seeing their prefix on the Internet, they'll check with their upstream on if their prefix is being received and propagated. o If a customer starts announcing a new prefix without updating their upstream, one e-mail or phone call to the upstream will get this fixed. In all cases above, it's better not to have an unauthorized prefix in the yonder than have open filters, because one is more likely to quickly get resolved without any colleteral than the other.
why aren't filters applied at all? ("its hard, people keep asking me to update them, bah! work!")
Well, so was running the Internet without BGP communities or prefix lists or AS_PATH filters, until they appeared. And while some folk still use so-called "distribute lists" today, it's fine with me as long as they maintain secure operations with whatever solution they choose, hard or easy. Some ISP's have automated this process either by using internal IRR software, or scripting web GUI's that their NOC can use to simply stick in the prefix, select which router to update, and bam! Compared to the alternative, this is a small price to pay.
why aren't filter data bases kept up to date? ("its hard, i have to email something to radb/altdb/etc... bah, work!")...
That's why we use the RIPE RR. They have a cool web GUI that you can use to edit on object, including IRR data (and they're respected by all other major RR's and operators): https://apps.db.ripe.net/webupdates/ It certainly beats the old "MAIL FROM" system, although I believe that is still operational.
why aren't checks of the filter data simple and mechanical? (and accurate?) ("Bah! work! plus, have you looked at the ouptput? bah! work!")
See above. We manually check the RIR WHOIS database. I'm sure some networks might automate this with an internal system that checks the RIR WHOIS database, and probably integrates with their provisioning system that can automatically create and update filters on routers. I don't know... But it's certainly better than the alternative.
resource certification would at least get us to the point where checking the data in the IRR is 'easy', it's not going to get people to PUT FILTERS ON CUSTOMER SESSIONS, and it's not going to get people to update their IRR objects (add AND DELETE!!!)
I support RPKI, but also realize that operator support will take a very long time for various reasons, e.g., education, delayed software upgrades, persistence with older methods, fear of centralization, e.t.c. In such a case, operators will need to support "Invalid" and "NotFound" states of origin information for a long time. As adoption and deployment increases, operators can begin dropping "Invalid" results, "NotFound" results, or both. Or even mark them down with poor LOCAL_PREF values so as not to use those routes for forwarding unless it is really necessary. At some point, when diffusion of RPKI is sufficiently prolific, anything that does not return a "Valid" result will be dropped. This should force every operator around the world to support it, much like the large carriers forced us all to use IRR's just so they won't ignore our routes, wherever we are in the world. But before all this happens, we have to prevent more hijacks. And we have to use the tools we have today. Mark.