DDoS mitigation providers normally originate a customer’s /24 or /48 with their ASN as the origin. This prefix is the most specific prefix which covers the customer’s IP(s) under attack that will be accepted on the Internet. If a customer has created ROAs for the protected prefixes, they would need to add one or more additional ROAs to allow the DDoS mitigation provider to originate any /24 or /48 prefixes contained in their prefix from the DDoS mitigation provider’s ASN. For example, if customer A is advertising 192.0.2.0/23 from an origin ASN of 65123 and they employ a DDoS mitigation provider with ASN 65456, before the mitigation service is enabled, the customer would need to create a ROA to allow 192.0.2.0/23 with a maximum length of /24 to originate from 65456. The other option is to create ROAs for each of the /24’s contained within the prefix. If customer A is advertising 192.0.2.0/24 and they are under attack, they would need to withdraw this advertisement while the DDoS mitigation provider advertises out 192.0.2.0/24. Again, a ROA would need to be created to allow the DDoS mitigation provider to originate that prefix from their ASN. Return traffic to the customer’s network after scrubbing the attack is usually sent through a cross connect or a tunnel like GRE. If the customer has no ROAs, then they should NOT create ROAs to allow their DDoS mitigation provider to originate their prefixes without also creating a ROA for their own ASN. If they do, then the customer’s advertisement will become RPKI INVALID and will get rejected by those ISPs doing ROV. The only situation where this may be acceptable is an always-on configuration where the customer’s traffic is ALWAYS sent across the Internet to the DDoS mitigation provider and is NEVER advertised by the customer. -Rich From: NANOG <nanog-bounces+rich_compton=comcast.com@nanog.org> on behalf of Steven Wallace <ssw@internet2.edu> Date: Friday, October 18, 2024 at 7:52 AM To: nanog@nanog.org <nanog@nanog.org> Subject: It can be challenging to advise DDoS mitigation subscribers on their RPKI-ROA needs DDoS mitigation services, particularly those that dynamically announce more specific routes during an attack, add complexity when advising customers on creating their RPKI-ROAs. Smaller organizations, often served by networks that provide DDoS mitigation on their behalf, might be unaware of these services or lack an understanding of how traffic is rerouted. In some cases, you can identify customers of DDoS mitigation services by looking at as-sets published by these providers or by investigating related IRR objects for the IP addresses. However, this approach isn’t reliable. Currently, there’s no established best practice for helping organizations determine the correct ROAs to create. This can lead to confusion, especially when DDoS mitigation is involved. ARIN plans to implement a check in their hosted RPKI interface that will help validate proposed ROAs against the current global routing table. While this feature will be useful, there is a risk that it could give DDoS mitigation customers a false sense of security. They might create ROAs that inadvertently block their DDoS scrubbing service from functioning properly. I’d like to engage with stakeholders in this space to explore opportunities for improvement. Any suggestions or input on this topic would be greatly appreciated. thanks, steven Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu