ARTEMIS and the minute between a BGP warning and a safe response

Summary

• ARTEMIS is an operator-run open-source system that compares live BGP observations with local routing intent, giving networks context that public collectors alone cannot supply.
• FORTH and CAIDA’s 2018 research reported detection within seconds and neutralisation within a minute in tested conditions; the result is not a universal production guarantee.
• Its mitigation can announce more-specific routes or invoke custom workflows, but filters, stale policy, incomplete visibility and broad credentials can turn a fast response into a second incident.
• The project now depends on disciplined releases, credible deployment evidence and a transparent boundary with Code BGP, whose commercial maintenance may sustain the open software without replacing its research history.

A real route change showed why seconds are only the beginning

CAIDA’s 2019 annual report says ARTEMIS detected a real hijack affecting an Internet2 /30 within seconds. The event is important because it moves the evidence beyond synthetic announcements designed by the researchers. A live route changed in a network participating in the deployment, and the system recognised the deviation quickly enough to support investigation.

The report does not establish a universal detection distribution. A /30 is a specific prefix in a specific routing context, observed through the feeds available to that deployment. Another event may propagate differently, last for less time or remain outside the connected collectors. The report also does not, by itself, prove malicious intent or every data-plane effect. The safe conclusion is that ARTEMIS detected one reported real event within seconds during the CAIDA deployment programme.

Case studies have value precisely when their limits are kept. They reveal how the software behaves around actual change, how operators receive the alert and which evidence is available afterwards. More incident records, including false positives, missed events and mitigation outcomes, would do more to establish production maturity than another headline timing claim.

A BGP alert can arrive in seconds and still leave the most important questions unanswered. A route collector may show that an unfamiliar autonomous system has announced a prefix, or that a more-specific route has appeared and begun to propagate. That evidence tells an operator that the control plane no longer matches an expected pattern. It does not, by itself, establish who made the change, whether it was accidental, whether traffic followed the new path, whether users were harmed or which response will restore service without creating another problem.

ARTEMIS was designed around that gap between detection and action. Its name expands to Automatic and Real-Time dEtection and MItigation System, but the capitalised acronym should not distract from the operating model. It is not a central service that watches the whole internet and repairs other networks from afar. An organisation deploys the software in infrastructure it controls, defines the routing state it considers legitimate, connects public and private observations, and decides how far the system may go when those observations depart from policy.

The project’s promise is speed with context; its constraint is that context and authority are local.

ARTEMIS is therefore less like an internet police force than an operator-owned control-room instrument. It can organise evidence, reduce the time spent searching through route updates and prepare a response that has already been discussed. It cannot relieve the operator of judgment. The final decision may affect global routing, upstream relationships and customer traffic, so the quality of the response depends on people, configuration and rehearsed authority as much as on the detector.

BGP can carry reachability before it can prove authority

The Border Gateway Protocol allows independently operated networks to exchange reachability information and apply local policy. An autonomous system announces that it can reach a set of IP prefixes; neighbouring networks decide whether to accept, prefer and pass on those routes. This arrangement made the internet scalable across organisations that do not share one controller, but the original protocol does not attach a cryptographic proof to every claim about origin or path. A mistaken export, a stale configuration or a deliberate announcement can therefore introduce a route that should not exist.

Routing selection can make a bad announcement attractive. When two routes cover the same prefix length, networks apply policy and path-selection rules that vary by operator. When an attacker or mistaken network announces a more-specific subprefix, normal longest-prefix matching usually directs traffic towards the narrower route wherever it is accepted. The mechanism is not a special attack feature; it is the ordinary rule that lets routers choose the most precise destination. That is why an apparently small announcement can redirect traffic quickly even if the legitimate aggregate remains visible.

The word “hijack” is useful shorthand but can imply intent that the routing messages do not reveal. An unauthorised origin may be malicious, accidental or the result of a legitimate commercial change that was not reflected in monitoring policy. A fabricated path can be used to intercept traffic, but a control-plane update cannot prove interception. ARTEMIS therefore works best when it treats the alert as a divergence between observed routing and intended routing, leaving attribution and impact to a wider incident process.

An exact-prefix event competes with the legitimate route at the same prefix length. Its reach depends on the policies and path choices of networks that receive both announcements. Some parts of the internet may prefer the unexpected route, while others continue to use the legitimate origin. The result can be partial reachability, regional differences and a confusing mixture of success and failure rather than one clean outage. Detection must therefore pay attention not only to the existence of a route but to where and how it propagates.

