Skip to Content.
Sympa Menu

netsec-sig - Re: [Security-WG] [External] Re: Seeking advice on BCP for ROAs....

Subject: Internet2 Network Security SIG

List archive

Re: [Security-WG] [External] Re: Seeking advice on BCP for ROAs....


Chronological Thread 
  • From: Andrew Gallo <>
  • To:
  • Cc: "" <>
  • Subject: Re: [Security-WG] [External] Re: Seeking advice on BCP for ROAs....
  • Date: Wed, 15 May 2019 11:16:30 -0400

Generating ROAs as-needed is not a workable solutions- the lag time can easily many hours.  I don't think ARIN has published a specific spec on this, but I think ROAs are made available 4-12 hours.  Then it is up to the individual networks to collect those ROAs.  RIPE validator defaults to 10 minute refresh, though I could easily imagine large provides (like Cloudflare) building its own collection and distribution system.  So the time from ROA creation to results showing up in routers worldwide could be half a day or longer.

This same question was raised a while back with respect to DDoS.  The situation isn't too bad if you know ahead of time which /24s you might have a scrubbing service advertise.  In that case, create ROAs to cover that case.  HOWEVER, what do you do if you have a /16, and any /24 could be redirected at any time.

There are two possibilities, though neither are ideal:
1. pre-create all possible route origin possibilities (which tends to pollute the RPKI infrastructure.  Imagine having to do this for IPv6 if you have a /32.
2. use the max length option, allowing the DDoS service to originate anything /16-24.  A single ROA covers this possibility.  However, use of the max length option is now considered less than describable.


The problem is that RPKI needs to mirror the route table (specifically ASN/prefix origin pairs), or any possible configuration of the route table, so these new services where subprefixes can move around make ROV a bit more difficult.

What's the opinion of having the DDoS vendor advertise the prefix using the original networks ASN, in which case, the original ROA would cover?  Is that bad form in terms of routing?



On Wed, May 15, 2019 at 10:57 AM John Kristoff <> wrote:
On Wed, 15 May 2019 14:35:02 +0000
"" <> wrote:

> Which means IU would create a ROA for 129.79.0.0/16-24 to cover the
> case where a more specific is being scrubbed….which creates the same
> problem…so still seeking folks’ thoughts on the questions.

There may not be a perfect solution, but on the bright side, loose ROAs
aren't actually making the problem worse compoared to use of RPKI at all
so there is that.  ROV is really only helpful for accidents anyway, so
if you do monitoring too, you're far beyond where most people will be
at and likely able to better respond to the more sophisticated
threats.  Solve for the 95% common case and document who to respond in
the 5% chance attack?

John



Archive powered by MHonArc 2.6.19.

Top of Page