In brief

  • ARTEMIS is an open-source system deployed by the operator itself. It compares current BGP observations with locally defined routing intent, adding context that public collectors alone cannot provide.
  • A 2018 study by FORTH and CAIDA reported detection within seconds and mitigation in under a minute under the tested conditions; this is not a universal guarantee for production networks.
  • For mitigation, ARTEMIS can announce more-specific routes or invoke custom procedures. However, filters, outdated policy, incomplete visibility and excessive privileges can turn a rapid response into a second incident.
  • The project’s viability now depends on release discipline, credible deployment evidence and a transparent boundary with Code BGP. Commercial maintenance can support the open code without replacing the research project’s history.

A real route change showed why seconds are only the beginning

CAIDA’s 2019 annual report says that ARTEMIS detected, within seconds, a real route hijack affecting an Internet2 /30 prefix. The case matters because it extends the evidence beyond synthetic announcements prepared by the researchers. A route genuinely changed in a participating network, and the system identified the deviation quickly enough to support investigation.

The report does not establish a universal distribution of detection times. The /30 was a particular prefix in a particular routing context, observed through sources available to that deployment. Another incident might propagate differently, last for less time or never reach the connected collectors. The report alone neither proves malicious intent nor describes every data-plane consequence. The defensible conclusion is narrower: within CAIDA’s deployment programme, ARTEMIS detected one recorded real-world incident within seconds.

Operational cases are most useful when their boundaries remain clear. They show how the programme behaves during a real change, how an operator receives an alert and what evidence remains afterwards. More incident records—including false positives, missed events and mitigation outcomes—would say more about production maturity than another striking timing result.

A BGP alert can arrive within seconds while leaving the most important questions unanswered. A route collector may show that an unfamiliar autonomous system originated a prefix, or that a more-specific route appeared and began to spread. This tells the operator that the control plane no longer matches the expected state. It does not establish who made the change, whether it was erroneous, whether traffic followed the new route, whether users were affected or which action can restore service without creating another problem.

ARTEMIS was designed for this interval between detection and action. Its name expands to Automatic and Real-Time dEtection and MItigation System, but the unusual capitalisation should not obscure the operating model. It is not a central service that sees the entire internet and repairs other organisations’ networks remotely. 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 observed data diverges from policy.

The promise is context-aware speed; the constraint is that both context and authority remain local.

ARTEMIS is therefore closer to an instrument in the operator’s own control room than to “internet police”. It can organise evidence, reduce time spent searching route updates and prepare a response agreed in advance. It cannot remove the need for operator judgement. A decision may affect global routing, upstream relationships and customer traffic, so its quality depends on people, configuration and rehearsed authority as much as on the detector.

BGP distributes reachability before it can prove authority

Border Gateway Protocol lets independently managed networks exchange reachability information and apply their own policies. An autonomous system announces that it can deliver traffic to particular IP prefixes; neighbouring networks decide whether to accept, prefer and propagate those routes. This model allowed the internet to scale across organisations without one controller, but the original protocol attaches no cryptographic proof to every claim about origin or path. A mistaken export, stale configuration or intentional announcement can therefore introduce a route that should not exist.

Route selection can make a bad announcement attractive. Where two routes cover prefixes of equal length, networks apply their policies and path-selection rules. If an attacker or mistaken network announces a more-specific subprefix, normal longest-prefix matching generally sends traffic towards the narrower route wherever it is accepted. This is not a special attack function but the standard rule for selecting the most precise destination. A seemingly small announcement can therefore redirect traffic rapidly even while the legitimate aggregate remains visible.

“Hijack” is useful shorthand, but it can imply intent that routing messages do not reveal. An unauthorised origin may be malicious, accidental or associated with a legitimate commercial change missing from monitoring policy. A fabricated path may be used to intercept traffic, but a control-plane update alone does not prove interception. ARTEMIS is most useful when it treats an alert as a mismatch between observed and intended routing, leaving attribution and impact assessment to the wider response process.

An exact-prefix event competes with a legitimate route of the same length. Its spread depends on policy and path selection in networks receiving both announcements. Some parts of the internet may prefer the unexpected route while others continue using the lawful origin. The result may be partial reachability, regional differences and a confusing mixture of success and failure rather than one clean outage. Detection must therefore consider not only whether a route exists, but where and how it propagates.

