Internet2 Network Security SIG

["Montgomery, Douglas (Fed)" <>]

I always find estimates of the “error rate” of ROAs interesting.  The current global view of invalid announcements is 0.76% … i.e., considerably less than 6%.   0.27% in terms of address space announced.

 

https://rpki-monitor.antd.nist.gov/

 

Always interesting to investigate if an “invalid” announcement is a hijack, a route mis-configuration, an intentional invalid, or a ROA creation error.   Certainly we have seen examples of each of these.  So yes, some are ROA creation errors (there were a bunch of these in LACNIC that got cleaned up), but some are known invalids, and some invalids are actually catching unauthorized announcements.

 

The other interesting question, even if one was dropping invalids, would it impact actual routing?

 

ATT is the first (that I know of) large transit network to begin operational use of RPKI orgin validation (OV) filtering. They are dropping OV invalids on sessions to their peers (but not customers).   ATT reports little impact on actual routing.

 

https://www.youtube.com/watch?v=DkUZvlj1wCk&feature=youtu.be

 

We have tools that look at details of current RPKI deployment and does some deeper analysis of invalid originations to determine if the invalid announcements are covered by routes that are not Invalid (i.e., Valid or NotFound) and if so, how the paths of the invalid announcements compare to their covering, but still routable (assuming a drop invalid policy) covering routes.

 

A recent IETF presentation on this his below:

 

https://datatracker.ietf.org/meeting/104/materials/slides-104-sidrops-analysis-of-invalid-routes-00

 

One take away is that of the < 1% of invalid announcements – the vast majority of those (70-80%) are covered by routes that would not be dropped.   Many of the covering routes are from the same origin AS as the invalid announcement (i.e., you end up in the same place), many are to the same next hop, etc.

 

I2 encouraging their customers to create ROAs is a reasonable idea, or using RPKI data to clean IRR data, but another idea would be for I2 to begin filtering routes based upon RPKI OV.  If ATT can do this, I2 should be able to do it.

 

dougm

--

Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST

 

 

From: <> on behalf of Steven Wallace <>
Reply-To: " List:" <>
Date: Monday, April 15, 2019 at 4:46 PM
To: " List:" <>
Subject: Re: [Security-WG] [External] Re: ARIN, RPKI, and legal barriers....

 

I was thinking of asking the commodity providers to use ARIN’s RPKI info in the management of their networks...I realize this is a rough idea lacking specifics, and the error rate of misconfigured ROAs is something like 6% right now...

 

You bring up an interesting point. I believe I2 should require and use IRRs for their router configs. Given this could be aggregated by the RONs, it seems doable to me....and not an unreasonable requirement. ROAs are harder in the sense that you have to own the resource to sign it, meaning the RONs alone can’t do it.

 

I like the idea of requiring ROAs. IMO, it would take something like a 24 month implementation plan, that would include multiple workshops/webinars and other outreach to provide assistance to get it done. It would be a great opportunity to engage the community. It would be an opportunity for the community to demonstrate leadership in securing the internet infrastructure.

 

...now if we get pervasive IPv6 adoption....one can dream.

 

Steve

 

Sent from my iPad

On Apr 15, 2019, at 4:25 PM, Andrew Gallo <> wrote:

When you say "the community may wish to consider is asking their internet transit providers agree to use their ROA records."

 

Use them for what?  In place of IRR entries, LOAs?  Some of our upstreams have asked for nothing.  They may have checked that we have an IRR record.  On the other hand, one of our upstreams required an LOA from us allowing us to advertise our own space for an upgrade.

I'm wondering if we would have better success asking Internet2 to start requiring ROAs for all space that can be covered (that is to say, space covered by some type of agreement that allows for RPKI, which should be nearly all IPv6).

On 4/15/2019 1:52 PM, wrote:

I suggest we de-couple the issues, and here’s why:

Having more networks with ROAs makes using the RPKI database more valuable, hence more incentive to overcome its access barriers. It would only take a handful backbone providers using ARIN’s database to have a huge impact on hijacking risk.

Another incentive the community may wish to consider is asking their internet transit providers agree to use their ROA records. Perhaps The Quilt might consider adding such language to the purchasing program?

Steve

On Apr 15, 2019, at 1:32 PM, A N (via security-wg Mailing List)  wrote:

Thanks for your update. 

However, same chicken and egg situation with RPA and RPKI adoption and ARIN not budging. 

On Mon, Apr 15, 2019 at 12:21 PM < > wrote:

Thanks for the clarification. I should have said “current RSA”. Last time we requested a new resource, I think it was an additional AS, they required signing of the most current RSA. They were willing to accept changes required due to Indiana law.

Steve

Not quite.  It depends on the specific version of the RSA you have in

place.  For example, the RSA's we have signed both for v6 and the legacy

RSA are of a vintage that doesn't cover ROA use, so we have to go back 

and re-litigate the terms to get to a modern version.

As a first step, I asked ARIN to produce the specific language we had

already mutually agreed to.  After being referred to their council and 

about 8 weeks later, they are still unable to produce the specific 

language we have in place.  We had maintained copies, but appears they 

did not. 

Dale

-- 

________________________________

Andrew Gallo

The George Washington University