Re: It can be challenging to advise DDoS mitigation subscribers on their RPKI-ROA needs

["Li, Weitong" <weitongli () vt edu>]

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.edu () nanog org> on behalf of Compton, Rich via NANOG <nanog () nanog org>
Sent: Friday, October 18, 2024 12:32 PM
To: Steven Wallace <ssw () 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.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