A subprefix event usually attracts traffic more strongly because longest-prefix matching favours the narrower route. If a network normally announces a /20 and another origin announces a /24 within it, routers accepting the /24 will generally send relevant traffic to that subprefix. Deaggregation is also a common defence: the legitimate operator announces equally or more-specific routes to regain preference. The method has a hard limit, however. Many networks filter IPv4 routes longer than /24 and IPv6 routes longer than /48. An operator already announcing prefixes of those lengths may have no narrower route that is widely accepted.

ARTEMIS also considers squatting and selected policy violations, including the no-export scenario described in project material. These categories matter because a routing incident is not always an outside network announcing the victim’s prefix. A route may have an authorised origin yet escape through an unexpected relationship. Monitoring therefore needs enough policy context to distinguish such cases without pretending that BGP data reveals every private agreement between networks.

ARTEMIS puts the operator’s routing intent inside the detector

External monitoring services have an obvious advantage: they collect data from many parts of the internet without requiring every network to deploy a complete platform. The disadvantage is equally clear. A third party may see announced prefixes and paths but not know which origin changes, backup upstreams, traffic-engineering arrangements or emergency announcements the operator permits. General rules may therefore miss a subtle policy violation or raise an alarm over a planned change.

ARTEMIS changes the observation point. The organisation whose address space is at risk runs the detector and defines the reference state. Public collectors still provide a broad external view, but their observations are interpreted using private knowledge of protected prefixes, authorised origin ASes, acceptable neighbours and selected path relationships. Local router feeds add events that public collectors cannot see. This is the project’s defining idea: incomplete global data becomes more useful when compared with explicit local intent.

Placing the detector inside the protected network also places responsibility there. The organisation operating ARTEMIS must decide who owns the policy file, how changes are reviewed, which alerts reach the network operations centre, what conclusions the security team may draw and who can authorise a new route. The software makes this responsibility visible; it cannot make an institution exercise it well.

ARTEMIS asks the operator to define protected prefixes, legitimate origin autonomous systems, acceptable neighbour relationships and selected routing rules. This reference lets the detector ask a more precise question than a general external service. Instead of deciding whether a route looks unusual against global history, it tests whether the route violates the stated intent of a particular network.

The advantage is only as reliable as the statement of intent. Networks change upstreams, add anycast sites, move origin ASes, create temporary backup paths and issue emergency announcements during outages. A policy accurate in January may be stale by June. If a change reaches routers but not ARTEMIS, the detector may produce a high-severity false positive. If rules are broadened too far to suppress noise, a genuine violation may become “permitted” on paper.

The system therefore turns technical configuration into an institutional agreement. Routing engineers, security staff and change-management teams must agree what the file means, who may edit it and how closely it follows the production network. Local context does not eliminate false positives or false negatives; it moves their main source to a place where the operator can manage them.

A routing-security rule deserves the same discipline as software code capable of affecting customer traffic. Changes need 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. An ordinary configuration file can support this process only if the organisation does not treat it as a disposable installation artefact.

Testing should cover both positive and negative scenarios. A planned legitimate route must pass without an alarm. An exact-prefix announcement from an unauthorised origin should receive the expected classification. A subprefix event should trigger the correct severity, while a no-export violation should not be mistaken for origin hijacking. Historical replay can test these cases, and a test environment can confirm that notifications and mitigation procedures receive the expected data.

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

FORTH and CAIDA turned a research question into an operator workflow

The project emerged from 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-engineering expertise. CAIDA added internet-measurement infrastructure, BGPStream experience and relationships that helped move the work into research and education networks. ARTEMIS was therefore more than a detection algorithm from the outset: it joined protocol knowledge, measurement systems and access to operators.

Funding followed the same mixed institutional model. The project history includes European and US research programmes, the RIPE NCC Community Projects Fund, an NSF EAGER deployment project, the US Department of Homeland Security and the Comcast Innovation Fund. RIPE support in 2017 helped turn a prototype into an operator tool, while a €50,000 grant in 2019 funded data-plane validation using RIPE Atlas. This funding shows how public-interest research became deployable software, but it does not reveal the current cost of supporting production installations.

