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
Dear Lee, *ring ring* - "IRR/RPKI helpdesk how may I help you today?" :-) On Fri, Oct 22, 2021 at 08:25:10AM -0500, Lee Fawkes wrote:
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
Job Snijders via NANOG wrote:
Dear Lee,
Hi Job,
*ring ring* - "IRR/RPKI helpdesk how may I help you today?" :-)
What a fantastic helpdesk it is, too! ;-)
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 https://www.dan.me.uk/filtergen
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. -- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
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 On Sat, 13 Nov 2021, 10:41 am Jay Hennigan, <jay@west.net> wrote:
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.
-- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
On Fri, Nov 12, 2021 at 9:56 PM George Michaelson <ggm@algebras.org> wrote:
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.
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
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 On Sat, 13 Nov 2021, 11:18 am Rubens Kuhl, <rubensk@gmail.com> wrote:
On Fri, Nov 12, 2021 at 9:56 PM George Michaelson <ggm@algebras.org> wrote:
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.
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
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
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
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
participants (7)
-
Adam Korab -
George Michaelson -
Jay Hennigan -
Job Snijders -
Lee Fawkes -
Randy Bush -
Rubens Kuhl