A subprefix event often has a more direct pull because longest-prefix matching gives the narrower route priority. If a network normally announces a /20 and another origin announces a /24 inside it, routers that accept the /24 generally send traffic for those addresses towards the subprefix. Deaggregation is also a common defence: the legitimate operator announces matching or still more-specific routes to regain preference. The defence reaches a hard boundary, however, because many networks filter IPv4 routes longer than /24 and IPv6 routes longer than /48.

An operator already announcing at those lengths may have no globally accepted narrower route available.

ARTEMIS also considers squatting and selected policy violations, including a no-export pattern described in the project material. These categories matter because routing incidents are not limited to a stranger originating a victim’s prefix. A route can have an authorised origin and still be exported through an unexpected relationship. A monitoring system needs enough policy context to distinguish those cases without pretending that BGP data exposes every private agreement between networks.

ARTEMIS puts the operator’s own routing intent inside the detector

External monitoring services have an obvious advantage: they can collect information from many parts of the internet without requiring each network to run a full system. Their disadvantage is equally important. A third party can see announced prefixes and paths, but it may not know which origin changes, backup providers, traffic-engineering paths or emergency advertisements the operator considers legitimate. Generic rules can therefore miss subtle policy breaches or raise alarms on planned changes.

ARTEMIS reversed the viewpoint. The detector is operated by the organisation whose address space is at risk, and that organisation supplies the ground truth. Public collectors still provide broad external visibility, but their observations are interpreted through private knowledge of protected prefixes, authorised origin ASes, acceptable neighbours and selected path relationships. Local router feeds can add events that public collectors do not see. The combination is the project’s defining idea: incomplete global evidence becomes more useful when compared with explicit local intent.

Placing the detector inside the defended network also moves responsibility inward. A network that maintains ARTEMIS must decide who owns the policy file, how changes are reviewed, which alerts reach the network operations centre, what the security team is allowed to infer and who can authorise a new route. The software can make that responsibility visible. It cannot make the institution perform it well.

ARTEMIS asks the operator to define protected prefixes, legitimate origin ASes, acceptable neighbour relationships and selected routing rules. This ground truth allows the detector to ask a more precise question than a generic monitoring service can ask. Instead of deciding whether a route looks unusual compared with global history, the system can decide whether the route violates the network’s declared intent.

That advantage is only as reliable as the declaration. Networks change providers, add anycast sites, shift origin ASes, establish temporary backup paths and make emergency advertisements during outages. A policy that is accurate in January may be wrong by June. If the operational change reaches routers but not ARTEMIS, the detector may generate a high-severity false positive. If the policy is broadened carelessly to suppress noise, a real violation may become authorised on paper.

The system therefore turns a technical configuration into an institutional contract. Routing engineering, security operations and change management must agree on what the file means, who may edit it and how quickly it follows production. The project’s local context does not eliminate false positives and false negatives; it moves their most important source into a place the operator can govern.

A routing-security rule deserves the same discipline as software that can affect customer traffic. Changes should have named owners, review, version history, tests and a reason linked to an approved network change. The operator should be able to answer when a prefix, origin or neighbour was added, who authorised it and which incident or project justified the decision. A plain configuration file can support that process, but only if the organisation treats it as more than a one-time installation step.

Testing should include both positive and negative cases. A legitimate planned route should pass without an alert. An exact-prefix announcement from an unauthorised origin should trigger the expected classification. A subprefix event should show the right severity, and a no-export violation should not be confused with an origin hijack. Historical replay can support these checks, while a staging environment can verify that notifications and mitigation wrappers receive the intended data.

This discipline also limits the danger of organisational drift. When the person who first deployed ARTEMIS leaves, the policy should remain understandable to the next operator. A detector whose logic depends on undocumented memory is not reliable infrastructure, even when its code is open and its feed latency is low.

FORTH and CAIDA turned a research question into an operator workflow

The project originated in collaboration between researchers at the Foundation for Research and Technology-Hellas, within the University of Crete ecosystem, and CAIDA at the University of California San Diego. FORTH contributed routing-security and systems work. CAIDA brought internet-measurement infrastructure, BGPStream expertise and relationships that helped move the design into research and education networks. The project was therefore never only a detection algorithm; it joined protocol knowledge, measurement systems and operator access.

Funding followed the same mixed institutional pattern. European and United States research programmes, RIPE NCC Community Projects Fund support, an NSF EAGER deployment project, the US Department of Homeland Security and the Comcast Innovation Fund appear in the project record. RIPE support in 2017 helped move the prototype towards an operator-facing tool, while a €50,000 award in 2019 funded work on data-plane verification using RIPE Atlas. Those grants show how public-interest research became deployable software, but they do not reveal the current cost of maintaining production installations.

