Quickstart Guide to IRR/RPSL
Greetings, As part of setting up a new Internet Exchange in Fremont, California, we've been investigating prefix filtering on the route servers based on IRR. Unfortunately, we were not satisfied with any of the existing documentation available online as far as taking a network engineer from "zero" to "just enough IRR to post our prefixes for filtering". Lacking this documentation, it was rather unreasonable for us to turn on filtering and drop most of our peer's prefixes without a relevant whitepaper to point them to to get started. So, we wrote our own guide: http://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html I thought others on this list would find our whitepaper interesting, and/or have valuable feedback based on their experience applying IRR themselves. -- Kenneth Finnegan Technical Director Fremont Cabal Internet Exchange http://fcix.net/
Dear Kenneth, On Wed, Jul 18, 2018 at 09:38:23PM -0700, Kenneth Finnegan wrote:
As part of setting up a new Internet Exchange in Fremont, California, we've been investigating prefix filtering on the route servers based on IRR.
Excellent, have you also considered using ARIN-WHOIS and RPKI as data sources for your route servers? An excellent tool to generate route server configurations is 'arouteserver' http://arouteserver.readthedocs.io/
Unfortunately, we were not satisfied with any of the existing documentation available online as far as taking a network engineer from "zero" to "just enough IRR to post our prefixes for filtering". Lacking this documentation, it was rather unreasonable for us to turn on filtering and drop most of our peer's prefixes without a relevant whitepaper to point them to to get started.
So, we wrote our own guide: http://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html
This is excellent reasoning, there indeed is a lack of easy to consume information.
I thought others on this list would find our whitepaper interesting, and/or have valuable feedback based on their experience applying IRR themselves.
1/ About the "Selecting an IRR Database" section, the best current practise is to use the IRR that your RIR provides you. In other words: register ARIN managed prefixes in the ARIN IRR, and RIPE managed prefixes in the RIPE IRR. Only the RIRs are in a position to attest that it was the owner of a prefix that created the route(6): object. Databases such as RADB, NTTCOM, ALTDB are so-called "third party" databases and at this moment in time have no way to validate anything. I've highlighted the differences between the various sources of data in this talk at RIPE76 https://ripe76.ripe.net/archives/video/22 Also, in most regions people are paying their RIR money, this money pays for IRR services so I'd recommend to use those. 2/ I'd delete the "Step 2: Document Your Autonomous System’s Routing Policy" step, nobody uses this. 3/ Step 3 is excellent, everybody who generates filters uses AS-SETs. I like how detail was given to the "AS15562:AS-SNIJDERS" format to ensure unique names. Good work. 4/ Step 4 can be extended to promote creating RPKI ROAs (in addition to) the route objects. Anyone can create a route: object in ALTDB, but only the owner of a prefix can create a RPKI ROA. As such the RPKI ROAs are a far more valuable source of data to filter generators. In summary, great work! Can I update http://peering.exposed/ and add FCIX with a 'yes' to both secure route servers & BCP 214? :-) Kind regards, Job
On Thu, Jul 19, 2018 at 9:19 AM, Job Snijders <job@ntt.net> wrote:
Excellent, have you also considered using ARIN-WHOIS and RPKI as data sources for your route servers? An excellent tool to generate route server configurations is 'arouteserver' http://arouteserver.readthedocs.io/
After the volume of time and level of frustration it took just to get a handle on IRR, RPKI has been placed very low on our priority list. It's still on our list, but we've got plenty of other work to do before I figure out the implications of turning on RPKI, and I'm not willing to turn on a prefix authentication that I'm not able to walk my members through a way to correct. As for ARIN-WHOIS, I think I had gotten confused whether it was additive or exclusive of IRR objects for allowing prefixes. We have a lot of members running prefixes off of letters of authorization, so rejecting routes based on ARIN-WHOIS wasn't attractive, but that documentation you linked to reads more like it'll accept prefixes in addition to what gets accepted based on IRR alone. We will experiment with it. And yes, arouteserver is an excellent tool; we're currently using it, so enabling RPKI and ARIN-WHOIS will be relatively easy once we're willing to qualify it and roll it out.
1/ About the "Selecting an IRR Database" section, the best current practise is to use the IRR that your RIR provides you. In other words: register ARIN managed prefixes in the ARIN IRR, and RIPE managed prefixes in the RIPE IRR. Only the RIRs are in a position to attest that it was the owner of a prefix that created the route(6): object.
This is true. I wanted to write a more evergreen guide than walking through the current implementation of a single region's RIR, since there's several of them with their own unique work-flows and I get the sense that several of them are currently in flux. If we could ultimately replace this whitepaper with links to five equivalent documents from the RIRs, so be it.
Databases such as RADB, NTTCOM, ALTDB are so-called "third party" databases and at this moment in time have no way to validate anything. I've highlighted the differences between the various sources of data in this talk at RIPE76 https://ripe76.ripe.net/archives/video/22
I did eventually find that talk useful once I had climbed high enough on the learning curve to really understand what you were talking about. Thanks.
2/ I'd delete the "Step 2: Document Your Autonomous System’s Routing Policy" step, nobody uses this.
Is the expectation that the only source of a network's as-set is PeeringDB then? I have reason to believe there are IRR consumers who do parse export/mp-export statements. I think at least documenting an mp-export to AS-ANY policy is reasonable, but I'll reconsider that.
4/ Step 4 can be extended to promote creating RPKI ROAs (in addition to) the route objects. Anyone can create a route: object in ALTDB, but only the owner of a prefix can create a RPKI ROA. As such the RPKI ROAs are a far more valuable source of data to filter generators.
Yes. Someone should write a "zero to RPKI" tutorial. After this whitepaper literally took sitting down and reading the RFCs for something that people bemoan isn't used by every network, I'm not excited to try and get the same handle on RPKI to be able to speak with authority on how to set it up.
Can I update http://peering.exposed/ and add FCIX with a 'yes' to both secure route servers & BCP 214? :-)
Please do. :-) $0 for 10G, N/A for 100G. The next IRR puzzle for us is converting a CSV of member ASNs to their as-sets to generate the requested AS33495:AS-MEMBERS as-set so our members can also generate filters against the route servers. It seems like there's probably a tool like bgpq3 that can turn a list of ASNs into an as-set of their exports, but I'm not seeing it. Anyone have something at hand, or am I breaking out the python soon? -- Kenneth Finnegan http://blog.thelifeofkenneth.com/
On Thu, Jul 19, 2018 at 11:19:12AM -0700, Kenneth Finnegan wrote:
As for ARIN-WHOIS, I think I had gotten confused whether it was additive or exclusive of IRR objects for allowing prefixes.
Indeed, in arouteserver it is 'additive'. Documentation from ARIN is here: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters-...
2/ I'd delete the "Step 2: Document Your Autonomous System’s Routing Policy" step, nobody uses this.
Is the expectation that the only source of a network's as-set is PeeringDB then?
Yes, or the IX/transit operator can ask what AS-SET to use during the turn-up of the circuit.
I have reason to believe there are IRR consumers who do parse export/mp-export statements. I think at least documenting an mp-export to AS-ANY policy is reasonable, but I'll reconsider that.
Globally I think there are only 2 or 3 organisations left that parse this information. The vast majority either autodiscovers via peeringdb, or just explicitly asks for it during provisioning.
Can I update http://peering.exposed/ and add FCIX with a 'yes' to both secure route servers & BCP 214? :-)
Please do. :-) $0 for 10G, N/A for 100G.
Excellent, done.
The next IRR puzzle for us is converting a CSV of member ASNs to their as-sets to generate the requested AS33495:AS-MEMBERS as-set so our members can also generate filters against the route servers. It seems like there's probably a tool like bgpq3 that can turn a list of ASNs into an as-set of their exports, but I'm not seeing it.
bgpq3 can only go from IRR sources (using the RADB IRRd protocol) to outputs such as Cisco, Juniper, BIRD, JSON - not the other way around.
Anyone have something at hand, or am I breaking out the python soon?
Go python Kind regards, Job
participants (2)
-
Job Snijders -
Kenneth Finnegan