Internet2 Network Security SIG

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

I can assure you the issue of supporting planned and unplanned (emergency) announcements from DDoS mitigation providers was discussed throughout the development of RPKI.

 

There is a bit of a double edged sword here.   Any ROA authorized announcement of a longer prefix than is actually announced under normal operation, creates the opportunity for a forged origin attack of just prepending the authorized AS to a bogus announcement.  While the resulting bogus path will be 1 hop longer than otherwise necessary, the BGP decision process assures it would always win.

 

There are some proposals under development to address this issue – see: https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/, but they are in the early stages.  These proposals include registered peering relationships in RPKI objects, thus making prepending the authorized origin even harder, because you would have to prepend the first “N” hops.   The semantics of such approaches allow one to validate that a subset (first N hops) are a feasible path.  This is slightly different than actually signing the update at each hop.

 

Or course long term BGPsec, that signs each hop, would address these authorized origin pre-pending attacks.

 

WRT RPKI propagation times, these are clearly a function of the rate at RIRs update their publication points, validating caches sync vs RIRs, and routers sync against caches.   In theory the worst case is the sum of each of these timers, average is half of that.  In practice, there have been some emulation studies of parts of this process: https://datatracker.ietf.org/meeting/interim-2012-sidr-05/materials/slides-interim-2012-sidr-5-4

 

The only measurements of how things are actually playing out in the Internet today that I know of is here:

 

Towards a Rigorous Methodology for Measuring Adoption of RPKI Route Validation and Filtering:  https://arxiv.org/pdf/1706.04263.pdf  Their work sees measured / inferred ROA propagation times of up to 8 hours.

 

Also from that work is a monitor of networks that appear to be filtering based upon RPKI based upon experiments from the project above.

 

dougm

--

Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST

https://www.nist.gov/itl/antd/internet-scalable-systems-research

 

From: <> on behalf of Brad Fleming <>
Reply-To: " List:" <>
Date: Friday, August 17, 2018 at 6:11 PM
To: " List:" <>
Subject: Re: [External] Re: [Security-WG] Generating an RPKI ROA request with lots of prefixes

 

Agreed. It seems odd that features like "prefix-length-range" or "prefix-list 1.1.1.1/16 ge 23 le 24" have been around for a long time but didn’t make it into the RPKI standards. Seems like it would this problems gracefully.

 

As far as maximum length I’m assuming “The Internet” will probably not allow prefixes more specific than /48; much like the social norm around announcing a /24 IPv4 prefix to the DFZ.

 

Either way, the tools not accepting the ROA means I doubt anyone ever thought the use case through (unfortunately).

--
Brad Fleming
Assistant Director for Technology
Kansas Research and Education Network
Office:

785-856-9805
Mobile:

785-865-7231
NOC:

785-856-9820

 

On Aug 17, 2018, at 3:38 PM, Garrett, Seth B <> wrote:

 

Wishful thinking...  It would be handy if the RPKI ROA allowed for a range and not just a limit of maxlength.  Similar to the Juniper route filter.

 

route-filter 129.79.0.0/16 prefix-length-range /24-/24

2001:18e8::/44 prefix-length-range /64-/64

 

Allows only /24's from within the /16 for IPv4 or /64's from the /44 for IPv6.  

 

Seth Garrett
Principal Network Engineer
Indiana University

---

From:  <> on behalf of Brad Fleming <>
Sent: Friday, August 17, 2018 4:13 PM
To: 
Subject: [External] Re: [Security-WG] Generating an RPKI ROA request with lots of prefixes

 

This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.

Thanks very much for the script and examples.

 

So is prevailing notion to make a ROA including the 65K /48s within a typical /32 assignment? I suppose I’m OK with the approach, just seems like that ROA is gonna crazy huge.

--
Brad Fleming
Assistant Director for Technology
Kansas Research and Education Network

 

On Aug 15, 2018, at 12:55 PM, Andrew Gallo <> wrote:

 

Greetings, Security WG:

Seth Garrett and I have been trading some emails about creating a ROA request with a lot of prefixes.  I've written a script that can make this easier.
https://github.com/CAAREN-engineering/generateSignedROAreq

Here's the scenario and use-case:

If you have a large summary prefix, let's say an IPv4 /16, and you would like to cover this prefix AND all the /24s within it, you *could* use the Max Length feature to create a ROA request for 172.16.0.0/16-24. HOWEVER, use of Max Length field is no longer recommended (can lead to larger attack surface).

You might want ROAs covering all the constituent /24s so that they can be originated by a DDoS scrubbing service.

At this point, following best practices, you're left with entering 256 prefixes by hand in the Hosted RPKI portal.  There is another way!

You can pasted into the portal pre-formatted, pre-signed text.

ARIN's instructions are here:
https://www.arin.net/resources/rpki/roarequest.html

I wrote a script to help make this process easier.  What you'll need:
Python 3.3+
a file containing a list of prefixes you want included in the ROA (you can mix v4 and v6)
Your private key

The script will ask you some basic information needed to create the ROA request data:
Origin ASN
ROA name
Validity Start Date
Validity End Date


Let me know if you have any questions.



-- 
________________________________
Andrew Gallo
The George Washington University