Per-AS monitoring for self-sourced prefix hijacks and/or new advertisements

[smith8917]

An ARTEMIS user may want to monitor their own AS for newly advertised prefixes.

There are two scenarios I can foresee this being useful for an engineer:
1) Internal misconfigurations that hijack a prefix from another ASN: For example, if I am monitoring 134.55.0.0/16 for our AS, ESnet (AS293), and an ESnet engineer misconfigures the BGP policy to advertise 133.55.0.0/16 instead, we'd want to know via an ARTEMIS alert so that we can fix the configuration before it impacts our internet neighbor.

2) Any new prefix advertisements: Alerting on a new prefix (whether it's configured or not in ARTEMIS) advertised by your own ASN provides an automated mechanism for verifying new configurations from an external point of view.

To achieve this, instead of monitoring /0 for all un-configured prefixes, it may be less intensive to monitor AS_PATHs in the global table for ARTEMIS-configured ASNs and compare them to a previously seen prefix-list and/or against the configured prefixes

[smith8917]

A colleague brought up another situation where this happens, specifically to ESnet, but possibly others. There's BGP prepending documentation around the Internet that suggests an engineer should prepend "16" times. Unfortunately, this results in institutions prepending "16" (one of our customer's ASNs) to the AS_PATH. This would result in the above-mentioned behavior that we're trying to detect/alert based on.

[slowr]

@smith8917 while I understand the use-case the problem is that the monitors are prefix-based which mean that we can't avoid the /0 monitoring to achieve the wanted behavior.

I will need to take a deeper look to see if it is possible without spending so many resources!

[vkotronis]

The only related thing that can be probably done by RIS live (not bgpstream, which monitors both RIS and RV sources based on prefix filtering, or exabgp, which is interfaced using a socketIO client subscribing to IP prefixes), is using the "path" filter, as shown in https://ris-live.ripe.net/

A single AS number or a comma-separated string of AS numbers. Can optionally begin with ^ to only match the first item of the path (which is the last traversed ASN), or end with $ to only match the last item of the path (which is the originating ASN). e.g. 789$ to match all paths that originate from AS789.

I am not sure if it can support regexes also for 1st hop neighbors in concert with valid origins, etc.

In general, AS-path monitoring seems that this can only work for the RIS live monitor, and will require changes in how we treat the user configuration (having ASNs, instead of prefixes, as basic primitives to be protected in the rule(s)).

@slowr yes let's coordinate on how to address this, would be interesting to check how we can monitor ASNs that advertise things they are not supposed to without monitoring the entire address space (even if it can be done by only one monitoring service).

[vkotronis]

Currently this is feasible for RIPE RIS as discussed, adding to the next milestone (1.5.0 release).

[vkotronis]

Since to address this issue we need to adapt a great part of the current monitoring and detection approach of ARTEMIS (AS- vs prefix-oriented), we will move this to a 2.0 milestone (breaking version). It holds that monitoring-wise only RRIS offers the option of filtering paths based on AS, so the solution will be feasible only for this source. The alternative of monitoring the entire /0 (v4 and v6) is not feasible for an AS-oriented system, so we will assess building around this for 2.0.

[smith8917]

The only related thing that can be probably done by RIS live (not bgpstream, which monitors both RIS and RV sources based on prefix filtering, or exabgp, which is interfaced using a socketIO client subscribing to IP prefixes), is using the "path" filter, as shown in https://ris-live.ripe.net/

A single AS number or a comma-separated string of AS numbers. Can optionally begin with ^ to only match the first item of the path (which is the last traversed ASN), or end with $ to only match the last item of the path (which is the originating ASN). e.g. 789$ to match all paths that originate from AS789.

I am not sure if it can support regexes also for 1st hop neighbors in concert with valid origins, etc.

In general, AS-path monitoring seems that this can only work for the RIS live monitor, and will require changes in how we treat the user configuration (having ASNs, instead of prefixes, as basic primitives to be protected in the rule(s)).

@slowr yes let's coordinate on how to address this, would be interesting to check how we can monitor ASNs that advertise things they are not supposed to without monitoring the entire address space (even if it can be done by only one monitoring service).

@vkotronis - as of this morning, bgpstream supports path monitoring in the form of path regex or from an origin perspective. So, it should be possible to compare the prefixes seen in the stream against the configured prefix list for an ASN and trigger alerts based on any unexpected prefixes seen. Here's an example how this can be pulled from CAIDA/routeviews:

bgpreader -o url=https://broker.bgpstream.caida.org/dev -p routeviews-stream -a 293 WARN: No time window specified, defaulting to live mode U|A|1597703877.938550|routeviews-stream|is-ah-bmp1|linx|195.66.241.146|58511|2001:7f8:4:1::e48f:1|2001:400::/32|2001:7f8:4:1::e48f:1|6447 58511 6939 293 293 293|293||| U|A|1597703877.939942|routeviews-stream|is-ah-bmp1|linx|195.66.241.146|58511|2001:7f8:4::e48f:1|2001:400::/32|2001:7f8:4::e48f:1|6447 58511 6939 293 293 293|293|||

[vkotronis]

@smith8917 thanks for this update, we will check out what is needed implementation-wise for this since the current detection mechanism is based heavily on prefixes (configured by the user given his ASNs) instead of ASNs (originating any kind of prefix). So while the mechanism might be simple to add to the monitors, what is trickier is changing the design primitives we use to declare hijacks (well, this is actually a "self-hijack"/leak we are taking about). I need to coordinate with available developers to decide on a proper workflow to work on this.

[smith8917]

Hi folks, it's been a while since this has been updated. Is there a new timeline for this feature request?

[vkotronis]

Hi folks, it's been a while since this has been updated. Is there a new timeline for this feature request?

@smith8917 thanks for the feature request Eric. We have not followed up on this since the current ARTEMIS design and implementation (especially the detection and prefix trie logic) do not allow easy comparisons on the ASN level (for arbitrary prefixes). The main logic is that ARTEMIS ingests the prefix-based conf file, turns it into an in-memory prefix trie for real-time lookups and uses multiple detectors to determine deviations between prefixes and ASNs that originate them (or are present in paths towards them) from incoming BGP updates from sources we have subscribed in. While data sources may support ASN filtering (like in the comments we exchanged on this thread), the hard part is the detection logic and the architectural approach. We plan to account for route leak detection and per-AS monitoring in our spinoff commercial version (in the alerting logic feature) which is redesigned from scratch to account for different use cases (like per-prefix, per-AS/etc. monitoring). Leaving the issue open for now in case we do a holistic refactoring of the detection approach to account for such events (which are not prefix hijacks per se, i.e., the primary objective of ARTEMIS, but misconfigurations).