Understanding impact of RPKI and ROA on existing advertisements

Hello,
I am new to RPKI/ROA and still learning about RPKI. From all my reading on ARIN’s documents I am not able to answer some of my questions.
We have a public ARIN block and advertise smaller subnets from that to our ISP’s. We do not have any RPKI configs.

We need to setup ROA’s to take another subnet from the ARIN block to AWS. Reading ARIN’s docs, it seems I need to get setup on their Hosted RPKI service after which I can configure ROA’s for the networks I am taking to AWS.

My question is, will this impact my existing advertisements to my ISP’s. The current advertisements do not have ROA’s.
Will having RPKI for my ARIN network, without ROA’s for the existing advertisements impact me?

Thanks for your help.

Ref:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html

https://www.arin.net/resources/manage/rpki/roa_request/

https://www.arin.net/resources/manage/rpki/hosted/

You may want to set this up yourself anyways. In the effort of making things work, your upstream ISP may have had to setup these records on your behalf. If not now, they may in the future. Having duplicate entries can cause unexpected results.

Creating ROAs for *all* the announcements that are done with your prefixes, both on your own AS and the ones announced by AWS, is probably the best way forward from both a routing security and ease-of-management perspective.

-Alex

If the route can exist on a FIB, can exist a ROA to that.

So, there is no reason to no create the ROAs.

In general, you want to create suitable ROAs for the most specific routes that will be advertised first.

Suppose you have a /20 from ARIN. You plan to take a /24 from that /20 to AWS. From what you've said, all you need is a ROA for the /24 you're taking to AWS, saying it can be originated by whatever ASN will be originating it at AWS.

One danger with RPKI, is shooting yourself (or customers) in the foot by creating too general a ROA. i.e. Suppose you have an ARIN /20. You have a multihomed customer to whom you've assigned a /24 from your /20. You create a ROA for the /20 saying your ASN is authorized to originate your /20. Now that customer /24 has become an RPKI-invalid, and the customer may find that their other provider is filtering their /24 advertisement.

Tue, Nov 01, 2022 at 12:01:46PM -0400, Jon Lewis:

One danger with RPKI, is shooting yourself (or customers) in the foot by
creating too general a ROA. i.e. Suppose you have an ARIN /20. You have
a multihomed customer to whom you've assigned a /24 from your /20. You
create a ROA for the /20 saying your ASN is authorized to originate your
/20. Now that customer /24 has become an RPKI-invalid, and the customer
may find that their other provider is filtering their /24 advertisement.

ie: you must also create roa(s) for your bgp customer's more specific(s) of
your aggregate.

Thanks everyone for your inputs. So bottomline setup RPKI and setup ROA’s for all our subnets being advertised.

Much of this is legacy and has too many unknowns, being handed down networks without documentation also does not help.

Thanks,
Sam

Thanks everyone for your inputs. So bottomline setup RPKI and setup ROA's
for all our subnets being advertised.

if the BGP advertisements are correct, then mirror them in ROAs. most,
if not all, CA UIs make that easy.

randy

RPKI/ROA is a way to cryptographically prove what someone needs to prepend if they want to hijack your addresses.

Owen

It’s very important to specify the /24 inside the /23 for example so as you said “for all our subnets being advertised”.

Tue, Nov 01, 2022 at 06:24:50PM -0700, Owen DeLong via NANOG:

RPKI/ROA is a way to cryptographically prove what someone needs to prepend if they want to hijack your addresses.

Operators should not be deterred by that comment. Owen seems to be ignoring
what it does achieve and that this is part of a larger system that is still
emerging. See IETF sidrops wg. In the interim, do your part to improve
DFZ hygiene.

Oh, I’m not ignoring it, I’m just rather underwhelmed by it and given how long it took SIDRWG to get RPKI this far,
not optimistic about any of the rest of the system getting deployed prior to IPv6 ubiquity or the end of my time on
this planet, or even before we manage to destroy the planet, whichever comes first.

Owen

I dont think ive every agreed with Owen this much, maybe this is the first sign the wording is ending further proving his statement :slight_smile: