Large communities indicating RPKI VALID status
Hi all, I was busy reading https://bgpfilterguide.nlnog.net/guides/reject_invalids/ and noticed the following text... Note: REALLY DONT store the validation state inside a bgp_community or bgp_large_community or bgp_ext_community variables. It can cause CPU & memory overload resulting in convergence performance issues. I was wondering if this is still an issue and if it would still be a bad idea to indicate that RPKI was VALID using communities on multiple full BGP feeds? Is anyone doing this at present? are you seeing significant load? Kind Regards Nigel
Hello Nigel, you can always store this information to custom attributes which are faster than communities, auto-ignored on export and can't leak to your peers. BTW that guide looks quite outdated (regarding e.g. the support of autoreload) and will be even more outdated with BIRD 3 optimized import tables and selective autoreload. Noting that we shall look into updating this guide. Maria On 27 April 2024 05:05:35 CEST, Nigel Kukard via Bird-users <bird-users@network.cz> wrote:
Hi all,
I was busy reading https://bgpfilterguide.nlnog.net/guides/reject_invalids/ and noticed the following text...
Note: REALLY DONT store the validation state inside a bgp_community or bgp_large_community or bgp_ext_community variables. It can cause CPU & memory overload resulting in convergence performance issues.
I was wondering if this is still an issue and if it would still be a bad idea to indicate that RPKI was VALID using communities on multiple full BGP feeds?
Is anyone doing this at present? are you seeing significant load?
Kind Regards Nigel
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
There's internet draft describing in detail, why it's not a good idea to store RPKI validation state inside community variables at all.. https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-0... - Daniel On 4/27/24 5:05 AM, Nigel Kukard via Bird-users wrote:
Hi all,
I was busy reading https://bgpfilterguide.nlnog.net/guides/reject_invalids/ and noticed the following text...
Note: REALLY DONT store the validation state inside a bgp_community or bgp_large_community or bgp_ext_community variables. It can cause CPU & memory overload resulting in convergence performance issues.
I was wondering if this is still an issue and if it would still be a bad idea to indicate that RPKI was VALID using communities on multiple full BGP feeds?
Is anyone doing this at present? are you seeing significant load?
Kind Regards Nigel
On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
There's internet draft describing in detail, why it's not a good idea to store RPKI validation state inside community variables at all..
https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-0...
Well, note that this draft is primarily about not announcing validation state in transitive attributes to the whole internet. But there are good reasons for having validation state in non-transitive BGP attributes (or communities properly filtered out on AS egress). Validating RPKI and marking routes at AS ingress ensures that all routers within AS have consistent routing state and thus avoiding routing loops. Unfortunately large communities do not have transitive flag like extended ones, so perhaps it would make sense to use extended community for this purpose. Or perhaps there should be well-known extended community for that ... -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote:
On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
There's internet draft describing in detail, why it's not a good idea to store RPKI validation state inside community variables at all..
https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-0...
Well, note that this draft is primarily about not announcing validation state in transitive attributes to the whole internet.
Yes
But there are good reasons for having validation state in non-transitive BGP attributes (or communities properly filtered out on AS egress). Validating RPKI and marking routes at AS ingress ensures that all routers within AS have consistent routing state and thus avoiding routing loops.
Perhaps I am missing something, but how does marking in itself help avoid routing loops? I am under the impression that a requirement for intra-AS transitive marking follows from non-standard modifying of non-transitive local attributes (for example, 'weight' or 'preference') based on the validation state - which is not what I'd recommend to begin with. Merely rejecting RPKI-invalid routes at the AS ingress and *not* manipulating any other local or transitive path attributes will also ensure a consistent routing state.
Unfortunately large communities do not have transitive flag like extended ones so perhaps it would make sense to use extended community for this purpose. Or perhaps there should be well-known extended community for that ...
https://www.rfc-editor.org/rfc/rfc8097.html ? Kind regards, Job
On Sun, Apr 28, 2024 at 01:00:40PM +0200, Job Snijders wrote:
On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote:
On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
There's internet draft describing in detail, why it's not a good idea to store RPKI validation state inside community variables at all..
https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-0...
Well, note that this draft is primarily about not announcing validation state in transitive attributes to the whole internet.
Yes
But there are good reasons for having validation state in non-transitive BGP attributes (or communities properly filtered out on AS egress). Validating RPKI and marking routes at AS ingress ensures that all routers within AS have consistent routing state and thus avoiding routing loops.
Perhaps I am missing something, but how does marking in itself help avoid routing loops?
I am under the impression that a requirement for intra-AS transitive marking follows from non-standard modifying of non-transitive local attributes (for example, 'weight' or 'preference') based on the validation state - which is not what I'd recommend to begin with.
Well, you are right. there are three ways how to define policy based on RPKI status: 1) Validate RPKI for all routes and apply policy based on the validation state on all routers. 2) Validate RPKI only for EBGP routes on border routers, mark result with communities, then apply policy based on marks on all routers. 3) Validate RPKI only for EBGP routes on border routers, apply policy based on validation state there and use (non-transitive) BGP attributes for policy (like bgp_local_pref) to propagate it through AS. The first approach is bad and can easily lead to inconsistent routing, the second is better as marking ensures that different routers have consistent view of validation states of routes, but the third approach is even better and does not require explicit marking of validation states (although one could argue that the validation state is implicitly encoded in the policy-carrying BGP attributes).
Merely rejecting RPKI-invalid routes at the AS ingress and *not* manipulating any other local or transitive path attributes will also ensure a consistent routing state.
Obviously.
Unfortunately large communities do not have transitive flag like extended ones so perhaps it would make sense to use extended community for this purpose. Or perhaps there should be well-known extended community for that ...
Thanks, i was not aware of this. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes. Why would one want to accept INVALID at all? If we agree one would reject INVALID, then what is left to tag? -- Richard
Hi there Richard, On 4/29/24 19:14, Richard Laager wrote:
Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes.
Why would one want to accept INVALID at all?
If we agree one would reject INVALID, then what is left to tag?
For my specific use case I wanted to add a community for VALID and UNKNOWN. I'm going to look into the non-transitive extended communities to see how this works out.
On Mon, 29 Apr 2024 at 21:27, Nigel Kukard via Bird-users < bird-users@network.cz> wrote:
Hi there Richard,
On 4/29/24 19:14, Richard Laager wrote:
Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes.
Why would one want to accept INVALID at all?
If we agree one would reject INVALID, then what is left to tag?
For my specific use case I wanted to add a community for VALID and UNKNOWN. I'm going to look into the non-transitive extended communities to see how this works out.
Sure, but why add such communities? It reduces performance and doesn’t add security benefits. OTOH - it can satisfy curiosity about where traffic is flowing - then again, using a traffic analyser like pmacct or Kentik helps offer insight how much traffic is going to Valid vs Not-Found destinations, without the need to add any communities. I’m not saying you shouldn’t pursue adding a few non-transitive extended communities here and there for your use case; just that generally speaking, operators probably should not apply different policies for Valid and Not-Found states. Kind regards, Job
On 4/29/24 19:33, Job Snijders wrote:
On Mon, 29 Apr 2024 at 21:27, Nigel Kukard via Bird-users <bird-users@network.cz> wrote:
Hi there Richard,
On 4/29/24 19:14, Richard Laager wrote:
Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes.
Why would one want to accept INVALID at all?
If we agree one would reject INVALID, then what is left to tag?
For my specific use case I wanted to add a community for VALID and UNKNOWN. I'm going to look into the non-transitive extended communities to see how this works out.
Sure, but why add such communities? It reduces performance and doesn’t add security benefits.
OTOH - it can satisfy curiosity about where traffic is flowing - then again, using a traffic analyser like pmacct or Kentik helps offer insight how much traffic is going to Valid vs Not-Found destinations, without the need to add any communities.
I’m not saying you shouldn’t pursue adding a few non-transitive extended communities here and there for your use case; just that generally speaking, operators probably should not apply different policies for Valid and Not-Found states.
Well, basically to summarize, I have quite a number of edges. My filtering occurs on the edges, including filtering of INVALID. I'm using bird to gather all prefixes from all routers using add-paths so I can easily do searches on my dashboard and graphically map paths to destinations and visually see other possible paths that are not best path. As my filtering occurs on the edge I don't have a way on my dashboard to see if the prefix was VALID or UNKNOWN. I thought it would be something useful to see so I can color the routes that are VALID in a dark green or have a small green box with [RPKI VALID] in it next to the prefix. But I certainly see the points raised. It's not used for anything more than analysis and visual display. I'm looking into pmacct and Opensearch to see if I can get Netflow/IPFIX data to help with insight into traffic flows (slightly different to visually seeing possible traffic paths). I'm very new to Elasticseach and Opensearch though and would appreciate if anyone has any recommendations of opensource platforms I can use to give me some info from Netflow/IPFIX data I'd really appreciate it. I did check out Kentik and Elastiflow, but my network is small and doesn't really have the income to support a paid product right now if I can achieve reasonable results with other options. -N
Hey there,
I'm using bird to gather all prefixes from all routers using add-paths > so I can easily do searches on my dashboard and graphically map paths > to destinations and visually see other possible paths that are not best path.
Interesting, how do you do this?
I'm looking into pmacct and Opensearch to see if I can get Netflow/IPFIX data to help with insight into traffic flows (slightly different to visually seeing possible traffic paths). I'm very new to Elasticseach and Opensearch though and would appreciate if anyone has any recommendations of opensource platforms I can use to give me some info from Netflow/IPFIX data I'd really appreciate it.
Maybe take a look at akvorado: https://github.com/akvorado/akvorado I know some people using netmeta (it's still on my "to try" list): https://github.com/monogon-dev/NetMeta Both use clickhouse as a DB which performs much better than elastic-/opensearch Java behemoths. Best, fran
participants (7)
-
Daniel Suchy -
Fran -
Job Snijders -
Maria Matejka -
Nigel Kukard -
Ondrej Zajicek -
Richard Laager