Internet2 Network Security SIG

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

Hmm, not sure I followed all of that.

 

You are right that RPKI-OV filtering of peers only requires ROA information, as compared to full prefix-filtering of peers which requires full recursive AS-SET expansion + full ROUTE objects.  Also RPKI-OV is applicable anywhere, regardless of relationships of neighboring ASes. E.g., you can do RPKI-OV on announcements from a provider, not just your peers.  

 

Not sure I follow David’s comment, if a bad actor is on the BGP path between a valid origin and a network doing RPKI-OV, why would they prepend anything?  They are already on the peering path.  If it is an alternative path you wish to promote, just suppress the original path/announcement.

 

Frankly, if a bad actor is actually in the sequence of BGP-speaking ASes, you have a different problem.   The only attack that would require malicious manipulation of BGP would be to drop/omit ASes from the path to either hide the bad guy, and/or shorten the path.

 

Of course any solution to manipulating the BGP path in such a manner will require either declarative data about feasible peering relationships (e.g., RPKI-ASPA, or full AS-SET data) or actually signing the path (e.g., BGPsec).

 

Maybe I misunderstood the scenario.  

 

dougm

--

Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST

 

 

From: <> on behalf of David Farmer <>
Reply-To: " List:" <>
Date: Tuesday, April 23, 2019 at 5:21 PM
To: " List:" <>
Subject: Re: [Security-WG] [External] RE: BCP for Origin validation (RFC7115)

 

 

 

On Tue, Apr 23, 2019 at 2:45 PM Steven Wallace <> wrote:

> On Apr 19, 2019, at 3:04 PM, Spurling, Shannon <> wrote:
>
> You just need to be shorter than some... How many I2 participants prepend I1 peers so traffic will better prefer I2?
>
> S-

That took a bit to fully sink in. I suspect many of us are prepending towards our transit providers, sometimes to an extreme, to maximize the benefit of TR-CPS. As Shannon points out that could severely handicap the transit providers from leveraging RPKI to prevent hijacks of our networks. I had thought that RPKI’s value to the transit providers is that they won’t have to rely on complete IRR data to filter routes from their inter-transit provider peering, where it’s least likely to be workable. Instead they can at least do origin validation so long as the resource owner created ROAs, a relatively low bar. But if we’re injecting two, four, a dozen, prepended origins then we’re effectively announcing loud-and-clear that these are subject to a relatively simple attack. Such an attack is more difficult than the simply announcing the prefix from attacker’s AS.

 

Your direct transit providers usually local preferences the routes they learn from you as a customer.  So the peers and customers of your transit providers that you prepend to have the issue you describe. However, your direct transit providers usually won't unless you de-preference your routes with BGP communities going to them. 

 

Also, RPKI doesn't have an AS-Set construct so you still need IRRs, there is work on AS Cones for RPKI, but it will be a while if it even ever gets fully baked.

 

https://datatracker.ietf.org/doc/draft-ietf-grow-rpki-as-cones/ 

 

You can also use ROAs as IRR route/route6 objects and even override IRR route objects if they conflict with a ROA.

 

Also, origin validation is no help if a bad guy is in the path between you and someone doing origin validation, all they have to do is artificially prepend your valid path, so their bogus path looks better.

 

Repeat after me "RPKI is only a start" 🤔

 

Thanks

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================