The institutional history matters for accurate attribution. ARTEMIS is not a separately incorporated foundation, a CAIDA service or a global detector owned by FORTH. It is open-source software under the BSD 3-Clause licence, with a research lineage and a present commercial maintainer. Its development is better described as a sequence of collaborations than as the property of one organisation.

The first public milestone was a demonstration at ACM SIGCOMM in 2016. Its main step was to connect monitoring and mitigation in one loop. Many systems can identify a suspicious route after data accumulates. ARTEMIS asked a different question: can an operator see an event quickly enough, with a practical countermeasure already prepared, so that the incident does not spend hours moving between dashboards, emails and manual router sessions?

A demonstration is not a mature production deployment. It shows that components can work together in a defined configuration and that a research problem is concrete enough for public testing. The 2016 work nevertheless set the direction for what followed: live observations, an internal model of lawful routing, classification and a prepared announcement. This sequence made response time a system property rather than an organisational afterthought.

The project was influenced by operator reports that responding to a route hijack could take hours. Delay did not arise only from slow collectors. Teams had to confirm prefix ownership, study propagation, determine whether the change was planned, find the correct upstream contacts and prepare a safe counter-announcement. ARTEMIS reduces several of these steps by keeping policy and procedures beside monitoring, but the human and commercial relationships surrounding a route remain outside the code.

The 2018 paper in IEEE/ACM Transactions on Networking gave ARTEMIS its most memorable claim: neutralising BGP hijacking within a minute. The researchers tested the approach in real experiments and reported detection within seconds and mitigation before a minute had elapsed under the tested conditions. The result mattered because it showed that the victim network did not necessarily have to wait for an external service, a chain of telephone calls and a manually assembled counter-announcement.

The phrase becomes misleading when separated from the experiment. Detection time depends on whether the event reaches a connected observer, how quickly the source delivers the update, whether detector rules match and whether the system itself is healthy. Mitigation time depends on the victim’s prefix length, routing authority, upstream filters, propagation and approval procedure. A network requiring human confirmation may make a safer decision and take longer. A network using immediate automation may respond faster while accepting additional risk.

The responsible conclusion must remain limited. ARTEMIS demonstrated that a tightly integrated operator-side system can compress a process that previously often took much longer. It did not prove that every hijack is visible, every counter-route is accepted or every production team should permit autonomous deaggregation. The result is an experimentally supported design goal, not a universal guarantee.

Several incomplete views can form a usable incident picture

ARTEMIS can use several public sources because no 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 common mechanism for accessing and normalising routing data from multiple sources. Each service broadens the operator’s view while reflecting only the networks connected to its collectors, the geography of those sessions and the timing characteristics of its feeds.

Partial visibility has practical consequences. An event may spread in one region without reaching any collector connected to a deployment. A very short announcement may be withdrawn before a feed delivers it. A route may affect the victim’s customers through a private relationship absent from open data. Combining collectors reduces some blind spots but produces a larger sample, not an omniscient copy of the global control plane.

The correct operational question is therefore not “did ARTEMIS see the internet?” but “which observers saw this announcement, how quickly, and what part of the event may have remained outside the sample?” This framing encourages operators to retain the provenance of each alert and not treat absence from one feed as proof that a route did not exist.

RIPE NCC presented a public prototype of RIS Live in February 2019 to deliver BGP messages with far less delay than periodic archive processing. ARTEMIS became one example of why such a feed matters. A security system cannot respond within seconds if its primary observation arrives many minutes later, whereas a real-time feed lets the detector assess updates as collectors receive them.

Lower latency does not remove observational limits. RIS Live still reflects 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 by another relationship, decisive evidence may never appear in the feed. Reliability also matters: an outage or format change can look like silence unless monitoring distinguishes “no suspicious routes” from “no data”.

Source health is therefore part of the security model. The operator needs to know whether each monitor is current, delayed, disconnected or producing an unusual volume of updates. A detector confidently reporting normality while its inputs are degraded can create more dangerous ignorance than an explicit failure.

