RADB

Mailman List Mirror (Read Only)
1

Hi,

I really don't know where else to post this. I recently subscribed to RADB and added route objects and route6 objects for our prefixes we announce. Of course an aut-num object was created and I created a list of ASN's that are downstream customers in an as-set list. But, since this is my first time ever subscribing to a routing registry, I really don't know for sure that I'm doing everything correctly. So, I submitted an e-mail to RADB and requested that they review what I've done and to see if I'm doing it correctly. Well, the reply I received was far less than I could have ever imagined:

"RADb is a self-serve service. If you have specific questions, we can
address those. However, the type of audit requested is not a part of the standard offering associated with this service."

So my question is, how am I supposed to verify that what I've done is what is supposed to be done and that I am doing this correctly?

My next question is, why would RADB offer zero support for confirming this? And lastly, why should my organization pay $500 per year to a service that is unwilling to assist in making sure their subscriber is using their service properly?

Best regards,
Brandon Wade

2

radb.net checks for syntactic correctness of database objects. Semantic
analysis is network dependent and is outside the scope of what the RADB
staff can provide. If you need this, you should hire someone who
understands your network and who can determine whether your irrdb objects
are a reasonable representation of your routing policy.

Nick

3

You can also verify the object configurations from another IRRd, such
as Level(3)

whois -h filtergen.level3.net "RADB::YOUR-AS-SET
-searchpath=RIPE;ARIN;RADB -recurseok -warnonly"

You can limit the searchpath to just include RADB if you wish, but
it's good to know what else is out there.

charles

4

I can relate to this, having gone thru a similar process/experience fairly recently in using IRRd..

So the real question Brandon is asking..

For a newbie, how does one go about learning the basic's of IRRd.

Speaking for myself, if there is a good answer, I would welcome it.

Here is what I had to do...

  1. Used Radb lookup on different AS-Set and ASN to get a feel on how others were using this resource.

   2. Went thru the ARIN IRRd Tutorial / info pages on how to create records etc.

   3. Did Google searches on finding some of the older NANOG presentations about IRRd.

Regards

Faisal Imtiaz
Snappy Internet & Telecom

5

For a newbie, how does one go about learning the basic's of IRRd.

That pretty much sums it up. I feel like I'm stuck reading RFC's that are too overly complex for something that seems like it shouldn't be complex. Anyone know of a
quick 101 intro to routing registries with a simple example of an AS
that has two upstream providers and a handful of peers and downstream
AS's?

Brandon

I can relate to this, having gone thru a similar process/experience fairly recently in using IRRd..

So the real question Brandon is asking..

For a newbie, how does one go about learning the basic's of IRRd.

Speaking for myself, if there is a good answer, I would welcome it.

Here is what I had to do...

  1. Used Radb lookup on different AS-Set and ASN to get a feel on how others were using this resource.

   2. Went thru the ARIN IRRd Tutorial / info pages on how to create records etc.

   3. Did Google searches on finding some of the older NANOG presentations about IRRd.

Regards

Faisal Imtiaz
Snappy Internet & Telecom

6

For a newbie, how does one go about learning the basic's of IRRd.

That pretty much sums it up. I feel like I'm stuck reading RFC's that are too overly complex for something that seems like it shouldn't be complex. Anyone know of a
quick 101 intro to routing registries with a simple example of an AS
that has two upstream providers and a handful of peers and downstream
AS's?

There's a decentish tutorial from nanog 51

ripe's training materials are here:

I'd start with the nanog tutorial, I'd treat it as background till you
get to the end, and the look at it again with an eye towards what you
need to do which is probably create a few route objects and an aut-num.

7

Take a look:

https://www.arin.net/resources/routing/

charles

8

<soapbox>

I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging existent systems and operational practices (e.g., more IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI or in-addr.arpa, etc). Given that many of the same derived "policies" there could also be employed for inter-domain datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing machinery and practices already deployed could more easily accommodate this in the near term, it seems only natural to me.

As for the visionaries playing the long game, they've made progress, but surely the only way to get there is with more incremental "putty" and small practical steps to fill the gaps at this point.

</soapbox>

I for one would like to see ARIN (as well as other RIRs and the adjacent community) invest more pragmatically in this area, particularly given the governance climate and other externalities at play these days.

Alas,

-danny

9

<soapbox>

I think the routing system would be in a much happier [less bad] place if

