[ARIN-consult] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs

[Hauge, Chuck P]

The questions for community consideration are:

- Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in?

A: I believe either and opt-in or opt-out option would be best per ORGID

- Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects?

A: If opt-in/out is adopted, this could be set by that option. If opt-in is selected, it could be a direct link with no manual management. If opt-out, manual management is required.

- Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today?

A: It seems this could also be set to opt-in/out, based upon the response to the first question. If opt-out of auto-creation, it seems this would be moot.

- If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not?

A: That would be based upon the IPAM manager for the ORG to define for themselves, based upon options selected. Personally, I can see a benefit for those Tier 1's and other peers that create their import policies based upon IRR objects.

- If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length (ML) configuration? Would a "least specific" route object meet expectations?

A: So, I agree there is a maximum, especially for IPv6. I just found out the other week that Google (and only Google to the best of my knowledge), will bypass ARIN Direct Allocation (DA) of a block, and prefer stale RADb route objects. That is, we own the supernet, but Google will not take that into consideration when we peer direct to them, they will look at [very old] RADb route objects if there is a subnet match and we don't have a route record in RADb or ARIN. As RADb is "open" and allows anyone to create a route object for any IP and origination AS, this opens our 57M v4 iP's to easy attack if we don't have a route record for every possible prefix we own. This creates a new vector of attack created solely by Google for our owned IP's to access Google resources. Also, since we have 100K employees, and most anyone in networking can create a prefix tagged appropriately and leaked to the Internet, in managing IP's we have no way to limit what is routed and leaked. We would have to play whack-a-mole trying to keep up.

That in mind, and I think that if more than 256 (or nnn?) IRR route objects are to be created, a message should be presented to the requester informing them of what they are asking. I should say, we don't like to use ML expect in very isolated cases where we'd be playing whack-a-mole if we tried to cover all /48's of a /32 for our business class customers. That said, we still have to act responsibly and understand the consequences such as Forged Origin attacks: https://datatracker.ietf.org/doc/html/rfc9319. So, you want to know the "specific" number, and I honestly don't have a suggestion, but how about this, if ML is used, ask the question something like, "Using an ML value greater than the mask creates the potential for subnets leaked to the Internet. Do you want to create IRR route objects for each candidate subnet, or create a route object for only the parent aggregate?"

Regards,

[Charter_Email Signature_Logo]

-------------------------------------------------------------------------------------------------------------------------------------
CHUCK HAUGE | CCNP, MBA | IP Management - Systems Engineer IV | c. 303.915.5512 | o. 303.323.6056
   6175 South Willow Drive |  Greenwood Village, CO  80111
-------------------------------------------------------------------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20230811/77ed67b3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6366 bytes
Desc: image001.png
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20230811/77ed67b3/attachment.png>