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....@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
Steven Wallace
Director - Routing Integrity
Internet2
s...@internet2.edu
