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?
> 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.)
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.
> The frontend code (parse.y and imsg passing) is missing, since this is
> already fairly large and it is tested by the unit tests I decided to
> send this out as an idividual step.
yes.
Kind regards,
Job