The institutional history matters for attribution. ARTEMIS is not a separately incorporated foundation, a CAIDA service or a FORTH-owned global detector. It is open-source software under the BSD 3-Clause licence, with a research lineage and a current commercial maintainer. The project’s development path is best understood as a sequence of collaborations rather than the property of one organisation.

The first public milestone was an ACM SIGCOMM demonstration in 2016. At that stage, the important move was to connect monitoring and mitigation in one loop. Many systems can identify a suspicious route after collecting enough evidence. ARTEMIS asked whether an operator could detect the event quickly enough and already have a practical countermeasure available, so that the incident did not spend hours moving between dashboards, emails and manual router sessions.

A demonstration is not a mature production deployment. It establishes that components can work together under a defined setup and that the research problem is concrete enough to show. The 2016 work nevertheless set the direction for everything that followed: live observations, an internal view of legitimate routing, classification and a prepared announcement. That sequence turned response time from an organisational afterthought into a system property.

The design was informed by operator evidence that hijack response could take hours. Delay did not come only from slow route collectors. Teams had to confirm ownership, inspect propagation, decide whether the event was planned, find the right upstream contacts and construct a safe mitigation. ARTEMIS could reduce several of those steps by keeping policy and workflows close to the monitoring system, but the human and commercial relationships around the route remained outside the code.

The 2018 IEEE/ACM Transactions on Networking paper gave ARTEMIS its most memorable claim: neutralising BGP hijacking within a minute. The researchers evaluated the approach through real-world experiments and reported detection within seconds and mitigation within the minute under the conditions they tested. That result was significant because it showed that a victim network did not necessarily have to wait for a third-party service, a telephone chain and a manually assembled counter-announcement.

The phrase becomes misleading when detached from the experiment. Detection time depends on whether the event reaches a connected monitor, how quickly the feed delivers the update, how the detector’s rules match it and whether the system is healthy. Mitigation time depends on the victim’s prefix length, routing authority, upstream filters, propagation and the chosen approval process. A network that requires a human confirmation may make a safer decision and take longer. A network that automates immediately may respond faster and accept more risk.

The responsible conclusion is bounded. ARTEMIS demonstrated that a tightly integrated operator-side system can compress a process that often took far longer. It did not prove that every hijack is visible, every counter-route is accepted or every production team should allow autonomous deaggregation. The result should be read as a design objective supported by an experiment, not as a universal guarantee.

Several incomplete views build a usable incident record

ARTEMIS can draw on several public sources because no single collector sees every route. RIPE RIS and the University of Oregon’s RouteViews project receive BGP updates from selected peers at distributed collection points. CAIDA BGPStream provides a framework for accessing and normalising routing data from several sources. Each service expands the operator’s field of view, yet each also reflects the networks that choose to peer with its collectors, the locations of those sessions and the timing of their feeds.

This partial visibility has practical consequences. An event may propagate to one region and never reach the collectors used by a deployment. A very short announcement may be withdrawn before the feed delivers it. A route may affect the victim’s customers through a private relationship that is not represented in the public data. Combining collectors reduces some blind spots, but the result is a larger sample, not an omniscient copy of the global control plane.

The correct operating question is therefore not “Did ARTEMIS see the internet?” It is “Which observers saw this announcement, how quickly did they see it and what part of the event might still be outside the sample?” That wording encourages operators to retain provenance for each alert and to avoid treating absence from one feed as proof that a route did not exist.

RIPE NCC introduced the public RIS Live prototype in February 2019 to stream BGP messages with far less delay than periodic archive processing. ARTEMIS became one of the examples of why such a feed matters. A security system cannot respond in seconds if its main observation arrives many minutes later, and a live stream allows the detector to evaluate updates as collectors receive them.

Lower latency does not change what the collectors can observe. RIS Live still reflects the peers connected to the RIPE Routing Information Service and the routes those peers export. If a hijack remains local, is filtered before reaching a collector or affects a path hidden behind another relationship, the feed may never carry the decisive evidence. Reliability also matters: a stream outage or schema change can look like silence unless the monitoring service distinguishes “no suspicious routes” from “no data.”

This is why feed health belongs inside the security model. An operator needs to know whether each monitor is current, delayed, disconnected or producing an unusual volume of updates. A detector that presents one confident status while its inputs are degraded can create a more dangerous form of ignorance than an explicit outage.

Real-time monitoring answers what is appearing now, while route information bases and update archives provide context. RIPE RIS and RouteViews publish historical data that can show what origins and paths were visible before an incident, when a change began and how long it persisted. CAIDA BGPStream makes those records easier to process through a common framework, allowing ARTEMIS to replay events and test rules against past routing behaviour.

