On Fri, Sep 14, 2018 at 05:27:03PM +0200, Job Snijders wrote: > Dear Claudio, > > On Fri, Sep 14, 2018 at 04:59:51PM +0200, Claudio Jeker wrote: > > This diff extends the existing trie code for prefix-set to also work with > > roa-set. Unlike prefix-set there is no need for a prefixlen mask during > > lookup, instead the source-as needs to be checked and also if the > > prefixlen of the prefix is allowed. > > The lookup can return 3 states: > > ROA_UNKNONW: prefix is not covered by any entry > > ROA_VALID: prefix is covered and the source-as matches as does the prefixlen > > ROA_INVALID: there was a covering ROA entry that did not match source-as > > or prefixlen > > I didn't test yet - but from your above description I have these three > questions. > > Given this ROA file with two entries: > > prefix 80.128.0.0/11 maxlen 11 source-as 0 > prefix 80.128.0.0/11 maxlen 11 source-as 3320 > > 1/ The following announcement "80.128.0.0/11 AS_PATH 2914_3320" received > via (E)BGP must result in ROA_VALID state. An announcement must be > considered ROA_VALID if it correctly matches /any/ of the configured > ROAs. So the presence of "80.128.0.0/11 maxlen 11 source-as 0" should > not invalidate any other ROA. Does this match your understanding too?
Yes. The code currently traverses the trie and gets to the 80.128.0.0/11 node. Until then the internal state is ROA_UNKNOWN but now the this prefix is found the ROA state is moved to ROA_INVALID and a as_set lookup for 3320 is done, which matches and maxlen >= prefixlen so ROA_VALID is returned and the search stops. If another AS is announcing 80.128.0.0/11 the as_set will not match and so the state remains ROA_INVALID and on the next step prefixlen is smaller than the node prefixlen and so the search ends returning ROA_INVALID. Also AS 0 is specially treated and will never match for ROA_VALID, instead it will make everything under that prefix ROA_INVALID unless a more specific route matches. > > The source-as check is done with an as_set and should therefor scale > > well. In general these lookups need to be quick since all prefixes > > will go through roa lookups. > > 2/ I take it that (iff a ROA file is defined) any and all announcements > will go through the lookup? (I think this is good.) Currently this is not yet done. This diff only includes the functions to implement this. I have not yet decided how to hook this up into filtering and config in general. My plan at the moment is to extend struct prefix to include a validity field that can be one of valid, invalid, unknown. The filter rule then can do matching on this state. Now how this works if more then just the RPKI ROA table is needed is unclear. Also undecided is if we should push internal announcements through this as well. I currently tend to say yes and have all prefixes validated. > 3/ If the contents of the roa_file are change, and a 'bgpctl reload' is > issued - the validation state should be reevaluated. For instance if we > start with: > > prefix 80.128.0.0/11 maxlen 11 source-as 0 > prefix 80.128.0.0/11 maxlen 11 source-as 3320 > > and have announcement 80.128.0.0/11 AS_PATH 2914_3320 (ROA_VALID) in > Loc-RIB, the moment the ROA file is changed to: > > prefix 80.128.0.0/11 maxlen 11 source-as 0 > prefix 80.128.0.0/11 maxlen 11 source-as 666 > > the announcement 80.128.0.0/11 AS_PATH 2914_3320 should become > ROA_INVALID. Should we get to the point where we can filter based on > validation state, and I configured something like: > > deny from ebgp validation-state invalid > > The 80.128.0.0/11 AS_PATH 2914_3320 announcement should become an > infeasible/rejected path. Yes, this is the plan. Is currently not yet implemented but on my todo list. This is an additional step on the softreconfig in code path. This is also mostly coupled with the config parsing and passing code which is still missing. -- :wq Claudio
