Questions about IRR best practices

Mailman List Mirror (Read Only)
1

Good morning Operators;

I have a couple of questions about best practices for Internet Routing Registries. I’m able to find lots of documentation about how to do things, but not a lot of documentation about when I should do things. I work for a medium-sized ISP in the US, and we are currently using both RADb and the ARIN IRR. We peer all over the place, but my main concern is how Cogent and Hurricane Electric build prefix filters from our IRRs.

  1. Netflix is asking us to add the AS of a downstream customer of one of our customers to our customer AS-SET. We have a direct relationship with this organization’s provider, but not with this organization itself. Is this appropriate?

  2. On the ARIN side, when ARIN-NONAUTH goes away next year, does that do away with our ability to do proxy route objects? Do we need to require all of our BGP customers to set up their own IRRs?

  3. On the RADb side, if we’re turning up a new customer that doesn’t have an IRR, and another ISP already has a proxy registration for that customer, is it sufficient for us to add that customer’s AS to our customer AS-SET?

I’ve been getting around the fact that RADb doesn’t allow multiple proxy registrations by registering proxy route objects in ARIN-NONAUTH, but that won’t be an option much longer, and I can’t really experiment with our customers’ route objects to see what works.

Thanks!

-Lee Fawkes

2

Dear Lee,

*ring ring* - "IRR/RPKI helpdesk how may I help you today?" :slight_smile:

I have a couple of questions about best practices for Internet Routing
Registries. I'm able to find lots of documentation about *how* to do
things, but not a lot of documentation about when I *should* do things. I
work for a medium-sized ISP in the US, and we are currently using both RADb
and the ARIN IRR. We peer all over the place, but my main concern is how
Cogent and Hurricane Electric build prefix filters from our IRRs.

1. Netflix is asking us to add the AS of a downstream customer of one of
our customers to our customer AS-SET. We have a direct relationship with
this organization's provider, but not with this organization itself. Is
this appropriate?

Another way to satisfy this request is to ask the organization's
provider to create an AS-SET (preferably RIR-operatored IRR such as
ARIN, RIPE, etc), and then reference their AS-SET on your own AS-SET.
IRR AS-SETs permit both referencing AS Numbers and AS-SETs as 'members:'.

2. On the ARIN side, when ARIN-NONAUTH goes away next year, does that
do away with our ability to do proxy route objects? Do we need to
require all of our BGP customers to set up their own IRRs?

The industry trend (very noticable the last 3 years) is that the ability
to create proxy route object registrations is slowly fading away.

At at first glance proxy registrations seem better than 'no
registration', the downside is that anyone can create proxy
registrations for any prefix: proxies are not very safe!

The recommendation is that each and every IP resource holder creates IRR
and/or RPKI objects themselves, or delegates the authority to do so to
their service provider.

These days everyone wants to see firm cryptographic proof!

3. On the RADb side, if we're turning up a new customer that doesn't have
an IRR, and another ISP already has a proxy registration for that customer,
is it sufficient for us to add that customer's AS to our customer AS-SET?

Technically this is likely to work, but the downside is that you end up
with a hard dependency on another ISP's proxy registration. If for
whatever reason that registration lapses (failure to pay bills, M&A, who
knows) ... you might end up with a hard to troubleshoot situation where
it is not immediately clear "it was working yesterday, but not today?!".

The best course of action is to ensure that objects are either managed
by yourself, or by the customer, so the responsibilities and object
ownership are clear to everyone involved.

I've been getting around the fact that RADb doesn't allow multiple
proxy registrations by registering proxy route objects in
ARIN-NONAUTH, but that won't be an option much longer, and I can't
really experiment with our customers' route objects to see what works.

A great tool to gain some insight into various IRR/BGP/RPKI data sources
and what the registration status of various objecst might mean can be
found at this awesome tool: https://irrexplorer.nlnog.net/

Follow up questions welcome!

Kind regards,

Job

3

2. On the ARIN side, when ARIN-NONAUTH goes away next year, does that do away with our ability to do proxy route objects? Do we need to require all of our BGP customers to set up their own IRRs?

Not only ARIN. LACNIC and TC (the two IRRs covering the LAC region, TC
for Brazil, LACNIC for Mexico and other Latin American countries) have
strict non-proxy policies, and there is no -NONAUTH scape route.

3. On the RADb side, if we're turning up a new customer that doesn't have an IRR, and another ISP already has a proxy registration for that customer, is it sufficient for us to add that customer's AS to our customer AS-SET?

The problem with that is all of sudden the covering object could disappear.

Rubens

4

Dear Lee,

Hi Job,

*ring ring* - "IRR/RPKI helpdesk how may I help you today?" :slight_smile:

What a fantastic helpdesk it is, too! :wink:

Another way to satisfy this request is to ask the organization's
provider to create an AS-SET (preferably RIR-operatored IRR such as
ARIN, RIPE, etc), and then reference their AS-SET on your own AS-SET.
IRR AS-SETs permit both referencing AS Numbers and AS-SETs as 'members:'.

This brings up a question I've been mulling over lately - if AS64500 has
AS64500:AS-CUSTOMERS and has a customer AS64510, and AS64510 only ever
plans to originate routes themselves, with no downstreams, is there any
reason other than "future flexibility" for AS64510 to create an AS-SET,
e.g.:

as-set: AS64500-CUSTOMERS

-> members: AS64510:AS-AS64510

>-> members: AS64510

versus simply the following:

as-set: AS64500-CUSTOMERS
>-> members: AS64510

It seems to me both are entirely functionally equivalent, aside that if
AS64510 ever wants to change things they would need to get AS64500 to
update their AS64500-CUSTOMERS members.

The industry trend (very noticable the last 3 years) is that the ability
to create proxy route object registrations is slowly fading away.

At at first glance proxy registrations seem better than 'no
registration', the downside is that anyone can create proxy
registrations for any prefix: proxies are not very safe!

I wonder what this means (eventually, anyway) for RADB, NTTCOM, LEVEL3,
etc. Though LEVEL3 can hardly be considered on the bleeding edge of
IRR...

The recommendation is that each and every IP resource holder creates IRR
and/or RPKI objects themselves, or delegates the authority to do so to
their service provider.

What is the mechanism for such a delegation?

It seems to me that with enough RPKI adoption, IRR will eventually go
away, but you mention "and/or" - is that just for current
interoperability?

Taking it a step futher, let's say I have valid ROAs for all my prefixes
today, because I do. But I don't maintain my objects in ARIN's IRR. Do
I need to migrate, and if so, assuming my upstreams still "reject RPKI
invalid but permit rpki unknown AND require an IRR AS-SET to build BGP
filters in the first place" it seems to me that maintaining IRR is
necessary because otherwise the upstream won't listen to the
announcements at all, much less verify RPKI.

Technically this is likely to work, but the downside is that you end up
with a hard dependency on another ISP's proxy registration. If for
whatever reason that registration lapses (failure to pay bills, M&A, who
knows) ... you might end up with a hard to troubleshoot situation where
it is not immediately clear "it was working yesterday, but not today?!".

FWIW, Lee, I ran into this exact scenario this week. Everything was
working, but the route was only being permitted by the customer's
upstream because of a stale object proxy registered by someone else. My
two cents is that this is an exceedling common occurence.

The best course of action is to ensure that objects are either managed
by yourself, or by the customer, so the responsibilities and object
ownership are clear to everyone involved.

And yet, there's probably double-digits of people that fully grok IRR,
despite the years and years of NOG presenations and tutorials and
everything else.

A great tool to gain some insight into various IRR/BGP/RPKI data sources
and what the registration status of various objecst might mean can be
found at this awesome tool: https://irrexplorer.nlnog.net/

There's also a command-line irrtree that's pretty slick, and if you want
to verify AS-SET recursion and ultimately expansion into prefixes,
point your whois client toward filtergen.level3.net [1] and/or
filtergen.dan.me.uk [2]

--Adam

[1] But be careful because L3 filtergen doesn't recurse across
registries and will ignore data that's not source: LEVEL3 +unless* you
put 'remarks: Level3 members: RADB::AS-FOO' in the AS-SET.

[2] If you instead want to filtergen against RADB data (and objects
which RADB mirrors from others) see Filter List Generator

5

Tagging onto this thread as it's relevant to me.

Is there any mechanism for removing stale cruft that someone else has added to IRR? Two of our subnets have some cruft from an automated script that was accurate in 2006 when they were created, but are no longer valid.

Long story short, we consolidated acquisitions into a single AS, returned the old AS to ARIN, and a 2006 RADB entry that looks to have been auto-generated by Level 3 with the old AS is still hanging around, causing other to question it.

6

Wouldn’t it be cool if we had a cryptographic mechanism to sign an authority to the IRR publisher to eject old data.

Some way you could prove you have control of the asset, and the let the RADB people know you repudiated some old data, made under somebody else’s authority which you can’t remove directly, even though it’s probably stale.

Something like a PKI tagged with your addresses and/or ASN.

G

7

That only helps with wrong origin IRR records. While this is the case at hand, a lot of proxy objects have correct origin attributes, and are just managed by the wrong person.

That said, TC IRR is currently using RPKI validation and the curious result is that most RPKI-triggered removals are objects sent by the own AS, but with a more specific prefix that what’s published in RPKI.

Rubens

8

Well, if you use a ROA as your only signed object, then yes. But really I was hinting at RTA or RSC: use the mechanism to countersign an instruction to RADB or any other IRR specifically about the RPSL you want to eject.

Not “because ROA do this” but “do this specific thing I command because I control the assets”

G

9

Jay Hennigan wrote:

Long story short, we consolidated acquisitions into a single AS, returned
the old AS to ARIN, and a 2006 RADB entry that looks to have been
auto-generated by Level 3 with the old AS is still hanging around, causing
other to question it.

If it's source: LEVEL3, drop a note to ipadmin@centurylink.com - it works
some of the time.

--Adam

10

Well, if you use a ROA as your only signed object, then yes. But really I
was hinting at RTA or RSC: use the mechanism to countersign an instruction
to RADB or any other IRR specifically about the RPSL you want to eject.

Not "because ROA do this" but "do this specific thing I command because I
control the assets"

this seems to be a reasonable use of rta and/or rsc.

randy, author of draft-ietf-sidrops-rpki-has-no-identity