Quickstart Guide to IRR/RPSL

Kenneth Finnegan kennethfinnegan2007 at gmail.com
Thu Jul 19 18:19:12 UTC 2018


On Thu, Jul 19, 2018 at 9:19 AM, Job Snijders <job at 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/



More information about the NANOG mailing list