Conversation
Depending on how many and what parameters exactly are passed to roa_check(), the function performs a fast - RFC-compliant - check, or a slower check, potentially even using the wrong part of the AS_PATH attribute. Calling the facility as "roa_check(table)" checks the route origin validation state of the route at hand in the specified ROA table. Using the facility in this particular way, is the way recommended by the BIRD developers. The "roa_check(table, prefix, asn)" variant is an explicit version of the above described ROA check for users who for whatever reason need to check a different prefix or different ASN than the default one. The equivalent call to the above mentioned short variant is "roa_check(table, net, bgp_path.last)" but, according to docs, it is faster to call the short variant. Calling roa_check() with "bgp_path.last_nonaggregated" is problematic because it might result in a misapplication of the RFC 6811 origin validation procedure. This PR also resolves a logging inconsistency where the routing policy would conduct check "bgp_path.last_nonaggregated" but end up logging a message using "bgp_path.last", which can result in hard-to-troubleshoot situations.
Member
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depending on how many and what parameters exactly are passed to
roa_check(), the filter language operator function performs a fast - RFC-compliant - check, or a slower check, potentially even using the wrong part of the AS_PATH attribute.Background: calling the facility as
roa_check(table)checks the route origin validation state of the route at hand in the specified ROA table. Using the facility in this particular way, is the way recommended by the BIRD developers.The
roa_check(table, prefix, asn)variant is an explicit version of the above described ROA check for users who for whatever reason need to check a different prefix or different ASN than the default one. The equivalent call to the above mentioned short variant isroa_check(table, net, bgp_path.last)but, according to docs, it is faster to call the short variant.Calling
roa_check()withbgp_path.last_nonaggregatednot only is slower, but also problematic from a compliance perspective, because it might result in a (silent) misapplication of the RFC 6811 origin validation procedure: the wrong ASN might be passed into the operator as the Origin ASN.This PR also resolves a logging inconsistency in router/server/bird2/rpki.foil.php where the routing policy would conduct check
bgp_path.last_nonaggregatedbut end up logging a message usingbgp_path.last, which can result in hard-to-troubleshoot situations.