On May 10, 2010, at 10:48 AM, Nick Hilliard wrote:
There are a lot of problems associated with using IRRDB filters for inbound prefix filtering.
We used them over 15 years ago near ubiquitously and stopped mostly because: 1) there was nothing akin to route refresh so you had to bounce best routes or reset sessions to trigger readvertisement after policy updates. This made unscheduled a pain and required some turning of the steam valves. 2) traditional ACLs were used for routing policy specification and weren't incrementally updatable, which was a huge pita. 3) IRRs were insecure to update, no one ever deletes anything from IRRs, and some folks even proxy register IRR objects based on BGP routing table entries. 4) customers complained they had to maintain them (ohh, wait, we told them if they wanted to be routed they had no choice) Regarding 1, we have route refresh and inherent soft-reconfig today. Regarding 2, pretty much all implementations support this today (although it will be a pita to maintain near exact prefix list and ACL entries for a customer down the road when used for both routing policies and ingress anti-spoofing). Regarding 3, RPKI should help here quite a bit, either used directly, or enabling IRR object population - the RIRs that run IRRs and other other folks are helping with secure update mechanisms as well. Regarding 4 - they didn't scream as loud about the policy as they did when things broke because of the absence of it, that I know firsthand.
- some clients announce lots of prefixes. This can make inbound prefix filtering difficult in some situations.
pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l 967
Yes, this needs to be automated, clearly.
- there are some endemic data reliability problems with the IRRDBs, exacerbated by the fact that on most of the widely-used IRRDBs, there is no link between the RIR and the IRRDB, which means that anyone can register any address space. whois.ripe.net doesn't allow this, but lots of other IRRDBs do.
See 3 above.
- the ripe whois server software does not support server-side as-set expansion. This is a really serious problem if you're expanding large ASNs.
Do it yourself for now and file a feature request..
- there is very little client software. At least irrtoolset compiles these days, but its front-end is very primitive. rpsltool provides some really nice templating functionality, but doesn't implement large sections of the rpsl standards.
Agreed, we need to do work here. -danny