Real-time monitoring answers what is appearing now; routing information bases and update archives provide context. RIPE RIS and RouteViews publish history showing origins and paths before an incident, the start of a change and its duration. CAIDA BGPStream simplifies processing through a common mechanism, allowing ARTEMIS to replay events and test rules against past routing behaviour.

Replay supports engineering validation and analysis. A team can determine whether a new rule would have caught a known event, reconstruct the sequence leading to an alert or train responders without changing a live production route. History can also reveal repeated announcements that appear anomalous individually but belong to an established backup arrangement. The limitation remains: an archive records the collectors’ view, not the whole event, and past topology does not reproduce every present relationship.

A mature deployment can include replay in change management. Before a new origin, upstream or export rule enters production, the operator tests the updated reference state against representative history and confirms that normal routing will not become a permanent alarm. Detector configuration then becomes a testable security artefact rather than a file edited only after noise appears.

Public data is only one side of the architecture. ARTEMIS can receive local updates through ExaBGP or private BGP Monitoring Protocol sessions. ExaBGP acts as a programmable BGP speaker and passes events to other applications. BMP allows routers to export routing information to monitoring without placing that system in the packet-forwarding decision. These sources show the protected network’s own adjacencies and route state before information reaches a public collector.

Local feeds improve timeliness and context but introduce sensitive infrastructure into the platform. BMP data can be voluminous and expose internal routing relationships. ExaBGP integration needs strict controls because the same programmable interface can observe and announce routes. Credentials, network access, message validation and separation between monitoring and mitigation become security boundaries.

A well-designed deployment uses public and private feeds for different purposes. Public collectors show propagation beyond the operator’s immediate environment. Local sources show what the network and its routers observed. Disagreement is not necessarily an error; it may show where propagation stopped or where policy took effect.

The application separates observation, detection and evidence

The modern platform is a multi-container microservice application, not a single script reading a feed. Monitoring services connect to public and private sources, normalise incoming BGP information and publish events. Detection services consume those events and apply operator rules. Storage, an API, a web interface, notifications and supervision surround the core. This separation lets components scale or fail independently and makes it easier to add a source without rewriting the entire system.

Modularity also multiplies dependencies. A monitor may be healthy while the detector is stopped. The message bus may accept events while the database is unavailable. The web interface may display an old incident while live processing is broken. An orchestrator may restart a container and conceal recurring failure. Operational checks must therefore cover the complete path from source to alert, not merely report that individual containers are running.

Docker Compose lowers the threshold for controlled deployment, while Kubernetes support suits organisations already operating container platforms. Neither option turns the system into a globally managed service. The deploying network remains responsible for capacity, updates, secrets, storage, backups and emergency access.

The message bus lets monitoring, detection and notification services exchange events without placing every process under one controller. It can absorb update bursts and allow consumers to operate at different speeds. It also raises questions about ordering, duplicates and backpressure. A routing incident may generate thousands of updates, withdrawals and path changes, so the system must preserve enough sequence and provenance for the operator to reconstruct events.

Persistent storage gives ARTEMIS an advantage over a one-off alarm. Updates, alerts, configuration state and incident decisions can be retained for later analysis. The architecture has used PostgreSQL components, Timescale-style storage and the Hasura API ecosystem. These support queries and integration but also create a sensitive archive of routing and operational evidence requiring retention rules, access controls and reliable backups.

Auditability is not certainty. A complete record of received data can show how ARTEMIS reached an alert. It cannot prove that the system saw every material route or that the operator’s rules were correct. Storage should therefore retain source and confidence information, not only the final incident label.

The web interface presents incidents, system status and routing observations in a form usable by a network or security operations centre. Notifications send alerts by email, mobile channel or custom integration, while Grafana dashboards show service health and event trends. These functions turn a research mechanism into an operational product: responders need priorities, history and a common view rather than raw BGP updates.

The interface can also create false confidence. A red incident card is a classification based on observations and rules, not independent proof of malicious intent. A map or path image may appear complete while representing only selected collectors. If planned changes are absent from policy, notifications become noise and alert fatigue increases the chance of missing a genuinely important event.

Good practice connects the interface to verification. A responder should be able to inspect original updates, compare public and local feeds, check current RPKI state, run data-plane tests and record why an incident was escalated, ignored or closed. A dashboard is useful when it shortens this route rather than replacing it.