Replay is useful for engineering and review. A team can examine whether a new policy would have caught a known event, reproduce the sequence that led to an alert or teach responders without manipulating a live production route. Historical evidence can also expose recurring announcements that look abnormal in isolation but represent an established backup arrangement. The limitation is that an archive preserves the collectors’ view, not the entire event, and a past topology cannot reproduce every current relationship.

A mature deployment can use replay as part of change control. Before a new origin, upstream or export rule enters production, the operator can test the revised ground truth against representative history and confirm that it does not turn ordinary routing into a permanent alarm. That practice makes the detector’s configuration an auditable security artefact rather than a file edited only after it causes noise.

Public data is only one side of the design. ARTEMIS can receive local updates through ExaBGP or private BGP Monitoring Protocol sessions. ExaBGP can act as a programmable BGP speaker and feed route events into other software. BMP allows routers to export routing information to a monitoring system without making that system part of the forwarding decision. These sources can show the protected network’s own adjacencies and route state before the information becomes visible at a public collector.

Local feeds improve timeliness and context, but they also introduce sensitive infrastructure into the platform. BMP data can be voluminous and may expose internal routing relationships. ExaBGP integration requires careful control because the same programmable interface can be used to announce routes as well as observe them. Credentials, network reachability, message validation and separation between monitoring and mitigation therefore become security boundaries.

A well-designed deployment uses public and private feeds for different purposes. Public collectors show how an announcement is spreading beyond the operator’s immediate neighbourhood. Local sources show what the operator and its routers saw directly. A disagreement between them is not necessarily an error; it may be the evidence needed to understand where propagation stopped or where a policy took effect.

The application separates observation, detection and evidence

The current platform is a multi-container microservice application rather than one script reading a stream. Monitoring services connect to public and private feeds, normalise incoming BGP information and publish events. Detection services consume those events and apply operator rules. Storage, APIs, the web interface, notifications and supervision sit around that core. The separation allows components to scale or fail independently and makes it easier to add a new feed without rewriting the whole application.

Modularity also multiplies dependencies. A monitor can be healthy while the detector is stalled. The message bus can accept events while the database is unavailable. The web interface can load an old incident while the live pipeline is broken. Container orchestration can restart a service and hide a recurring crash. Operations therefore require health checks that describe the complete path from source feed to alert, rather than reporting only that individual containers are running.

Docker Compose lowers the barrier for a controlled deployment, while Kubernetes support fits organisations that already operate container platforms. Neither method turns the system into a managed global service. The deploying network still owns capacity, upgrades, secrets, storage, backups and incident access.

A message bus lets monitoring, detection and notification services exchange events without one process directly controlling all others. That design can absorb bursts of updates and allow consumers to work at different rates. It also creates questions about ordering, duplication and back pressure. A routing incident can involve thousands of updates, withdrawals and path changes, so the system must preserve enough sequence and provenance for an operator to reconstruct what happened.

Persistent storage gives ARTEMIS an advantage over a transient alarm. Updates, alerts, configuration state and incident decisions can be retained for review. The project architecture has used PostgreSQL-related components, Timescale-style storage and the Hasura API ecosystem. These choices support querying and integration, but they also create a sensitive repository of routing and operational evidence that requires retention limits, access control and reliable backup.

Auditability is not the same as certainty. A complete record of what the system received can prove how ARTEMIS reached an alert. It cannot prove that the system received every relevant route or that the operator’s rules were correct. The database should therefore preserve source and confidence, rather than only a final incident label.

The web interface presents incidents, system state and routing observations in a form that a network or security operations team can use. Notifications can send alerts by email, mobile channel or custom integration, while Grafana dashboards can expose service health and event trends. These functions turn a research mechanism into an operational product because the response team needs prioritisation, history and a common view rather than raw BGP updates.

The interface can also create false confidence. A red incident card is a classification made from observations and rules, not an independent finding of malicious intent. A map or path view may appear complete even when it represents only selected collectors. Notifications can become noise when planned changes are not reflected in policy, and alert fatigue can cause the one important event to be ignored.

Good operating practice keeps the user interface connected to verification. The responder should be able to inspect the source updates, compare public and local feeds, check current RPKI state, run data-plane tests and record why the incident was escalated, ignored or resolved. The dashboard is useful when it shortens that path, not when it replaces it.

A route pattern cannot prove motive or impact

