Re: Analysing traffic in context of rejecting RPKI invalids
If at least one ROA matches a route, then the route is valid. This is to cover the case when more than one AS is authorized to originate a particular prefix. https://tools.ietf.org/html/rfc6811 Page 5: o NotFound: No VRP Covers the Route Prefix. o Valid: At least one VRP Matches the Route Prefix. o Invalid: At least one VRP Covers the Route Prefix, but no VRP Matches it. BTW, this rule allows you to issue a ROA authorizing AS0 to originate your complete address space. Why would you do that? Suppose you own an address space, but you only want to announce a portion of it to the internet. If you issue a ROA for the unannounced portion authorizing your own ASN, then an attacker can announce that portion and prepend your ASN. The attacker can thus hijack your unannounced space and appear valid by RPKI! To prevent that, you issue a ROA for your complete address space authorizing AS0 and your BGP announced space authorizing your own ASN. An AS path containing AS0 is malformed, being treated as withdraw. https://tools.ietf.org/html/rfc7607 Regards, Jakob. -----Original Message----- Date: Wed, 13 Mar 2019 11:17:22 -0400 From: Steve Meuse <smeuse@mara.org>
Thanks for the update, but based on that description I'm not certain that you implemented the same thing that pmacct built, which IMO is what is needed by those considering deploying a drop-invalids policy. (Perhaps you omitted mentioning that ability in your description but included it in your implementation.)
Thanks Jay, you are correct. As we were talking through the logic we realized we missed that bit. Internally, we're working though the logic to understand if there is a covering route, is that route valid, and if not, will we recurse and look for another covering route that is valid? Either way, we'll be updating our software with that functionality shortly. -Steve
participants (1)
-
Jakob Heitz (jheitz)