A routing pattern proves neither motive nor consequences

ARTEMIS research developed a classification distinguishing events by prefix relationship, AS-path manipulation, policy and possible data-plane effect. The implementation supports a defined subset of these patterns using control-plane evidence: exact-prefix and subprefix cases with an incorrect origin, squatting and selected export violations. Classification gives operators a common language and allows different rules for different events.

Categories must remain tied to what the data actually shows. A path beginning with an unexpected neighbour may indicate a fabricated segment, a route leak or an authorised change missing from policy. An unauthorised origin may be an error rather than an attack. Even an intentional announcement may aim to blackhole traffic, impersonate a service or observe transit, and BGP updates alone cannot distinguish these outcomes.

Cautious terminology protects accuracy and response quality. At the alert stage, “suspected hijack” or “policy violation” is generally safer than “attack”. Stronger language should follow checks of routing authority, operator contacts and data-plane evidence. This restraint does not weaken defence; it prevents a classifier from converting uncertainty into a claim that other teams repeat as fact.

BGP messages describe reachability and path claims exchanged by networks. They do not show every packet that followed a selected route. After a suspicious announcement, traffic may be blackholed, intercepted and forwarded, answered by an impersonating service or unaffected because the route did not spread to relevant user networks. Different parts of the internet may experience different effects simultaneously.

This boundary is central to ARTEMIS. The detector can show that a route violated operator policy and appeared at particular observation points. It does not infer motive from an AS path or guarantee that traceroute follows the same direction as application traffic. Encryption, DNS behaviour, caching, anycast and application failover further alter user experience. A control-plane alert is evidence of an incident, not the entire incident.

A useful response combines several records. BGP data establishes the announcement and its propagation. Data-plane tests examine reachability and paths from selected locations. Service telemetry shows errors, latency and customer impact. Contact with upstream networks establishes whether the announcement was authorised or mistaken. No source is perfect, but together they support a decision that one feed cannot provide.

A 2019 RIPE Community Projects Fund grant supported extending ARTEMIS with RIPE Atlas traceroute measurements to assess the effect of detected events. The work recognised a limitation of the original control-plane loop. A route may look dangerous in BGP while barely affecting users, whereas a small propagation area may affect a valuable customer group. Data-plane probes add evidence about likely traffic paths and endpoint reachability.

RIPE Atlas has a distributed probe network, but placement is uneven and a selected target may respond without revealing the path. Traceroute is affected by filtering, load balancing, tunnels and asymmetric routing. The forward path from a probe to a target need not match the return path of customer traffic. A failed measurement may mean an outage, a non-responsive node or a limitation of the test.

The practical gain is better triage rather than certainty. If BGP collectors show an unauthorised subprefix and probes in several regions lose reachability or shift towards an unexpected origin, there is a stronger basis for escalation. If a control-plane event appears at one collector while tests remain stable, the team may investigate further before changing global announcements. The decision still depends on context, but it is made less blindly.

Deaggregation restores traffic only when routing permits it

ARTEMIS’s best-known response is deaggregation. A victim announcing a broad prefix can begin announcing more-specific routes so that normal longest-prefix selection draws traffic back to the legitimate network. The method uses standard BGP behaviour and can propagate quickly, making it suitable for the experimental “within a minute” objective. It also leaves action with the victim, without requiring cooperation from the unexpected origin before recovery begins.

Deaggregation has hard limits. Many networks filter IPv4 routes longer than /24 and IPv6 routes longer than /48 to constrain table growth and abuse. A victim already announcing a /24 or /48 may be unable to issue a more-specific route accepted across the wider internet. Upstream networks also restrict customer announcements, while route objects, prefix filters and RPKI data must permit the emergency state. Propagation is neither instantaneous nor uniform, so old and new paths may coexist.

A prepared operator knows these limits beforehand. 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 an external procedure, but its success depends on arrangements beyond the application.

Project material refers to automatic mitigation, and the research includes a closed loop in which detection triggers a counter-announcement. Detailed operational descriptions also show manual confirmation and user-defined procedures. Both statements can be true because deployments choose different levels of autonomy. The safe formulation is that ARTEMIS supports automated or operator-approved mitigation through configurable workflows.

The risk is asymmetric. Delay may prolong an outage or interception. An incorrect automatic response may announce unnecessary more-specific routes, violate upstream policy, expose internal assumptions or create instability while the original event is still under investigation. A stale reference state may turn a planned change into a false emergency. If an external procedure has broad router privileges, compromise of ARTEMIS itself becomes a routing attack.

Safer automation proceeds in stages. The system first enriches an alert, checks several feeds, RPKI state and the data plane, then prepares a precise route change. A person approves high-impact actions, while lower-risk cases may proceed automatically under policy. Rate limits, narrow privileges, simulation, change records and tested rollback matter more than the label “automatic”. The goal is not to preserve manual work for its own sake, but to prevent speed from destroying accountability.

RPKI strengthens only one link in the evidence chain

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

ARTEMIS operates at another layer of the incident. It can use RPKI validation state as evidence, while also comparing routes with private operator rules, recording events, combining public and local feeds and connecting detection to response. RPKI does not validate the entire AS path, and deployment policy is not universal. A route may be RPKI-valid yet violate an expected neighbour relationship or leak along an unwanted path. Conversely, a legitimate change may be invalid if its ROA was not updated.

The mechanisms therefore complement one another. RPKI reduces the number of unauthorised origins accepted across the wider internet. ARTEMIS shows the victim what was actually observed, catches selected patterns beyond simple origin validity and organises response. Future path-authorisation mechanisms such as ASPA may strengthen relationship evidence, but they will not remove the need to observe what networks actually announce or how events affect services.

Pilots moved ARTEMIS beyond the laboratory but did not prove market scale

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

The evidence is credible but limited. A pilot confirms installation, engineering feedback and some operational use. It does not prove continuous production coverage, a current version or equal effectiveness across every network type. The project site also publishes comments from engineers associated with AMS-IX, Internet2 and ESnet, and displays organisation logos. This indicates testing or use, but does not justify calling every organisation a current paying customer or assigning the project a known global share.

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

Operator control brings integration work and software supply-chain risk

ARTEMIS is distributed under the BSD 3-Clause licence. An operator can inspect the code, run it in controlled infrastructure, modify integrations and avoid sending sensitive policy to one mandatory central service. This model matches the project’s main advantage: the most valuable reference information can remain inside the network. The licence permits commercial use and forks, allowing Code BGP and others to build services around the open foundation.

Control requires labour. The platform includes containers, a message bus, databases, an API, a web application, notifications and data-feed connections. Every component needs updates, credentials, network segmentation, backups and monitoring. The system stores sensitive routing policy and may hold privileges capable of changing announcements. The attack surface of a production deployment is therefore much broader than the original detection algorithm.

An open licence gives the operator a route away from dependence on one maintainer, but it does not create support automatically. Someone must still review updates, manage dependencies and understand the code when a data feed or router interface changes. A simpler alerting tool or managed commercial service may suit a small network better, even if it provides less local control.

A production ARTEMIS service must remain available during the same network instability that caused the operator to need it. Feed connections, the message bus, database, API, interface, notification channel and authentication layer form one service chain. Container-level redundancy 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 show an incident that detection failed to process.

The operating architecture should therefore define degraded modes. If one public feed disappears, the system should report reduced coverage rather than continue showing an indistinguishable “healthy” state. If the database is unavailable, the detector may need to retain events locally or suspend mitigation because audit evidence cannot be recorded. If the identity service fails, emergency access should remain possible without relying on a permanent uncontrolled account. These decisions lie outside hijack taxonomy, but they determine whether a research idea becomes reliable infrastructure.

The platform also needs its own performance budget. A burst of legitimate updates during a major routing change may place more load on monitors and storage than one hijack. Internal queues must not silently turn a near-real-time feed into a delayed incident report. Capacity testing, database retention periods and message-bus backpressure belong in planning for the same reason as route filters and prefix lengths: they constrain the response speed the system can honestly promise.