The ARTEMIS research developed a taxonomy that distinguishes events by prefix relationship, AS-path manipulation, policy and possible data-plane effect. The implementation supports a defined subset of those patterns from control-plane evidence, including exact-prefix and subprefix origin cases, squatting and selected export violations. A taxonomy gives operators consistent language and helps the detector apply different rules to different events.

The categories must remain tied to what the data shows. A path that begins with an unexpected neighbour may indicate a fabricated segment, a route leak or an authorised change not recorded in policy. An unauthorised origin can be a mistake rather than an attack. Even a deliberate announcement may be designed to blackhole traffic, impersonate a service or observe traffic in transit, and BGP updates alone cannot distinguish those outcomes.

Careful language protects both accuracy and response quality. “Suspected hijack” or “policy violation” is usually safer at the alert stage than “attack.” The stronger word can be used after route ownership, operator contacts and data-plane evidence support it. That restraint does not weaken security; it prevents the incident system from converting uncertainty into a claim that other teams may repeat as fact.

BGP messages describe reachability claims and path information exchanged between networks. They do not show every packet that follows the selected route. After a suspicious announcement, traffic might be blackholed, intercepted and forwarded, answered by an impersonating service or unaffected because the route did not propagate to the networks carrying the relevant users. Different parts of the internet can experience different outcomes at the same time.

This boundary is central to ARTEMIS. The detector can show that a route violated the operator’s policy and appeared at identified observation points. It cannot infer motive from the AS path, and it cannot guarantee that a traceroute follows the same direction as application traffic. Encryption, DNS behaviour, caching, anycast and application failover can further change what users experience. The control-plane alert is therefore evidence for an incident, not the whole incident.

A useful response joins several records. BGP evidence establishes the announcement and its propagation. Data-plane tests examine reachability and paths from selected locations. Service telemetry shows errors, latency and customer impact. Upstream contacts establish whether the route was authorised or mistaken. None of these records is perfect, but together they support a decision that one feed cannot.

The 2019 RIPE Community Projects Fund award supported an ARTEMIS extension using RIPE Atlas traceroute measurements to examine the effect of detected events. This work recognised a limitation in the original control-plane loop. A route can look dangerous in BGP and have little observable impact, while a small propagation footprint can still affect a valuable customer population. Data-plane probes add evidence about where traffic appears to go and whether endpoints remain reachable.

RIPE Atlas has a distributed probe network, but probe placement is uneven, and the chosen target may not respond in a way that reveals the path. Traceroute can be affected by filtering, load balancing, tunnels and asymmetric routing. The forward path from a probe to the destination need not match the path taken by customer traffic in the opposite direction. A failed measurement can mean an outage, an unresponsive hop or a test-specific limitation.

The practical gain is not certainty but better triage. If BGP collectors show an unauthorised subprefix and probes in several regions lose reachability or change towards the unexpected origin, the operator has stronger evidence to escalate. If the control-plane event is visible only at one collector and data-plane tests remain stable, the team may investigate before changing global announcements. The decision remains contextual, but it is less blind.

Deaggregation can recover traffic only when the routing system permits it

The best-known ARTEMIS response is deaggregation. A victim announcing a broad prefix can originate more-specific routes so that normal longest-prefix selection draws traffic back towards the legitimate network. The method uses existing BGP behaviour and can propagate quickly, which made it suitable for the project’s experimental “within a minute” objective. It also keeps authority with the victim rather than requiring the unexpected origin to cooperate before service can begin to recover.

Deaggregation has strict limits. Many networks filter IPv4 routes longer than /24 and IPv6 routes longer than /48 to contain table growth and operational abuse. A victim already announcing a /24 or /48 may be unable to produce a more-specific route that the wider internet will accept. Upstreams may also restrict what a customer may announce, and route objects, prefix filters or RPKI data may need to permit the mitigation. Propagation is not instantaneous or uniform, so the old and new paths can coexist.

A prepared operator should know these boundaries before the incident. Which prefixes can be deaggregated? Which upstreams will accept them? Which route filters and Route Origin Authorisations already cover the emergency state? How will the routes be withdrawn after recovery? ARTEMIS can invoke a wrapper, but the success of that wrapper depends on arrangements that exist outside the application.

Project material uses the language of automatic mitigation, and the research includes a closed loop in which detection can trigger a counter-announcement. Detailed operational descriptions also show manual confirmation and custom wrappers. Both can be accurate because deployments choose different autonomy levels. The safe formulation is that ARTEMIS supports automated or operator-authorised mitigation through configurable workflows.

The risk is asymmetric. A delayed response can prolong an outage or interception. A wrong automatic response can announce unnecessary more-specific routes, violate an upstream policy, leak internal assumptions or create instability while the original event is still being investigated. A stale ground-truth rule can turn a planned route change into an apparent emergency. If the wrapper has broad router credentials, a compromise of ARTEMIS can become a routing attack in its own right.

Safer automation is staged. The system can first enrich the alert, check several feeds, verify RPKI status, run data-plane tests and prepare the exact route change. A human can approve high-impact action, while lower-risk cases may use policy-based automation. Rate limits, scoped credentials, simulation, change records and a tested rollback path matter more than the label “automatic.” The point is not to preserve manual work for its own sake; it is to ensure that speed does not remove accountability.

RPKI strengthens one part of the evidence chain

The Resource Public Key Infrastructure allows address holders to create Route Origin Authorisations stating which autonomous systems may originate specified prefixes and maximum lengths. Routers or policy systems can perform Route Origin Validation and classify a route as valid, invalid or not found. This adds cryptographic evidence to a part of BGP that otherwise depends on distributed trust. It is a proactive control because other networks can reject or deprefer an unauthorised origin before traffic follows it.

ARTEMIS operates at a different layer of the incident. It can use RPKI validation state as evidence, but it also compares routes with private operator rules, records the event, combines public and local feeds and connects detection to response. RPKI does not validate the entire AS path, and deployment policy is not universal. A route can be RPKI-valid and still violate an expected neighbour relationship or leak through a path the operator did not intend. A route can be invalid because a legitimate operational change was not reflected in the ROA.

The systems are therefore complementary. RPKI can reduce the number of unauthorised origin routes accepted by the wider internet. ARTEMIS can show the victim what is being observed, catch selected patterns beyond simple origin validity and organise the response. Future path-authorisation mechanisms such as ASPA may strengthen evidence about relationships, but they will not remove the need to monitor what networks actually announce and how incidents affect services.

Pilots moved ARTEMIS beyond the laboratory without proving market scale

CAIDA reported an NSF-supported experimental deployment of ARTEMIS with Internet2, Great Plains Network and Merit during 2018–2019. These pilots mattered because research and education networks have real prefixes, upstreams, change processes and service obligations. Operators could test whether the software fitted existing monitoring, whether the rules captured their routing intent and how alerts would enter incident response.

The record is credible but bounded. A pilot can establish installation, engineering feedback and selected operational use. It does not prove continuous production coverage, current version status or performance across every network type. The project website also publishes statements from engineers associated with AMS-IX, Internet2 and ESnet and shows organisational logos. Those references indicate testing or use, but they should not be converted into a claim that every named organisation is a current paying customer or that the project has a known global share.

This distinction matters because routing-security software often has invisible deployments. An operator may run an internal fork, use monitoring without mitigation or stop after a trial. The absence of a complete census does not make the project irrelevant, but it prevents a precise statement about adoption. Named cases are stronger evidence than a large unsupported number.

Operator control brings an integration and software-supply-chain burden

ARTEMIS is distributed under the BSD 3-Clause licence. An operator can inspect the code, run it in controlled infrastructure, adapt integrations and avoid sending sensitive policy to one mandatory central provider. This model fits the project’s core advantage because the most valuable ground truth belongs inside the network. It also permits commercial use and forks, allowing Code BGP and other parties to build services around the open foundation.

Control brings work. The platform includes containers, a message bus, databases, APIs, a web application, notification systems and feed integrations. Each component needs patching, credentials, network segmentation, backups and monitoring. The system stores sensitive routing policy and may hold credentials capable of influencing announcements. A production deployment therefore has a security surface far larger than the original detection algorithm.

The open licence gives an operator an exit path from one maintainer, not an automatic support organisation. Someone still has to test upgrades, review dependencies and understand the code when a feed or router interface changes. For smaller networks, a simpler alerting tool or a managed commercial service may be easier to operate even if it offers less local control.

A production ARTEMIS service has to remain available during the same network instability that causes operators to need it. The feed connections, message bus, database, API, interface, notification channel and authentication layer form one service chain. Redundancy at the container level helps only when state, storage and external dependencies are also designed for failure. A restarted monitor cannot recover updates that were never retained, and a replicated interface cannot display an incident that the detection pipeline failed to process.

Operational design should therefore include explicit degraded modes. When one public feed disappears, the system should state that coverage has narrowed rather than continuing to display an undifferentiated healthy status. When the database is unavailable, the detector may need to preserve events locally or stop mitigation because audit evidence cannot be written. When the identity provider fails, emergency access should be possible without leaving a permanent uncontrolled account. These choices are not described by the hijack taxonomy, but they determine whether the research idea becomes dependable infrastructure.

The platform also needs its own performance budget. A burst of legitimate updates during a large routing change can place more stress on monitors and storage than a single hijack. Queues inside the application should not turn a near-real-time feed into a delayed incident without making the delay visible. Capacity tests, database retention and message-bus back pressure belong in deployment planning for the same reason that route filters and prefix lengths do: they bound the response the system can honestly promise.

ARTEMIS brings together web software, container images, a database, messaging components, APIs, authentication and networking libraries. That architecture makes the project extensible, but every dependency is a possible vulnerability or failure point. A flaw in a user interface can expose routing policy. A compromised image can alter alerts. A permissive API token can disclose incidents, while a credential attached to a mitigation wrapper can allow route changes. The security of the detector is therefore inseparable from the security of the software used to operate it.

Open source helps because operators can inspect components, pin versions and build images themselves. It does not guarantee that someone has reviewed every transitive dependency or that a public vulnerability will be fixed on the schedule a network requires. A production team needs an inventory of images and libraries, a process for rebuilding them, separation between read-only monitoring and write-capable mitigation, and a way to test security updates without losing the incident history.

This requirement changes how the project’s maintenance should be judged. A new detection feature may attract more attention than a database upgrade or an authentication fix, yet the latter can be more important to the integrity of the service. Security advisories, reproducible builds, dependency updates and a supported release branch are evidence of operational maturity even when they add no visible option to the dashboard.

Releases and Code BGP define the current maintenance test

The latest formal tagged release identified in the research pack is version 2.3.0, named Cadmus, dated 24 November 2022. The live demo at the 5 August 2026 cutoff displayed a later commit-based build, and the current project website remained active. These facts support the conclusion that work continued after the last formal release, but they also create a legitimate production question: which version is tested, supported and suitable for upgrade?

Commit activity and a working demonstration show development. A semantic release provides a different form of assurance: a named baseline, release notes, dependency expectations and a point against which operators can test. A project can be active while its formal release process lags, and a current demo can run code that no production operator should adopt without review.

For routing-security infrastructure, release discipline is part of the security model. Operators need to know which branches receive fixes, how migrations are handled and whether older dependencies remain exposed. A new tag would not prove universal reliability, but a published support and security policy would reduce uncertainty more than a current website alone.

The project website identifies Code BGP as ARTEMIS’s current maintainer and describes the company as a startup spun out of the project. Commercialisation can solve a real open-source problem. Routing-security software needs people who can maintain integrations, respond to vulnerabilities, support deployments and turn research features into reliable operations after the original grants end.

Code BGP is nevertheless a separate commercial company with a wider product and customer context. It should not be used as an alias for FORTH, CAIDA or every open-source deployment. Public evidence in the pack does not disclose the company’s revenue, valuation, customer list or the exact boundary between community features and commercial capabilities. That absence is not a criticism; it is a limit on what a profile can claim.

The relationship creates two incentives that may align or diverge. The open project benefits when commercial staff contribute tested code and documentation. The company benefits when the open project builds trust, adoption and a technical base for paid services. The long-term test is whether releases, security fixes and roadmap decisions remain visible enough for operators who are not commercial customers.

A permissive licence ensures that the source can be copied, modified and commercialised. It does not ensure that another team can understand the architecture, reproduce a release or assume maintenance when the current experts move on. The project’s long-term continuity depends on documentation, tests, issue history, dependency knowledge and a contributor path that extends beyond the people who built the original research system.

Code BGP’s stewardship may strengthen that continuity by keeping experienced engineers attached to the platform. It may also concentrate practical knowledge inside a commercial organisation even while the repository remains public. The distinction can be observed through release notes, public design discussion, responsiveness to community reports and whether non-customer deployments can obtain enough information to operate securely.

The goal is not to prevent commercial value. A healthy open-core relationship can align paid support with public maintenance. The risk appears when the open project becomes a historical demonstration while the operational path moves into undocumented private components. Portability should therefore be tested in practice: can an independent operator install, upgrade, audit and recover the system using the public record available at the time?

ARTEMIS occupies a demanding middle ground in routing security

The routing-security field includes public collectors, research inference systems, open-source alerting tools, RPKI validators and commercial monitoring platforms. RIPE RIS, RouteViews and BGPStream provide data rather than an operator-specific incident workflow. BGPalerter offers another open-source monitoring model. MANRS sets operational norms but does not detect live events. Commercial services can provide broad monitoring and analyst support, while they may lack private local context unless the customer integrates it.

