We're just working on a measurement paper about this: Firstly, a measure in 2019 [1] shows that DDoS protection itself is not a major cause of RPKI Invalid (contribute less than 1%). Also, the propagation time for ROA usually takes 10 - 100 minutes, which is not that long [2].
We found out that the challenge is when IP leasing involved: if one guy rents a prefix from brokers, it needs up to 24 hours to update the ROA (since the prefix is still registered under the owner). Waiting 24 hours might be too long for DDoS. I've talked this with some IP brokers and Job, and one possible solution might be asking RIRs to support "partial delegation", that allows IP lessor to create RPKI CA certificate and give IP broker the right to manage ROAs only for prefix under leasing. (one broker told me that if you create a CA certificate in ARIN and RIPE, it will be authorized for all prefixes under that account, which stop lessors from doing this) The current RPKI RFC already supports it, and PP/CA software like Krill also supports it, but not in RIRs. Just let me know if you are interested in detail, or you can reach out Tao Wan next week in nanog. [1] RPKI is Coming of Age: A Longitudinal Study of RPKI Deployment and Invalid Route Origins [2] RPKI Time-of-Flight: Tracking Delays in the Management, Control, and Data Planes Best, Weitong ________________________________ From: NANOG <nanog-bounces+weitongli=vt....@nanog.org> on behalf of Compton, Rich via NANOG <nanog@nanog.org> Sent: Friday, October 18, 2024 12:32 PM To: Steven Wallace <s...@internet2.edu>; nanog@nanog.org <nanog@nanog.org> Subject: Re: It can be challenging to advise DDoS mitigation subscribers on their RPKI-ROA needs 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....@nanog.org> on behalf of Steven Wallace <s...@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 s...@internet2.edu
