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
I'm very interested in this! I'd suggest talking with the smart folks at globalcyberalliance.org, who now operate MANRS. I'm sure Brad Gorman, the ARIN product owner for routing security, is also close by. I was going to suggest an informal BoF at NANOG next week, but I see you aren't registered. One thought I haven't examined closely is creating a ROA during a DDoS attack, specific to the affected resources. But I suppose that's dependent on Validators downloading updated ROAs, which may be longer than the DDoS lasts. Lee -----Original Message----- From: NANOG <nanog-bounces+leehoward=hilcostreambank.com@nanog.org> On Behalf Of Steven Wallace Sent: Friday, October 18, 2024 9:50 AM To: nanog@nanog.org Subject: It can be challenging to advise DDoS mitigation subscribers on their RPKI-ROA needs This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments. 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
Lee, I’m attending an Internet Integrity meeting hosted by globalcyberalliance.org in a couple of weeks. I intend to discuss the topic there. I’ll also explore with MANRS if it makes sense to have recommended actions for DDoS scrubbing services. It would be great to have the DDoS providers in the conversation. steve On 18 Oct 2024, at 12:09, Howard, Lee wrote:
I'm very interested in this!
I'd suggest talking with the smart folks at globalcyberalliance.org, who now operate MANRS. I'm sure Brad Gorman, the ARIN product owner for routing security, is also close by.
I was going to suggest an informal BoF at NANOG next week, but I see you aren't registered.
One thought I haven't examined closely is creating a ROA during a DDoS attack, specific to the affected resources. But I suppose that's dependent on Validators downloading updated ROAs, which may be longer than the DDoS lasts.
Lee
-----Original Message----- From: NANOG <nanog-bounces+leehoward=hilcostreambank.com@nanog.org> On Behalf Of Steven Wallace Sent: Friday, October 18, 2024 9:50 AM To: nanog@nanog.org Subject: It can be challenging to advise DDoS mitigation subscribers on their RPKI-ROA needs
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.
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
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
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
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
Hi Rich, What I see is a mix of approaches when announcing the more specific: - retaining the original origin - the origin of their upstream provider - the origin of the scrubbing provider I see no reliable way to determine which might be used. The organization creating the ROA frequently doesn’t know. Sometimes, there’s IRR objects that hint at what happens. Oh, and sometimes you need a third ROA to prevent a route object from being suppressed. steve On 18 Oct 2024, at 12:32, Compton, Rich wrote:
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
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
On 18 Oct 2024, at 13:17, Randy Bush wrote:
In some cases, you can identify customers of DDoS mitigation services by looking at as-sets published by these providers
what's an as-set?
randy An IRR object that contains ASNs and other as-sets. Generally used to represent a network’s customer cone.
That’s my understanding. steve Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
participants (5)
-
Compton, Rich -
Howard, Lee -
Li, Weitong -
Randy Bush -
Steven Wallace