ARTEMIS combines web components, container images, a database, messaging, an API, authentication and networking libraries. This makes extension easier, but every dependency becomes a potential vulnerability or failure point. A user-interface flaw may expose routing policy. A compromised image may alter alerts. An over-privileged API token may reveal incident data, while credentials in a mitigation wrapper may permit route changes. The detector’s security is inseparable from the security of the software on which it runs.

Open code helps: operators can inspect components, pin versions and build images themselves. Openness does not guarantee that anyone has reviewed every transitive dependency or will repair a public vulnerability within the time a particular network needs. A production team requires an inventory of images and libraries, a rebuilding process, separation between read-only monitoring and write-capable mitigation, and a way to apply security updates without losing incident history.

This also changes how project maintenance should be assessed. A new detection feature is more visible than a database update or authentication fix, although the latter may matter more to service integrity. Security advisories, reproducible builds, dependency updates and a supported release branch are signs of operational maturity even when no new dashboard button appears.

Releases and Code BGP define the current maintenance test

The latest formally tagged release identified in the research material is version 2.3.0 Cadmus, dated 24 November 2022. At the 5 August 2026 cut-off, the live demonstration showed a later commit-based build and the project site remained active. This confirms that work continued after the last formal release, while raising 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 another kind of confidence: a named baseline, release notes, expected dependencies and a point against which an operator can test. A project may remain active while its release process lags, and a current demonstration may run code that a production network should not accept without its own validation.

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

The project site names Code BGP as the current maintainer of ARTEMIS and describes the company as a start-up that grew from the project. Commercialisation can address a real open-source problem. Routing-security tools need people to maintain integrations, respond to vulnerabilities, assist deployments and turn research functions into sustainable operations after initial grants end.

Code BGP is nevertheless a separate commercial company with a broader product and customer context. It cannot be used as another name for FORTH, CAIDA or every open deployment. The public material does not disclose the company’s revenue, valuation, customer list or the precise boundary between public and commercial capabilities. This is not a criticism but a limit on what the profile may claim.

The relationship creates two sets of 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 basis for paid services. The long-term test is whether releases, security fixes and roadmap decisions remain visible enough for operators that are not commercial customers.

A permissive licence guarantees the ability to copy, modify and commercialise source code. It does not guarantee that another team will understand the architecture, reproduce a release or assume maintenance when current specialists leave. Continuity depends on documentation, tests, issue history, dependency knowledge and a path for new contributors beyond the people who created the original research system.

Code BGP’s maintenance may strengthen continuity by keeping experienced engineers close to the platform. It may also concentrate practical knowledge inside a commercial organisation while the repository remains public. The difference can be judged through release notes, open design discussions, responses to community reports and whether non-customer deployments receive enough information to operate safely.

The aim is not to prevent commercial value. A healthy open-core model can connect paid support with public maintenance. Risk appears when the open project becomes a historical demonstration while the operational route moves into undocumented private components. Portability should therefore be tested in practice: can an independent operator install, update, verify and restore the system using currently available public material?

ARTEMIS occupies a demanding middle ground in routing protection

The routing-protection field includes public collectors, research inference systems, open 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 monitoring model. MANRS defines operational norms but does not detect events in real time. Commercial services may provide broad observation and analyst support, yet without customer integration they often lack private local context.

ARTEMIS’s distinctive position combines operator control, an explicit reference state, several public and local feeds, open code and optional mitigation. That position is also demanding. A network needs routing specialists, maintained policy and the ability to operate a multi-component platform. The project is therefore likely to fit organisations for which routing protection is an internal capability rather than another dashboard subscription.

Comparison cannot be reduced to a feature table. Different models distribute trust and labour differently. A managed service centralises knowledge and observation. An operator-side system keeps policy and action closer to the network. The practical question is which side sees enough, acts safely and remains accountable when evidence is incomplete.

ARTEMIS Lite appeared in RIPE community material in 2023 as a related lightweight approach intended to reduce some deployment burden. The existence of a Lite variant itself suggests that the full platform may be heavy for a small team. A multi-container stack with persistent storage, several feeds and custom mitigation may suit a large operator but be excessive for a network that first needs clear visibility and reliable alerts.