ARTEMIS’s distinctive position is the combination of operator control, explicit ground truth, several public and local feeds, open code and optional mitigation. That position is also demanding. A network must have routing expertise, maintain policy and operate a multi-service platform. The project may therefore be most suitable for organisations that consider routing security a core capability rather than a dashboard subscription.

The comparison should not be reduced to a feature table. Different models place trust and labour in different places. A managed service centralises expertise and observation. An operator-run system keeps policy and action closer to the network. The relevant question is which party can see enough, act safely and remain accountable when the evidence is incomplete.

ARTEMIS Lite appeared in RIPE community material in 2023 as a related, lighter approach intended to reduce some of the deployment burden. The existence of a Lite variant is evidence that the full platform’s breadth can be difficult for smaller teams. A multi-container stack with persistent storage, several feeds and custom mitigation may be appropriate for a large operator and excessive for a network that first needs clear visibility and reliable alerting.

A lighter system should not be described as equivalent merely because it shares the name and purpose. The research pack characterises ARTEMIS Lite as having reduced functionality, and presentation claims need independent confirmation. The relevant trade-off is between lower operating cost and the context, integrations, history or response mechanisms that may be absent. A smaller deployment can still be valuable if it defines those boundaries honestly.

Adoption depends on the amount of institutional machinery the tool requires. A project can be technically open and remain inaccessible to operators without container, database and routing-security specialists. Packaging, sensible defaults and a staged path from monitoring to detection and mitigation may determine whether the architecture spreads more widely than another research paper.

The real product is a governed feedback loop

ARTEMIS does not make BGP trustworthy in one step. It creates a loop around a protocol that was built without complete authorisation. The operator states intended routing. Public and local feeds show part of the observed routing. The detector identifies divergence. Storage and interfaces organise the evidence. People or approved automation choose a response, and the feeds then show whether propagation changes. The incident can be resolved, ignored, withdrawn, escalated or left dormant with a recorded reason.

That loop is the project’s most durable contribution. It recognises that routing security is neither a one-time certificate nor a distant alarm. It is an operating practice in which policy must be explicit, observations must retain provenance and response authority must be prepared before an emergency. The system’s value lies in narrowing uncertainty quickly enough for the network to act, not in pretending that uncertainty has disappeared.

The limits are equally instructive. The route collectors are partial. Ground truth can be stale. Control-plane evidence cannot prove motive or every traffic outcome. A technically valid mitigation can be filtered or harmful. Open-source code still needs sustained maintenance. ARTEMIS is strongest when those limits are built into the workflow rather than hidden behind the headline of a one-minute response.

A BGP anomaly can arrive at a network operations centre, a security operations centre or both. The routing team understands prefixes, upstream policy and the risks of changing announcements. The security team may be better prepared to correlate identity, service telemetry and possible malicious activity. ARTEMIS crosses those domains, which is useful only if the alert carries enough evidence for each team to work from the same event rather than opening separate investigations with different assumptions.

The handoff should distinguish observation, policy and impact. The system observed a route at named feeds. The route violated a specific ground-truth rule. Service checks or RIPE Atlas probes showed a defined effect, or no effect has yet been established. The operator contacted an upstream or route origin, and the response remains pending. This structure prevents the NOC from dismissing a security concern as ordinary routing and prevents the SOC from calling an unauthorised announcement an attack before the operational facts are known.

Shared language also improves post-incident learning. A case can be closed as a planned change omitted from policy, an accidental route leak, a suspected hijack, a confirmed malicious event or an unresolved anomaly. Those outcomes should feed back into rules, runbooks and upstream arrangements. Without that loop, the detector can become a machine for producing tickets rather than a system for improving routing control.

The fastest alert is not always the most useful one. A detector can fire on the first unexpected update and leave the responder to discover that the feed is stale, the route was planned or the alleged victim authorised a new origin. Conversely, waiting for every collector and every data-plane test can sacrifice the advantage of early response. ARTEMIS needs a measure that sits between raw detection latency and final incident closure: the time required to assemble enough trustworthy evidence for the authorised operator to make a defensible decision.

That measure can be decomposed. How quickly did the first observation arrive? How many independent feeds confirmed it? Was the relevant policy current? Did RPKI or local BMP add evidence? How long did service checks take? When did the responsible person receive the alert, and when was a response approved? Did the mitigation achieve the intended propagation, and was it withdrawn cleanly? These questions expose where delay actually lives instead of assigning the whole result to the detection algorithm.

A credible-decision metric also discourages dangerous optimisation. The system should not be rewarded for acting faster when it acts on less evidence or creates unnecessary routing change. The best deployment is one that reduces uncertainty and response time together, while preserving a record that can be reviewed after the incident.