only had a minor amount of the energy and resources that USG (and RIRs)
have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have
been redirected to lower hanging fruit and better recognizing / leveraging
existent systems and operational practices (e.g., more IRR usage, training,
tools, and better hygiene, perhaps expressly validated from resource
certification from either RPKI or in-addr.arpa, etc). Given that many of
the same derived "policies" there could also be employed for inter-domain
datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing
machinery and practices already deployed could more easily accommodate this
in the near term, it seems only natural to me.

As for the visionaries playing the long game, they've made progress, but

surely the only way to get there is with more incremental "putty" and small
practical steps to fill the gaps at this point.

</soapbox>

I for one would like to see ARIN (as well as other RIRs and the adjacent

community) invest more pragmatically in this area, particularly given the
governance climate and other externalities at play these days.

Sounds like you want to see the rirs make sure they get rpki work dine and
widely available with the least encumbrances on the network operator
community as possible. Did you see wes's slides / talk at the last nanog?

10

Sounds like you want to see the rirs make sure they get rpki work
dine and widely available with the least encumbrances on the network
operator community as possible.

Or focus on more short/intermediate term returns like fortifying all the existing systems and automating processes that are already deployed and focus on ROI of members and operational buffers required by the community _today. E.g., IRR training and investment rather than RPKI, which this thread began with.

I'd continue and say in-addr.arpa or the like for resource certification because RPKI is so ugly, silly without a single root aligned with number resource allocations, etc.., but that'd require response cycles I'm not going to spend there.

Did you see wes's slides / talk at the last nanog?

I did (after).

Aside, I understand why the ARIN board did what they did with the RPA and I don't blame them -- it seemed well considered to me, but that's just me.

Reminded of Taleb's "Fat Tony" quote [paraphrased]: If the pilot ain't on the plane, you probably don't want to get on it,

-danny

11

IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI

You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which suggests using RPKI to protect RPSL objects.

That would help solve the trust problem in the current IRR world, which is that most IRRs can't tell if the object being registered is authorized. RIPE and, I think, APNIC being the exception, for their region resources. Lots of proxy registered objects aren't a good sign.

--Sandy

12

IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI

You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which
suggests using RPKI to protect RPSL objects.

Yep, I'm aware of that and think that's a really useful thing if RPKI is the resource certification infrastructure we must use.

That would help solve the trust problem in the current IRR world,
which is that most IRRs can't tell if the object being registered is
authorized. RIPE and, I think, APNIC being the exception, for their
region resources. Lots of proxy registered objects aren't a good
sign.

Agreed!

That said, if people are still having issues with IRRs and lack of training, toolsets, and usability around them today and after deploying RPKI they still need IRRs (and whois, and in-addr.arpa, and..) for a whole bunch of stuff just to keep the packets flowing then the height limit to do basic and useful things just became that much higher, and requires a lot more care and feeding then before RPKI (even absent all the architectural aspects of RPKI that are "interesting").

-danny

13

Sounds like you want to see the rirs make sure they get rpki work

dine and widely available with the least encumbrances on the network
operator community as possible.

Or focus on more short/intermediate term returns like fortifying all the
existing systems and automating processes that are already deployed and
focus on ROI of members and operational buffers required by the community
_today. E.g., IRR training and investment rather than RPKI, which this
thread began with.

makes perfect sense to focus on validating existing systems such as IRR.
Seems like very low hanging fruit with a lot of benefit and a good ROI

14

Sounds like you want to see the rirs make sure they get rpki work
dine and widely available with the least encumbrances on the network
operator community as possible.

Or focus on more short/intermediate term returns like fortifying all the
existing systems and automating processes that are already deployed and
focus on ROI of members and operational buffers required by the community
_today. E.g., IRR training and investment rather than RPKI, which this
thread began with.

makes perfect sense to focus on validating existing systems such as IRR.
Seems like very low hanging fruit with a lot of benefit and a good ROI

it seems to me that there are a couple simple issues with IRR data
(historically):
  1) no authority for it (really, at least in the ARIN region)
  2) no common practice of keeping it updated
  3) proxy-registration issues (probably part of cleanup and authority issues)
  4) lack of widespread use due to the above issues.

I was/am hopeful that providing some path from IANA (eventually) on
down through RIR to LIR to end-user for 'authority to use' ip
resources would help in letting people use the IRR data cleansed of
insanity by the data from this path, and then into routers for route
filters.

The RPKI system looks like the path in question, to me.

15

The RIPE IRR is secure. Why not just copy that for the other regions?

Baldur