A lightweight system should not be treated as equivalent merely because it shares a name and purpose. The research material describes ARTEMIS Lite as a reduced-functionality variant, and claims from a presentation require independent confirmation. The material trade-off is between lower operating cost and context, integrations, history or response mechanisms that may be absent. A smaller deployment can still be useful if these limits are stated honestly.

Adoption depends on the institutional machinery a tool requires. A project may be technically open yet 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 beyond a research paper.

The real product is a governed feedback loop

ARTEMIS does not make BGP trustworthy through one action. It builds a loop around a protocol that was not designed with complete authorisation. The operator describes intended routing. Public and local feeds show part of the actual picture. The detector finds a mismatch. Storage and interfaces organise evidence. People or authorised automation choose a response, after which the feeds show whether propagation changed. The incident may be resolved, judged immaterial, closed after withdrawal, escalated or left without action for a recorded reason.

This loop is the project’s most durable contribution. It recognises that routing protection is neither a one-off certificate nor a distant alarm. It is an operational 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 a network to act, not in pretending uncertainty has disappeared.

The limitations are equally instructive. Route collectors see only part of the world. The reference state may become stale. Control-plane evidence proves neither motive nor every traffic consequence. A technically valid mitigation may be filtered or cause harm. Open code still requires continuing maintenance. ARTEMIS is strongest when these limits are built into the workflow rather than hidden behind a headline about a one-minute response.

A BGP anomaly may reach a network operations centre, a security operations centre or both. The routing team understands prefixes, upstream policy and the risk of changing announcements. The security team is better placed to correlate identity, service telemetry and possible malicious activity. ARTEMIS crosses these areas. It is useful only when an alert carries enough evidence for both teams to work on the same event rather than open separate investigations based on different assumptions.

An incident handover should separate observation, policy and impact. The system saw a route in specifically named feeds. The route violated a defined reference rule. Service checks or RIPE Atlas probes showed a particular effect—or no effect has yet been established. The operator contacted an upstream network or route origin and is awaiting a response. This structure prevents the NOC from dismissing a security concern as ordinary routing and the SOC from calling an unauthorised announcement an attack before operational facts are established.

A shared language also improves post-incident review. A case may close as a planned change omitted from policy, an accidental route leak, a suspected hijack, a confirmed malicious event or an unresolved anomaly. These outcomes should feed back into rules, procedures and upstream agreements. Without this loop, the detector risks becoming a ticket-generating machine rather than a system that improves routing control.

The fastest alert is not always the most useful. A detector may trigger on the first unexpected update, only for the feed to prove delayed, the route planned or the supposed victim to have authorised a new origin. Conversely, waiting for every collector and every data-plane test would destroy the advantage of early response. ARTEMIS needs a measure between raw detection time and final incident closure: how long does it take to gather sufficiently reliable evidence and allow an authorised operator to make a defensible decision?

This measure can be divided into parts. How quickly did the first observation arrive? How many independent feeds confirmed it? Was the relevant policy current? Did RPKI or local BMP add material evidence? How long did service checks take? When did the responsible employee receive the alert, and when was the response approved? Did mitigation propagate as expected, and was it withdrawn cleanly? These questions reveal where delay actually occurs instead of attributing the entire result to the detection algorithm.

A defensible-decision metric also discourages dangerous optimisation. A system should not be rewarded for acting faster when it relies on less evidence or creates an unnecessary routing change. The better deployment reduces both uncertainty and response time while preserving a record that can be examined after the incident.

Sources

  • ARTEMIS project website
  • Open-source ARTEMIS architecture on RIPE Labs
  • ARTEMIS source repository and documentation
  • “ARTEMIS: Neutralizing BGP Hijacking within a Minute”
  • Operational explanation of ARTEMIS on RIPE Labs
  • ARTEMIS demonstration paper at ACM SIGCOMM 2016
  • ARTEMIS releases
  • CAIDA 2019 annual report
  • RIPE RIS Live BGP message feed
  • University of Oregon RouteViews
  • CAIDA BGPStream
  • ExaBGP repository
  • Route Origin Validation, RFC 6811
  • RIPE Community Projects Fund 2019 recipients
  • Code BGP
  • CAIDA experimental ARTEMIS deployment
  • ARTEMIS live demonstration
  • BGP Monitoring Protocol, RFC 7854
  • RIPE Atlas