...

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 On Wednesday, October 8, 2014 8:15 PM, Faisal Imtiaz <faisal@snappytelecom.net> wrote: 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 ----- Original Message -----

From: "Brandon Wade" <brandonwade@yahoo.com> To: nanog@nanog.org Sent: Wednesday, October 8, 2014 4:44:07 PM Subject: RADB

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

Take a look: https://www.arin.net/resources/routing/ charles On Wed, Oct 8, 2014 at 10:35 PM, Brandon Wade <brandonwade@yahoo.com> wrote:

...

...

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

On Wednesday, October 8, 2014 8:15 PM, Faisal Imtiaz <faisal@snappytelecom.net> wrote:

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

----- Original Message -----

...

From: "Brandon Wade" <brandonwade@yahoo.com> To: nanog@nanog.org Sent: Wednesday, October 8, 2014 4:44:07 PM Subject: RADB

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

On Oct 23, 2014 2:27 PM, "Danny McPherson" <danny@tcb.net> wrote:

<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?

Alas,

-danny

On Thu, Oct 23, 2014 at 4:18 PM, Danny McPherson <danny@tcb.net> wrote:

On 2014-10-23 12:33, Christopher Morrow wrote:

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

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

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

On 2014-10-25 06:57, Sandra Murphy wrote:

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.

Those are fair points Sandy, I agree they need to be resolved. It's just that RPKI feels like a _really heavy solution to _that problem. That said, if that problem were solved nearly all of what I care about with regard to routing security (and inter-domain anti-spoofing) could be addressed. -danny

On Oct 25, 2014, at 9:38 PM, Danny McPherson <danny@tcb.net> wrote:

On 2014-10-24 15:24, Christopher Morrow wrote:

...

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>

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 :-)

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.

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

On 2014-10-25 08:25, John Curran wrote:

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.

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

On Sat, Oct 25, 2014 at 5:00 PM, Randy Bush <randy@psg.com> wrote:

you just happen to have the view from a third world country look at. http://archive.psg.com/141006.rpki-nanog.pdf slides 4 & 5 or http://certification-stats.ripe.net/?type=roa-v4

randy

I agree with Randy. RPKI is achievable today. Signing routes is a trivial amount of effort, there is really no excuse to not do it. Even i did it. Validation does take effort, but it is consistent with the level of effort to deploy any new router feature. CB

john

To what extent is the ROA growth rate in the RIPE region (on page 5 of the NANOG slides) enabled by the IRR practices of that region?

check out slide 3, lacnic has a 20% adoption rate. both ripe and lacnic have put energy into their own systems, educating users, ... ripe's curve would not seem to show correlation with recent liberalization of policy, but i doubt it is wise to twy to squeeze cause out of curves.

I do recognize that there are issues (as Wes nicely identified in Baltimore and which we'll be working on) that get in the way of RPKI deployment in the ARIN region, but those issues are not present other non-RIPE regions - yet the number actual ROA's issued still appears to be rather low...

20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. slide 5 "It’s What Happens When You Let Lawyers and Wannabe Regulators Run the Internet" i really loved the arin ac guy i met in baltimore who did not think having arin meet at nanog was good because those operators just did not get how to regulate the internet. you've been captured by the tea party. randy

it's just a consequence that our initial idea was just about to protect allocations of our members - not about secure routing at all On 26 Oct 2014, at 14:40, John Curran <jcurran@arin.net> wrote:

On Oct 26, 2014, at 6:46 AM, Randy Bush <randy@psg.com> wrote:

...

20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6?

arin, 388 and 0.7%, a joke.

LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case....

You don't feel there's any correlation between RIPE's IRR approach and their RPKI success?

/John

John Curran President and CEO ARIN

LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs.

< conjecture follows > of course one can never know. but i conject o the are the largest registry actively promotin registration o the ncc, particularly alex, tim, oleg, ... have put significant effort into making it very easy to register o they have a culture of cooperation and doing things well

You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case....

it is hard to register in apnic, ask folk who have tried. the most active folk are under NIRs, who are only now working on deployment. apnic is not really promoting it.

You don't feel there's any correlation between RIPE's IRR approach and their RPKI success?

that's the cooperative culture bit, actually interested in the net running well. randy

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 On Oct 23, 2014, at 2:26 PM, Danny McPherson <danny@tcb.net> wrote:

<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