16

it seems to me that there are a couple simple issues with IRR data
(historically):
  1) no authority for it (really, at least in the ARIN region)
  2) no common practice of keeping it updated
  3) proxy-registration issues (probably part of cleanup and authority issues)
  4) lack of widespread use due to the above issues.

I think that's a subset of the issues. Those and others are captured here:

<https://tools.ietf.org/html/draft-ietf-grow-irr-routing-policy-considerations-05&gt;

Ironically, many of the issues that lead to decay in IRR use have been resolved, while others exist in RPKI, even.

Baldur's RIPE IRR point is a fair one and worthy of consideration, I'm all for low-hanging fruit.

I was/am hopeful that providing some path from IANA (eventually) on
down through RIR to LIR to end-user for 'authority to use' ip
resources would help in letting people use the IRR data cleansed of
insanity by the data from this path, and then into routers for route
filters.

And datapath filters for inter-domain anti-spoofing, perhaps, as it's largely the same policy (I know there are corner cases people that don't want to do this point out).

The RPKI system looks like the path in question, to me.

I know you're an RPKI fan, I'm at peace with that :slight_smile:

However, unless you can fortify the systems that RPKI (or any other resource certification infrastructure) would inform, operators have little incentive to use it as all the systems that are already deployed and still have to use (e.g., whois, in-addr.arpa, IRR, etc.) still have to be used and managed and operated. RPKI adds considerable complexity, costs, scaling challenges, new external dependencies, etc.. I actually think it'd have been a challenge to design something _more complicated than RPKI to address the problem space, but that's just me.

-danny

17

Other RIR based RIRs have the same ability to protect prefixes in their realm of control. (See RFC 2725 RPSS)(*) (I think that APNIC is doing pretty much as RIPE is.)

Even RIPE is not secure for prefixes outside their region. (There's one maintainer that anyone can use to register anything for resources outside the region - password publicly available, etc.)

Non-RIR based IRRs do not have the ability to tie the register-er to authority for the resource, so they have no base on which to build the RIPE sort of security.

--Sandy

(*) (yes, I'm listed as an author, but Curtis Villamizer was far and away the principal author.)

18

I had dinner with Russ and Wes during the LA ICANN meeting, and asked, in passing, whether RPKI conferred any benefits that just throwing appropriate IRR records into a signed in-addr didn’t, and they had an answer in the affirmative, but I can’t remember the details now, because I was jet-lagged and it was in the middle of a conversation about something else. Russ, Wes, anyone else with an interest, could you explain that again?

                                -Bill

19

Just for avoidance of any doubt -

The ARIN Board of Trustees has consistently directed that ARIN work on
technical capabilities that the community clearly expresses some level
of interest in, i.e. there is no standing directive that particular
technology solutions must be (or must not be) deployed. We have had
very specific requests for supporting RPKI, so we've done the necessary
work for hosted and delegated certificate authority (CA) services. We
can continue to enhance RPKI, or deploy other technical solutions, or
some combination (as the community directs)

With respect to IRR support, the same answer applies. If the community
is clear on direction, ARIN can strengthen the current IRR offerings,
phase them out and redirect folks to existing solutions, or any other
direction as desired. The hardest part is getting a common view in the
community on the desired approach; this leads to the strong adoption
that is necessary for these types of systems to have meaningful benefit.

FYI,
/John

John Curran
President and CEO
ARIN

20

I didn't necessarily intend to fault ARIN here, some very vocal folks have pushed ARIN (and others) pretty hard on focusing considerable resources on experimental systems (RPKI [/BGPSEC]) that may never see broad-scale adoption and use, for an array of technical, business, and geopolitical reasons. I could be wrong.

As an ARIN and community member, I'd prefer to see more work on nearer term solutions and better leveraging existing systems that we're already captive to and will still need in the future (e.g., IRR hygiene work and more security rails, tool sets, training for operators, perhaps in-addr.arpa or other techniques to validate resource holders, etc..). If orthodox visions materialize that provide utility and a reasonable ROI without introducing excess risk and overhead and complexity and undue external dependencies for the folks that would be captive to those new systems, then great.

I continue to believe that the only way any resource certification system is going to realize adoption is by taking this incremental approach of fortifying existing systems and supplying sufficient operational buffers, and that the easiest way to stunt deployment and adoption of RPKI is to slam it directly into the routing system and compromise current autonomy in routing operations that exists and makes the Internet resilient.

Thanks for that response, John.

-danny