Em resumo

  • ARTEMIS é um sistema de código aberto implantado pelo próprio operador. Ele compara observações atuais de BGP com uma intenção de roteamento definida localmente e acrescenta um contexto que os coletores públicos, por si sós, não oferecem.
  • O estudo de 2018 de FORTH e CAIDA relatou detecção em segundos e neutralização em menos de um minuto nas condições testadas; isso não constitui uma garantia universal para operações em produção.
  • Para mitigar um incidente, ARTEMIS pode anunciar rotas mais específicas ou acionar procedimentos próprios. No entanto, filtros, políticas desatualizadas, visibilidade incompleta e permissões amplas podem transformar uma resposta rápida em um segundo incidente.
  • A viabilidade do projeto agora depende da disciplina de lançamentos, de evidências convincentes de adoção e de uma fronteira transparente com a Code BGP: o suporte comercial pode sustentar o código aberto sem substituir a história do projeto de pesquisa.

Uma mudança real de rota mostrou por que os segundos são apenas o começo

O relatório anual de 2019 da CAIDA afirma que ARTEMIS detectou, em poucos segundos, um sequestro real de rota que afetou um prefixo /30 da Internet2. O caso é importante porque leva as evidências além dos anúncios sintéticos preparados pelos próprios pesquisadores. Uma rota realmente mudou em uma rede participante da implantação, e o sistema reconheceu o desvio com rapidez suficiente para apoiar a investigação.

O relatório não estabelece uma distribuição universal do tempo de detecção. O /30 era um prefixo específico, em um contexto de roteamento específico, observado pelas fontes disponíveis naquela implantação. Outro incidente pode se propagar de maneira diferente, durar menos ou nem chegar aos coletores conectados. O relatório, por si só, também não comprova intenção maliciosa nem descreve todas as consequências no plano de dados. A conclusão correta é mais restrita: no programa de implantação da CAIDA, ARTEMIS detectou em poucos segundos um incidente real documentado.

Casos práticos têm valor justamente quando seus limites são preservados. Eles mostram como o programa se comporta diante de uma mudança real, como o operador recebe o alerta e quais evidências permanecem após o evento. Para avaliar a maturidade em produção, registros adicionais de incidentes — incluindo falsos positivos, eventos não detectados e resultados de mitigação — seriam mais úteis do que outro número de tempo chamativo.

Um alerta BGP pode chegar em segundos e ainda deixar sem resposta as perguntas mais importantes. Um coletor de rotas pode mostrar que um sistema autônomo desconhecido anunciou um prefixo ou que uma rota mais específica surgiu e começou a se propagar. Isso informa ao operador que o plano de controle já não corresponde ao cenário esperado. Mas essa evidência, isoladamente, não determina quem fez a mudança, se ela foi um erro, se o tráfego seguiu o novo caminho, se usuários foram afetados nem qual ação restaurará o serviço sem criar outro problema.

ARTEMIS foi criado precisamente para o intervalo entre a detecção e a ação. O nome significa Automatic and Real-Time dEtection and MItigation System, mas o uso incomum de maiúsculas não deve ocultar o modelo operacional. Não se trata de um serviço central que enxerga toda a internet e conserta redes alheias à distância. A organização implanta o programa em infraestrutura sob seu controle, define o estado de roteamento que considera legítimo, conecta observações públicas e privadas e decide até onde o sistema pode agir quando os dados reais divergem da política.

A promessa do projeto é velocidade com contexto; a limitação é que tanto o contexto quanto a autoridade permanecem locais.

Por isso, ARTEMIS se parece mais com um instrumento na sala de controle do próprio operador do que com uma “polícia da internet”. Ele pode organizar evidências, reduzir o tempo gasto pesquisando atualizações de rota e preparar uma reação previamente discutida. Contudo, não elimina a necessidade de julgamento do operador. A decisão final pode afetar o roteamento global, as relações com redes upstream e o tráfego dos clientes. Assim, a qualidade da resposta depende tanto das pessoas, da configuração e das permissões testadas quanto do detector.

O BGP transmite alcançabilidade antes de conseguir comprovar autoridade

O Border Gateway Protocol permite que redes administradas de forma independente troquem informações de alcançabilidade e apliquem suas próprias políticas. Um sistema autônomo anuncia que pode entregar tráfego a determinados prefixos IP; redes vizinhas decidem se aceitam essas rotas, se lhes dão preferência e se as propagam. Esse modelo permitiu que a internet se expandisse entre organizações sem um controlador único, mas o protocolo original não associa uma prova criptográfica a cada afirmação sobre origem ou caminho.

Portanto, uma exportação equivocada, uma configuração desatualizada ou um anúncio deliberado podem introduzir uma rota que não deveria existir.

O mecanismo de seleção de rotas pode tornar atraente um anúncio incorreto. Se duas rotas cobrem prefixos de mesmo comprimento, as redes aplicam suas políticas e regras de seleção. Se um invasor ou uma rede que cometeu um erro anuncia um subprefixo mais específico, a regra comum da correspondência pelo prefixo mais longo geralmente envia o tráfego para a rota mais estreita onde quer que ela seja aceita. Isso não é uma função especial de ataque, mas a regra normal para selecionar o destino mais preciso. Portanto, um anúncio aparentemente pequeno pode redirecionar tráfego rapidamente, mesmo quando a rota agregada legítima continua visível.

A palavra “sequestro” é uma abreviação conveniente, mas pode atribuir uma intenção que as mensagens de roteamento não revelam. Uma origem não autorizada pode ser maliciosa, acidental ou resultar de uma mudança comercial legítima que não foi incorporada à política de monitoramento. Um caminho falsificado pode ser usado para interceptar tráfego, mas uma única atualização do plano de controle não comprova que a interceptação realmente ocorreu. ARTEMIS é mais útil quando trata o alerta como uma divergência entre o roteamento observado e o pretendido, deixando a atribuição e a avaliação de impacto para um processo de resposta mais amplo.

Um evento de prefixo exato concorre com a rota legítima de mesmo comprimento. A extensão da propagação depende das políticas e da seleção de caminho nas redes que receberam os dois anúncios. Algumas partes da internet podem preferir a rota inesperada, enquanto outras continuam usando a origem legítima. O resultado pode ser alcançabilidade parcial, diferenças regionais e uma combinação confusa de sucessos e falhas, em vez de uma única interrupção clara. Por isso, a detecção deve considerar não apenas a existência da rota, mas também onde e como ela se propagou.

Um evento de subprefixo costuma atrair tráfego com mais força porque a regra do prefixo mais longo prioriza a rota mais específica. Se uma rede normalmente anuncia um /20 e outra origem anuncia um /24 contido nele, os roteadores que aceitarem o /24 geralmente direcionarão para o subprefixo o tráfego destinado a esses endereços. A desagregação também é uma defesa comum: o operador legítimo anuncia rotas igualmente ou ainda mais específicas para recuperar a preferência. O método, porém, tem um limite rígido: muitas redes filtram rotas IPv4 mais longas que /24 e rotas IPv6 mais longas que /48.

Se o operador já anuncia prefixos desse comprimento, talvez não exista uma rota mais específica com aceitação global.

ARTEMIS também considera ocupação indevida de espaço e determinadas violações de política, incluindo o cenário de no-export descrito nos materiais do projeto. Essas categorias importam porque um incidente de roteamento nem sempre consiste em uma rede externa anunciando o prefixo da vítima. Uma rota pode ter uma origem permitida e ainda assim escapar por uma relação inesperada. O sistema de monitoramento precisa de contexto de política suficiente para distinguir esses casos sem fingir que os dados BGP revelam todos os acordos privados entre redes.

ARTEMIS coloca a intenção de roteamento do operador dentro do detector

Serviços externos de monitoramento têm uma vantagem evidente: coletam dados de muitas partes da internet sem exigir que cada rede implante uma plataforma completa. A desvantagem é igualmente clara. Um terceiro vê prefixos e caminhos anunciados, mas pode não saber quais mudanças de origem, provedores de contingência, esquemas de engenharia de tráfego ou anúncios emergenciais o operador considera aceitáveis. Regras genéricas podem, portanto, deixar passar uma violação sutil de política ou gerar um alerta por causa de uma mudança planejada.

ARTEMIS muda o ponto de observação. O detector é executado pela organização cujo espaço de endereços está em risco, e é ela que define a referência. Coletores públicos continuam oferecendo uma visão externa ampla, mas suas observações são interpretadas com conhecimento privado sobre prefixos protegidos, AS de origem autorizados, vizinhos aceitáveis e relações de caminho escolhidas. Fluxos locais dos roteadores acrescentam eventos que os coletores públicos não veem. Essa é a ideia central do projeto: dados globais incompletos tornam-se mais úteis quando comparados com uma intenção local explicitamente definida.

Colocar o detector dentro da rede protegida também transfere a responsabilidade para esse ambiente. A organização que opera ARTEMIS precisa decidir quem é responsável pelo arquivo de política, como as mudanças são verificadas, quais alertas chegam ao centro de operações de rede, quais conclusões a equipe de segurança pode tirar e quem pode autorizar uma nova rota. O programa torna essa responsabilidade visível, mas não pode obrigar a instituição a exercê-la bem.

ARTEMIS pede que o operador defina os prefixos protegidos, os sistemas autônomos de origem legítimos, as relações aceitáveis com vizinhos e as regras de roteamento escolhidas. Com essa referência, o detector faz uma pergunta mais precisa do que um serviço externo universal. Em vez de decidir se uma rota parece incomum diante do histórico mundial, o sistema verifica se ela viola a intenção declarada de uma rede específica.

A vantagem é tão confiável quanto a própria declaração. Redes trocam de provedores, acrescentam pontos anycast, transferem AS de origem, criam caminhos temporários de contingência e emitem anúncios emergenciais durante falhas. Uma política correta em janeiro pode estar desatualizada em junho. Se a mudança chegar aos roteadores, mas não a ARTEMIS, o detector poderá produzir um falso positivo de alta gravidade. Se as regras forem ampliadas excessivamente para reduzir ruído, uma violação real poderá aparecer como “permitida” no papel.

O sistema transforma, assim, uma configuração técnica em um acordo institucional. Engenheiros de roteamento, equipe de segurança e gestão de mudanças precisam concordar sobre o significado do arquivo, quem pode editá-lo e com que rapidez ele acompanha a rede de produção. O contexto local não elimina falsos positivos e falsos negativos; ele desloca sua principal origem para uma área que o operador consegue administrar.

Uma regra de segurança de roteamento merece a mesma disciplina aplicada a código capaz de afetar o tráfego de clientes. Mudanças devem ter responsáveis designados, revisão, histórico de versões, testes e uma justificativa vinculada a uma alteração de rede aprovada. O operador deve conseguir responder quando um prefixo, uma origem ou um vizinho foi adicionado, quem autorizou a mudança e qual incidente ou projeto fundamentou a decisão. Um arquivo de configuração comum pode sustentar esse processo, desde que a organização não o trate como parte descartável da instalação.

Os testes devem incluir cenários positivos e negativos. Uma rota legítima planejada deve passar sem alerta. Um anúncio de prefixo exato por uma origem não autorizada deve receber a classificação esperada. Um evento de subprefixo deve produzir o nível correto de gravidade, e uma violação de no-export não deve ser confundida com um sequestro de origem. A reprodução histórica ajuda a verificar esses casos, enquanto um ambiente de testes confirma que notificações e procedimentos de mitigação recebem os dados esperados.

Essa disciplina também limita a perda de conhecimento organizacional. Quando a pessoa que implantou ARTEMIS pela primeira vez deixa a equipe, a política precisa continuar compreensível para o próximo operador. Um detector cuja lógica depende de memória não documentada não é uma infraestrutura confiável, mesmo que seu código seja aberto e suas fontes operem com baixa latência.

FORTH e CAIDA transformaram uma questão de pesquisa em um processo operacional

O projeto surgiu da colaboração entre pesquisadores da Foundation for Research and Technology-Hellas, no ecossistema da Universidade de Creta, e da CAIDA, na Universidade da Califórnia em San Diego. FORTH contribuiu com conhecimento sobre proteção de roteamento e engenharia de sistemas. A CAIDA acrescentou infraestrutura de medição da internet, experiência com BGPStream e relações que ajudaram a levar o desenvolvimento às redes de pesquisa e educação. Desde o início, portanto, ARTEMIS não foi apenas um algoritmo de detecção: reuniu conhecimento de protocolo, sistemas de medição e acesso a operadores.

O financiamento seguiu o mesmo modelo institucional misto. A história do projeto inclui programas de pesquisa europeus e norte-americanos, o Community Projects Fund da RIPE NCC, um projeto de implantação NSF EAGER, o Departamento de Segurança Interna dos Estados Unidos e o Comcast Innovation Fund. O apoio da RIPE em 2017 ajudou a transformar o protótipo em uma ferramenta para operadores, e uma subvenção de € 50 mil em 2019 financiou a verificação do plano de dados por meio do RIPE Atlas.

Esses recursos mostram como uma pesquisa de interesse público se tornou software implantável, mas não revelam o custo atual de suporte a instalações em produção.

A história institucional é importante para uma atribuição correta. ARTEMIS não é uma fundação constituída separadamente, um serviço da CAIDA nem um detector global pertencente a FORTH. É um software aberto sob a licença BSD 3-Clause, com origem acadêmica e um mantenedor comercial atual. Seu desenvolvimento é descrito com mais precisão como uma sequência de colaborações, e não como propriedade de uma única organização.

O primeiro marco público foi uma demonstração na ACM SIGCOMM em 2016. O principal avanço foi conectar monitoramento e mitigação em um único ciclo. Muitos sistemas conseguem reconhecer uma rota suspeita depois de acumular dados. ARTEMIS formulou outra pergunta: o operador consegue ver o evento rápido o bastante e já ter uma contramedida prática preparada, evitando que o incidente passe durante horas entre painéis, e-mails e sessões manuais em roteadores?

Uma demonstração não equivale a uma implantação madura em produção. Ela mostra que os componentes podem funcionar juntos em determinada configuração e que o problema de pesquisa é concreto o bastante para um experimento público. Ainda assim, o trabalho de 2016 definiu a direção posterior: observações ao vivo, representação interna do roteamento legítimo, classificação e anúncio preparado. Essa sequência transformou o tempo de resposta de uma consequência organizacional em uma propriedade do sistema.

O projeto foi influenciado por relatos de operadores segundo os quais a reação a um sequestro de rota podia levar horas. O atraso não se devia apenas a coletores lentos. As equipes precisavam confirmar a propriedade do prefixo, examinar a propagação, descobrir se a mudança estava planejada, localizar os contatos corretos no provedor e preparar um contra-anúncio seguro. ARTEMIS reduz várias dessas etapas ao manter políticas e procedimentos próximos do monitoramento, mas as relações humanas e comerciais em torno da rota permanecem fora do código.

O artigo de 2018 publicado na IEEE/ACM Transactions on Networking apresentou a afirmação mais memorável sobre ARTEMIS: neutralizar um sequestro BGP em até um minuto. Os pesquisadores testaram a abordagem em experimentos reais e relataram detecção em segundos e mitigação antes do fim do primeiro minuto nas condições avaliadas. O resultado foi importante porque mostrou que a rede vítima não precisava necessariamente esperar por um serviço externo, uma cadeia de telefonemas e um contra-anúncio preparado manualmente.

A frase se torna enganosa quando é separada do experimento. O tempo de detecção depende de o evento chegar a um observador conectado, da velocidade com que a fonte entrega a atualização, da correspondência com as regras do detector e da integridade do próprio sistema. O tempo de mitigação depende do comprimento do prefixo da vítima, de sua autoridade de roteamento, dos filtros dos provedores, da propagação e do procedimento de aprovação escolhido. Uma rede que exija confirmação humana pode tomar uma decisão mais segura e gastar mais tempo. Uma rede com automação imediata responderá mais rápido, mas assumirá risco adicional.

A conclusão responsável deve permanecer limitada. ARTEMIS demonstrou que um sistema fortemente integrado e operado pela própria rede pode comprimir um processo que antes costumava levar muito mais tempo. Não demonstrou que todo sequestro será visível, que todo contra-anúncio será aceito nem que todas as equipes de produção devem permitir desagregação autônoma. O resultado deve ser lido como um objetivo de projeto confirmado experimentalmente, não como garantia universal.

Várias visões incompletas formam um quadro útil do incidente

ARTEMIS pode usar várias fontes públicas porque nenhum coletor vê todas as rotas. O RIPE RIS e o projeto RouteViews da Universidade do Oregon recebem atualizações BGP de parceiros selecionados em pontos de coleta distribuídos. O CAIDA BGPStream fornece um mecanismo comum para acessar e normalizar dados de roteamento provenientes de várias fontes. Cada serviço amplia o campo de visão do operador, mas também reflete apenas as redes que decidiram se conectar aos seus coletores, a geografia dessas sessões e as características temporais dos fluxos.

A visibilidade parcial tem consequências práticas. Um evento pode se propagar em uma região e não alcançar nenhum coletor conectado a determinada implantação. Um anúncio muito curto pode ser retirado antes de ser entregue pelo fluxo. Uma rota pode afetar clientes da vítima por meio de uma relação privada ausente dos dados abertos. Combinar coletores reduz alguns pontos cegos, mas fornece apenas uma amostra maior, não uma cópia onisciente do plano de controle global.

Por isso, a pergunta operacional correta não é “ARTEMIS viu a internet?”, mas “quais observadores viram este anúncio, com que rapidez e qual parte do evento pode ter permanecido fora da amostra?”. Essa formulação incentiva a preservação da origem de cada alerta e evita tratar a ausência em um fluxo como prova de que a rota não existiu.

RIPE NCC apresentou um protótipo público do RIS Live em fevereiro de 2019 para transmitir mensagens BGP com latência muito menor do que o processamento periódico de arquivos. ARTEMIS tornou-se um exemplo da necessidade desse tipo de fluxo. Um sistema de segurança não consegue reagir em segundos se sua observação principal chega muitos minutos depois, enquanto um fluxo em tempo real permite avaliar atualizações à medida que os coletores as recebem.

A latência menor não altera os limites da observação. RIS Live continua refletindo os parceiros conectados ao RIPE Routing Information Service e as rotas exportadas por eles. Se o sequestro permanecer local, for filtrado antes do coletor ou afetar um caminho oculto por outra relação, a evidência decisiva poderá não aparecer no fluxo. A confiabilidade também importa: uma falha no fluxo ou uma mudança de esquema parecerá silêncio se o monitoramento não distinguir entre “não há rotas suspeitas” e “não há dados”.

Por essa razão, o estado da fonte faz parte do modelo de segurança. O operador precisa saber se cada monitor funciona em tempo hábil, está atrasado, desconectado ou produz um volume incomum de atualizações. Um detector que mostra normalidade com confiança enquanto suas entradas estão degradadas pode criar uma ignorância mais perigosa do que uma falha explícita.

O monitoramento em tempo real responde ao que está surgindo agora; bases de informações de roteamento e arquivos de atualizações fornecem contexto. RIPE RIS e RouteViews publicam históricos que mostram origens e caminhos anteriores ao incidente, o momento em que a mudança começou e sua duração. CAIDA BGPStream simplifica o processamento desses registros por meio de um mecanismo comum, permitindo que ARTEMIS reproduza eventos e teste regras diante de comportamentos passados.

A reprodução é útil para verificação de engenharia e análise. A equipe pode descobrir se uma nova regra teria detectado um evento conhecido, reconstruir a sequência que levou ao alerta ou treinar responsáveis sem alterar uma rota real de produção. O histórico também revela anúncios recorrentes que parecem anômalos isoladamente, mas pertencem a uma estratégia de contingência estabelecida. A limitação permanece: o arquivo registra a visão dos coletores, não todo o evento, e a topologia anterior não reproduz todas as relações atuais.

Uma implantação madura pode incorporar a reprodução à gestão de mudanças. Antes de colocar em produção uma nova origem, um provedor ou uma regra de exportação, o operador testa a referência atualizada em um histórico representativo e verifica se o roteamento normal não se transformará em alerta permanente. A configuração do detector torna-se, assim, um artefato de segurança verificável, e não um arquivo editado apenas quando começa a gerar ruído.

Os dados públicos são apenas um lado da arquitetura. ARTEMIS pode receber atualizações locais por ExaBGP ou sessões privadas do BGP Monitoring Protocol. ExaBGP funciona como um speaker BGP programável e envia eventos a outras aplicações. BMP permite que roteadores exportem informações de roteamento para um sistema de monitoramento sem incluí-lo na decisão de encaminhamento de pacotes. Essas fontes mostram as próprias adjacências e o estado das rotas da rede protegida antes que os dados cheguem a um coletor público.

Fluxos locais melhoram a rapidez e o contexto, mas introduzem informações sensíveis de infraestrutura na plataforma. Dados BMP podem ser volumosos e revelar relações internas de roteamento. A integração com ExaBGP exige controle rigoroso porque a mesma interface programável pode não apenas observar, mas também anunciar rotas. Credenciais, acesso à rede, validação de mensagens e separação entre monitoramento e mitigação tornam-se fronteiras de segurança.

Uma implantação bem projetada usa fluxos públicos e privados para tarefas diferentes. Coletores públicos mostram a propagação de um anúncio além do entorno imediato do operador. Fontes locais mostram o que a própria rede e seus roteadores observaram. A divergência entre elas não é necessariamente um erro; pode constituir evidência de onde a propagação parou ou de onde uma política entrou em vigor.

A aplicação separa observação, detecção e evidências

A plataforma atual é uma aplicação de microsserviços com vários contêineres, não um único script que lê um fluxo. Serviços de monitoramento conectam-se a fontes públicas e privadas, normalizam informações BGP recebidas e publicam eventos. Serviços de detecção recebem esses eventos e aplicam as regras do operador. Ao redor do núcleo estão armazenamento, API, interface web, notificações e supervisão. A separação permite que componentes sejam dimensionados ou falhem de modo independente e facilita a inclusão de uma nova fonte sem reescrever todo o sistema.

A modularidade também multiplica dependências. Um monitor pode estar saudável enquanto o detector está parado. O barramento de mensagens pode receber eventos quando o banco de dados está indisponível. A interface web pode mostrar um incidente antigo enquanto o fluxo ao vivo está interrompido. O orquestrador pode reiniciar um contêiner e ocultar falhas recorrentes. Portanto, as verificações operacionais precisam cobrir todo o caminho da fonte ao alerta, e não apenas informar que contêineres individuais estão em execução.

Docker Compose reduz a barreira para uma implantação controlada, enquanto o suporte a Kubernetes atende organizações que já operam plataformas de contêineres. Nenhuma das opções transforma o sistema em um serviço global gerenciado. A rede que o implanta continua responsável por capacidade, atualizações, segredos, armazenamento, cópias de segurança e acesso emergencial.

O barramento de mensagens permite que serviços de monitoramento, detecção e notificação troquem eventos sem subordinar todos os processos diretamente a um único componente. A arquitetura pode absorver picos de atualizações e permitir que consumidores trabalhem em velocidades diferentes. Porém, também levanta questões de ordenação, duplicidade e contrapressão. Um incidente de roteamento pode gerar milhares de atualizações, retiradas e mudanças de caminho. O sistema precisa preservar sequência e origem suficientes para que o operador reconstrua o evento.

O armazenamento persistente dá a ARTEMIS uma vantagem sobre um alerta descartável. Atualizações, alertas, estado da configuração e decisões sobre incidentes podem ser preservados para análise posterior. A arquitetura já utilizou componentes PostgreSQL, armazenamento no estilo Timescale e o ecossistema de API Hasura. Essas escolhas facilitam consultas e integrações, mas também criam um arquivo sensível de evidências operacionais e de roteamento que exige prazos de retenção, controle de acesso e cópias de segurança confiáveis.

Capacidade de auditoria não equivale a certeza. Um registro completo do que foi recebido pode demonstrar como ARTEMIS chegou a um alerta. Não comprova que o sistema viu todas as rotas relevantes nem que as regras do operador estavam corretas. O banco deve, portanto, preservar a origem e o grau de confiança, não apenas o rótulo final do incidente.

A interface web apresenta incidentes, estado do sistema e observações de roteamento em um formato adequado a um centro de rede ou segurança. As notificações enviam alertas por e-mail, canal móvel ou integração própria, enquanto painéis Grafana mostram a integridade do serviço e tendências de eventos. Essas funções transformam um mecanismo de pesquisa em produto operacional: uma equipe de resposta precisa de prioridades, histórico e uma visão unificada, não de atualizações BGP brutas.

A interface também pode criar falsa confiança. Um cartão vermelho de incidente representa uma classificação baseada em observações e regras, não uma comprovação independente de intenção maliciosa. Um mapa ou uma imagem do caminho pode parecer completo embora represente apenas os coletores escolhidos. Se mudanças planejadas não forem refletidas na política, as notificações viram ruído e a fadiga de alertas aumenta o risco de ignorar um evento realmente importante.

Uma boa prática conecta a interface à verificação. O responsável deve conseguir abrir as atualizações de origem, comparar fluxos públicos e locais, verificar o estado atual de RPKI, executar testes do plano de dados e registrar por que o incidente foi escalado, ignorado ou encerrado. O painel é útil quando reduz esse caminho, não quando o substitui.

Um padrão de rota não comprova motivo nem consequências

A pesquisa de ARTEMIS desenvolveu uma classificação que distingue eventos segundo relações entre prefixos, manipulações do caminho AS, políticas e possíveis efeitos no plano de dados. A implementação oferece suporte a um subconjunto desses padrões com base em evidências do plano de controle: casos de prefixo exato e subprefixo com origem incorreta, ocupação indevida de espaço e determinadas violações de exportação. A classificação fornece uma linguagem comum e permite aplicar regras diferentes a eventos distintos.

As categorias precisam permanecer vinculadas ao que os dados realmente demonstram. Um caminho iniciado por um vizinho inesperado pode representar um segmento falsificado, um vazamento de rota ou uma mudança permitida que não foi registrada na política. Uma origem não autorizada pode ser um erro, não um ataque. Mesmo um anúncio deliberado pode pretender descartar tráfego, substituir um serviço ou observar trânsito, e as atualizações BGP isoladas não distinguem esses resultados.

Uma terminologia cautelosa protege a precisão e a qualidade da resposta. Na fase de alerta, “suspeita de sequestro” ou “violação de política” costuma ser mais seguro do que “ataque”. Formulações mais fortes devem ser usadas após verificar a titularidade da rota, os contatos com o operador e os dados do plano de encaminhamento. Essa contenção não enfraquece a defesa; evita que o classificador transforme incerteza em uma afirmação que outras equipes repetirão como fato.

Mensagens BGP descrevem afirmações de alcançabilidade e caminhos trocadas entre redes. Elas não mostram todos os pacotes que seguiram a rota escolhida. Depois de um anúncio suspeito, o tráfego pode cair em um buraco negro, ser interceptado e encaminhado, receber resposta de um serviço substituto ou permanecer inalterado se a rota não se propagar pelas redes dos usuários relevantes. Diferentes partes da internet podem enfrentar consequências distintas ao mesmo tempo.

Essa fronteira é central para ARTEMIS. O detector pode mostrar que uma rota violou a política do operador e apareceu em determinados pontos de observação. Não deduz o motivo a partir do caminho AS nem garante que um traceroute siga a mesma direção do tráfego de uma aplicação. Criptografia, comportamento do DNS, cache, anycast e alternância de aplicações também modificam a experiência do usuário. Um alerta do plano de controle é evidência do incidente, mas não representa o incidente inteiro.

Uma resposta útil combina vários registros. Dados BGP estabelecem o anúncio e sua propagação. Testes do plano de dados verificam alcançabilidade e caminhos a partir de locais selecionados. A telemetria do serviço mostra erros, latência e impacto nos clientes. Contatos com provedores estabelecem se o anúncio foi autorizado ou equivocado. Nenhuma fonte é perfeita, mas juntas elas sustentam uma decisão que um único fluxo não consegue oferecer.

Uma subvenção de 2019 do RIPE Community Projects Fund apoiou a ampliação de ARTEMIS com medições traceroute do RIPE Atlas para avaliar os efeitos dos eventos detectados. O trabalho reconhecia uma limitação do ciclo original do plano de controle. Uma rota pode parecer perigosa no BGP e ter pouco efeito sobre os usuários, enquanto uma pequena área de propagação pode atingir um grupo valioso de clientes. As sondas do plano de dados acrescentam informações sobre o provável caminho do tráfego e a alcançabilidade dos destinos.

RIPE Atlas possui uma rede distribuída de sondas, mas sua localização não é uniforme e o destino selecionado pode responder de modo que o caminho não seja revelado. Traceroute é afetado por filtragem, balanceamento de carga, túneis e roteamento assimétrico. O caminho direto da sonda ao destino não precisa coincidir com o caminho de retorno do tráfego dos clientes. Uma medição malsucedida pode indicar falha, um nó que não responde ou uma limitação do teste específico.

O ganho prático não é certeza total, mas uma triagem melhor. Se coletores BGP mostram um subprefixo não autorizado e sondas em várias regiões perdem alcançabilidade ou mudam para um caminho com origem inesperada, há mais fundamento para escalar o incidente. Se o evento do plano de controle é visto por apenas um coletor e os testes permanecem estáveis, a equipe pode continuar investigando antes de mudar anúncios globais. A decisão ainda depende do contexto, mas é tomada com menos pontos cegos.

A desagregação só recupera o tráfego quando o sistema de roteamento a permite

A resposta mais conhecida de ARTEMIS é a desagregação. Uma vítima que anuncia um prefixo amplo pode começar a anunciar rotas mais específicas para que a seleção normal pelo prefixo mais longo devolva o tráfego à rede legítima. O método utiliza o comportamento padrão do BGP e pode se propagar rapidamente, o que o tornou adequado ao objetivo experimental de resposta “em até um minuto”. Ele também mantém a ação sob controle da vítima, sem exigir a cooperação da origem inesperada antes do início da recuperação.

A desagregação tem limites rígidos. Muitas redes filtram rotas IPv4 mais longas que /24 e rotas IPv6 mais longas que /48 para limitar o crescimento das tabelas e abusos. Uma vítima que já anuncia um /24 ou /48 talvez não consiga emitir uma rota mais específica aceita amplamente pela internet. Provedores também limitam os anúncios permitidos ao cliente, e objetos de rota, filtros de prefixos ou dados RPKI precisam admitir o estado emergencial. A propagação não é instantânea nem uniforme, de modo que caminhos antigos e novos podem coexistir.

Um operador preparado conhece essas fronteiras previamente. Quais prefixos podem ser desagregados? Quais provedores os aceitarão? Quais filtros de rota e Route Origin Authorisations já cobrem o estado emergencial? Como as rotas serão retiradas após a recuperação? ARTEMIS pode acionar um procedimento externo, mas o sucesso depende de acordos fora da aplicação.

Os materiais do projeto falam em mitigação automática, e a pesquisa inclui um ciclo fechado em que a detecção aciona um contra-anúncio. Descrições operacionais detalhadas também mostram confirmação manual e procedimentos iniciados pelo usuário. As duas afirmações são compatíveis porque as implantações escolhem níveis diferentes de autonomia. A formulação segura é: ARTEMIS oferece suporte à mitigação automatizada ou aprovada pelo operador por meio de fluxos de trabalho configuráveis.

O risco é assimétrico. Um atraso pode prolongar a interrupção ou a interceptação. Uma resposta automática incorreta pode anunciar rotas mais específicas desnecessárias, violar a política do provedor, revelar pressupostos internos ou criar instabilidade enquanto o evento original ainda está sendo investigado. Uma referência desatualizada pode transformar uma mudança planejada em falsa emergência. Se um procedimento externo tiver permissões amplas nos roteadores, o comprometimento de ARTEMIS torna-se, por si só, um ataque ao roteamento.

Uma automação mais segura é construída em etapas. Primeiro, o sistema enriquece o alerta, verifica vários fluxos, o estado de RPKI e o plano de dados e prepara uma mudança de rota precisa. Ações de alto impacto são aprovadas por uma pessoa, enquanto casos de menor risco podem prosseguir automaticamente conforme a política. Limites de frequência, permissões restritas, simulação, registro de mudanças e reversão testada são mais importantes do que o rótulo “automático”. O objetivo não é preservar o trabalho manual por si só, mas impedir que a velocidade elimine a responsabilização.

RPKI fortalece apenas um elo da cadeia de evidências

Resource Public Key Infrastructure permite que detentores de endereços criem Route Origin Authorisations que indicam quais sistemas autônomos podem anunciar determinados prefixos e comprimentos máximos. Roteadores ou sistemas de política executam Route Origin Validation e classificam uma rota como válida, inválida ou não encontrada nos registros. Isso acrescenta evidência criptográfica à parte do BGP que, de outro modo, depende de confiança distribuída. O controle é proativo: outras redes podem rejeitar ou reduzir a preferência de uma origem não autorizada antes que o tráfego a utilize.

ARTEMIS atua em outro nível do incidente. Pode usar o estado de validação RPKI como evidência, mas também compara rotas com regras privadas do operador, registra o evento, reúne fluxos públicos e locais e conecta a detecção à resposta. RPKI não verifica todo o caminho AS, e sua adoção não é universal. Uma rota pode ser válida segundo RPKI e ainda violar uma relação de vizinhança esperada ou vazar por um caminho indesejado. Inversamente, uma mudança legítima será inválida se não tiver sido incluída na ROA.

Os mecanismos, portanto, se complementam. RPKI reduz o número de origens não autorizadas aceitas pela internet em geral. ARTEMIS mostra à vítima as observações reais, detecta determinados padrões além da simples validade da origem e organiza a resposta. Futuros mecanismos de autorização de caminho, como ASPA, podem fortalecer as evidências sobre relações, mas não eliminarão a necessidade de observar o que as redes realmente anunciam e como os eventos afetam os serviços.

Projetos-piloto tiraram ARTEMIS do laboratório, mas não comprovaram escala de mercado

CAIDA informou uma implantação experimental de ARTEMIS, apoiada pela NSF, com Internet2, Great Plains Network e Merit em 2018 e 2019. Esses pilotos são importantes porque redes de pesquisa e educação têm prefixos reais, provedores, processos de mudança e obrigações de serviço. Os operadores puderam testar se o programa se integrava ao monitoramento existente, se as regras refletiam sua intenção de roteamento e como os alertas entravam no processo de resposta.

As evidências são convincentes, mas limitadas. Um piloto confirma instalação, retorno de engenharia e algum uso operacional. Não comprova cobertura contínua em produção, atualidade da versão nem eficácia igual em todos os tipos de rede. O site do projeto também publica depoimentos de engenheiros ligados a AMS-IX, Internet2 e ESnet e exibe logotipos de organizações. Isso indica testes ou uso, mas não permite classificar cada organização como cliente pagante atual nem atribuir ao projeto uma participação mundial conhecida.

A distinção importa porque implantações de software de proteção de roteamento frequentemente são invisíveis. Um operador pode usar uma versão interna derivada, limitar-se ao monitoramento sem mitigação ou encerrar a iniciativa depois de um teste. A ausência de um registro completo não torna o projeto irrelevante, mas impede medir sua adoção com precisão. Casos identificados são evidências mais fortes do que um número elevado sem comprovação.

O controle do operador traz trabalho de integração e proteção da cadeia de software

ARTEMIS é distribuído sob a licença BSD 3-Clause. O operador pode examinar o código, executá-lo em infraestrutura controlada, modificar integrações e evitar enviar políticas sensíveis a um único provedor central obrigatório. Esse modelo corresponde à principal vantagem do projeto: as informações de referência mais valiosas devem permanecer dentro da própria rede. A licença também permite uso comercial e versões derivadas, de modo que Code BGP e outros participantes podem criar serviços sobre a base aberta.

Controle exige trabalho. A plataforma inclui contêineres, barramento de mensagens, bancos de dados, APIs, aplicação web, sistemas de notificação e conexões com fluxos de dados. Cada componente precisa de atualizações, credenciais, segmentação de rede, cópias de segurança e monitoramento. O sistema armazena políticas sensíveis de roteamento e pode ter permissões capazes de afetar anúncios. Por isso, a superfície de ataque de uma implantação em produção é muito maior do que o algoritmo original de detecção.

A licença aberta oferece ao operador uma saída da dependência de um único mantenedor, mas não cria automaticamente um serviço de suporte. Alguém ainda precisa revisar atualizações, analisar dependências e compreender o código quando um fluxo de dados ou uma interface de roteador muda. Para uma rede pequena, uma ferramenta de alertas mais simples ou um serviço comercial gerenciado pode ser mais conveniente, ainda que ofereça menos controle local.

Um serviço ARTEMIS em produção deve permanecer funcional durante a mesma instabilidade de rede que levou o operador a adotá-lo. Conexões com fluxos, barramento de mensagens, banco de dados, API, interface, canal de notificações e camada de autenticação formam uma única cadeia de serviço. Redundância no nível dos contêineres só ajuda quando estado, armazenamento e dependências externas também foram projetados para falhar. Reiniciar um monitor não recupera atualizações que não foram preservadas, e uma interface replicada não mostrará um incidente se o processo de detecção não conseguir tratá-lo.

A arquitetura operacional deve, portanto, prever explicitamente modos degradados. Se um fluxo público desaparecer, o sistema deve informar a redução de cobertura, em vez de continuar mostrando um estado “saudável” indistinguível. Quando o banco de dados estiver indisponível, o detector talvez precise armazenar eventos localmente ou interromper a mitigação porque as evidências de auditoria não podem ser registradas. Se o provedor de identidade falhar, o acesso emergencial deve continuar possível, mas não por uma conta permanente sem controle.

Essas decisões não fazem parte da taxonomia de sequestros, porém determinam se a ideia de pesquisa se tornará uma infraestrutura confiável.

A plataforma também precisa de um orçamento próprio de desempenho. Um pico de atualizações legítimas durante uma grande mudança de roteamento pode sobrecarregar monitores e armazenamento mais do que um único sequestro. Filas internas não devem transformar silenciosamente um fluxo quase em tempo real em um relatório atrasado. Testes de capacidade, prazos de retenção no banco e contrapressão do barramento devem integrar o planejamento pelo mesmo motivo que filtros de rota e comprimentos de prefixo: eles limitam a velocidade de resposta que o sistema pode prometer honestamente.

ARTEMIS combina componentes web, imagens de contêiner, banco de dados, mensageria, APIs, autenticação e bibliotecas de rede. A arquitetura facilita a expansão, mas cada dependência se torna uma possível vulnerabilidade ou ponto de falha. Um erro na interface pode expor políticas de roteamento. Uma imagem comprometida pode alterar alertas. Um token de API excessivamente amplo pode acessar informações sobre incidentes, e credenciais no componente de mitigação podem permitir mudanças de rota. A segurança do detector é, portanto, inseparável da segurança do software em que ele opera.

O código aberto ajuda: o operador pode examinar componentes, fixar versões e compilar suas próprias imagens. Mas a abertura não garante que alguém tenha revisado cada dependência transitiva nem que uma vulnerabilidade pública seja corrigida no prazo necessário a uma rede específica. Uma equipe de produção precisa de inventário de imagens e bibliotecas, processo de recompilação, separação entre monitoramento somente leitura e mitigação com permissão de escrita e uma forma de aplicar atualizações de segurança sem perder o histórico dos incidentes.

Isso também altera os critérios de manutenção do projeto. Uma nova função de detecção é mais visível do que uma atualização de banco de dados ou uma correção de autenticação, embora estas possam ser mais importantes para a integridade do serviço. Boletins de segurança, compilações reproduzíveis, atualização de dependências e uma linha de lançamentos mantida são sinais de maturidade operacional, mesmo que nenhum novo botão apareça no painel.

Os lançamentos e a Code BGP definem o teste atual de manutenção

O último lançamento formalmente identificado no conjunto de pesquisa é a versão 2.3.0 Cadmus, de 24 de novembro de 2022. Na data de corte de 5 de agosto de 2026, a demonstração ao vivo exibia uma compilação posterior baseada em um commit, e o site do projeto permanecia ativo. Isso confirma que o trabalho continuou após o último lançamento formal, mas também levanta uma questão legítima para produção: qual versão foi verificada, recebe suporte e pode ser atualizada com segurança?

Atividade de commits e uma demonstração funcional indicam desenvolvimento. Um lançamento semântico oferece outro tipo de confiança: uma versão de referência identificada, notas de lançamento, dependências esperadas e um ponto em relação ao qual o operador pode realizar testes. Um projeto pode continuar ativo mesmo com um processo de lançamentos atrasado, e a demonstração atual pode executar um código que uma rede de produção não deveria adotar sem verificação própria.

Para uma infraestrutura de proteção de roteamento, a disciplina de lançamentos faz parte do modelo de segurança. Os operadores precisam saber quais ramificações recebem correções, como as migrações são realizadas e se dependências antigas continuam vulneráveis. Uma nova etiqueta de versão não comprovaria confiabilidade universal, mas uma política publicada de suporte e segurança reduziria mais a incerteza do que um site ativo isoladamente.

O site do projeto identifica Code BGP como atual mantenedora de ARTEMIS e descreve a empresa como uma startup surgida do projeto. A comercialização pode resolver um problema real do software aberto. Ferramentas de proteção de roteamento precisam de pessoas que mantenham integrações, respondam a vulnerabilidades, ajudem nas implantações e transformem funções de pesquisa em operações sustentáveis depois do término das subvenções iniciais.

Ao mesmo tempo, Code BGP é uma empresa comercial separada, com um contexto mais amplo de produtos e clientes. Não pode ser usada como outro nome para FORTH, CAIDA ou qualquer implantação aberta. Os materiais públicos analisados não revelam receita, avaliação, lista de clientes da empresa nem a fronteira exata entre funções comunitárias e recursos comerciais. Isso não é uma crítica, mas o limite do que o perfil pode afirmar.

A relação cria dois conjuntos de incentivos que podem convergir ou divergir. O projeto aberto se beneficia quando funcionários comerciais contribuem com código e documentação verificados. A empresa se beneficia quando o projeto aberto gera confiança, adoção e uma base técnica para serviços pagos. O teste de longo prazo será saber se lançamentos, correções de segurança e decisões sobre o roteiro permanecerão suficientemente visíveis para operadores que não são clientes comerciais.

A licença permissiva garante a possibilidade de copiar, modificar e comercializar o código-fonte. Não garante que outra equipe compreenderá a arquitetura, reproduzirá um lançamento ou assumirá a manutenção quando os atuais especialistas saírem. A continuidade depende de documentação, testes, histórico de tarefas, conhecimento das dependências e um caminho para novos colaboradores que vá além das pessoas que criaram o sistema original.

A manutenção pela Code BGP pode reforçar essa continuidade ao manter engenheiros experientes próximos da plataforma. Também pode concentrar conhecimento prático dentro de uma organização comercial, ainda que o repositório permaneça público. A diferença será visível nas notas de lançamento, nas discussões abertas de projeto, nas respostas à comunidade e na quantidade de informações oferecida às implantações de não clientes para uma operação segura.

O objetivo não é proibir valor comercial. Um modelo saudável de núcleo aberto pode associar suporte pago à manutenção pública. O risco surge quando o projeto aberto se torna uma demonstração histórica e o caminho operacional migra para componentes privados não documentados. Por isso, a portabilidade deve ser testada na prática: um operador independente consegue instalar, atualizar, verificar e recuperar o sistema usando os materiais públicos atualmente disponíveis?

ARTEMIS ocupa uma posição intermediária exigente na proteção de roteamento

O campo da proteção de roteamento inclui coletores públicos, sistemas acadêmicos de inferência, ferramentas abertas de alerta, validadores RPKI e plataformas comerciais de monitoramento. RIPE RIS, RouteViews e BGPStream fornecem dados, não um processo de incidente configurado para um operador específico. BGPalerter oferece outro modelo aberto de monitoramento. MANRS estabelece normas operacionais, mas não detecta eventos em tempo real. Serviços comerciais podem proporcionar observação ampla e suporte de analistas, porém, sem integração com o cliente, frequentemente não têm acesso ao contexto local privado.

A posição diferenciada de ARTEMIS combina controle pelo operador, referência explicitamente definida, vários fluxos públicos e locais, código aberto e mitigação opcional. Essa posição também é exigente. A rede precisa de especialistas em roteamento, uma política mantida e capacidade de operar uma plataforma com vários componentes. O projeto provavelmente é mais adequado a organizações para as quais a proteção de roteamento é uma competência interna, e não apenas outra assinatura de painel.

A comparação não pode ser reduzida a uma tabela de funções. Diferentes modelos distribuem confiança e trabalho de maneiras distintas. Um serviço gerenciado centraliza conhecimento e observação. Um sistema operado pela própria rede mantém a política e a ação mais próximas da infraestrutura. A questão prática é qual lado consegue ver o suficiente, agir com segurança e continuar responsável quando as evidências são incompletas.

ARTEMIS Lite apareceu em materiais da comunidade RIPE em 2023 como uma abordagem relacionada e mais leve, destinada a reduzir parte do trabalho de implantação. A existência de uma versão Lite mostra que a amplitude da plataforma completa pode ser pesada para uma equipe pequena. Uma estrutura com vários contêineres, armazenamento persistente, múltiplos fluxos e mitigação própria faz sentido para um grande operador, mas pode ser excessiva para uma rede que inicialmente precisa apenas de visibilidade clara e alertas confiáveis.

Um sistema mais leve não deve ser considerado equivalente apenas por compartilhar nome e finalidade. O conjunto de pesquisa caracteriza ARTEMIS Lite como uma variante com funcionalidade reduzida, e as afirmações de apresentações exigem confirmação independente. A principal troca ocorre entre menor custo operacional e contexto, integrações, histórico ou mecanismos de resposta que podem estar ausentes. Uma implantação pequena ainda pode ser útil se declarar esses limites com clareza.

A adoção depende do tamanho da estrutura institucional exigida pela ferramenta. Um projeto pode ser tecnicamente aberto e, ainda assim, permanecer inacessível a operadores sem especialistas em contêineres, bancos de dados e segurança de roteamento. Empacotamento, configurações padrão razoáveis e um caminho gradual do monitoramento à detecção e à mitigação podem determinar se a arquitetura se difundirá além de um único artigo acadêmico.

O verdadeiro produto é um ciclo de resposta governado

ARTEMIS não torna o BGP confiável com uma única ação. Ele cria um ciclo em torno de um protocolo que originalmente não continha autorização completa. O operador descreve o roteamento desejado. Fluxos públicos e locais mostram parte do cenário real. O detector identifica a divergência. O armazenamento e as interfaces organizam as evidências. Pessoas ou uma automação autorizada escolhem a resposta, e os fluxos mostram se a propagação mudou. O incidente pode ser resolvido, considerado irrelevante, encerrado após a retirada da rota, escalado ou deixado sem ação com uma justificativa registrada.

Esse ciclo é a contribuição mais duradoura do projeto. Ele reconhece que a proteção de roteamento não se resume a um certificado isolado nem a um alerta distante. Trata-se de uma prática operacional na qual a política deve ser explícita, as observações devem preservar sua origem e a autoridade para responder precisa ser preparada antes da emergência. O valor do sistema está em reduzir a incerteza rápido o bastante para que a rede possa agir, não em fingir que a incerteza desapareceu.

As limitações são igualmente reveladoras. Coletores de rotas veem apenas parte do mundo. A referência pode ficar desatualizada. Evidências do plano de controle não comprovam motivo nem todas as consequências para o tráfego. Uma mitigação tecnicamente permitida pode ser filtrada ou causar danos. O código aberto ainda exige manutenção contínua. ARTEMIS é mais forte quando esses limites fazem parte do processo, em vez de ficarem ocultos por uma manchete sobre resposta em um minuto.

Uma anomalia BGP pode chegar ao centro de operações de rede, ao centro de operações de segurança ou a ambos. A equipe de roteamento entende prefixos, políticas de provedores e o risco de modificar anúncios. A equipe de segurança está mais preparada para correlacionar identidade, telemetria do serviço e possível atividade maliciosa. ARTEMIS cruza essas áreas. O benefício só aparece quando o alerta carrega evidências suficientes para que as duas equipes trabalhem sobre o mesmo evento, em vez de abrir investigações separadas com pressupostos iniciais diferentes.

A transferência do incidente deve separar observação, política e impacto. O sistema viu uma rota em fluxos especificamente identificados. A rota violou uma regra definida da referência. Verificações de serviço ou sondas RIPE Atlas mostraram um efeito concreto — ou o efeito ainda não foi estabelecido. O operador entrou em contato com a rede upstream ou com a origem da rota, e a resposta ainda é aguardada. Essa estrutura evita que o NOC descarte uma ameaça de segurança como roteamento normal e que o SOC classifique um anúncio não autorizado como ataque antes de estabelecer os fatos operacionais.

Uma linguagem comum também melhora a análise posterior. Um caso pode ser encerrado como mudança planejada não registrada na política, vazamento acidental de rota, suspeita de sequestro, evento malicioso confirmado ou anomalia não resolvida. Esses resultados devem voltar às regras, aos procedimentos e aos acordos com provedores. Sem esse ciclo, o detector corre o risco de se tornar uma máquina de criar chamados, não um sistema de melhoria dos controles de roteamento.

O alerta mais rápido nem sempre é o mais útil. O detector pode reagir à primeira atualização inesperada e depois descobrir que o fluxo estava atrasado, que a rota era planejada ou que a suposta vítima havia autorizado a nova origem. Por outro lado, esperar por todos os coletores e todos os testes do plano de dados eliminaria a vantagem da resposta antecipada. ARTEMIS precisa de uma medida entre o tempo bruto de detecção e o encerramento final: quanto tempo é necessário para reunir evidências confiáveis suficientes e permitir que um operador autorizado tome uma decisão defensável?

Essa medida pode ser decomposta. Com que rapidez chegou a primeira observação? Quantos fluxos independentes a confirmaram? A política relevante estava atualizada? RPKI ou BMP local acrescentaram evidências significativas? Quanto tempo levaram as verificações do serviço? Quando o responsável recebeu o alerta e quando a resposta foi aprovada? A mitigação produziu a propagação esperada e foi retirada com cuidado? Essas perguntas mostram onde a latência realmente reside, em vez de atribuir todo o resultado ao algoritmo de detecção.

A métrica da decisão defensável também impede uma otimização perigosa. O sistema não deve ser recompensado por agir mais rápido quando a ação se baseia em menos evidências ou cria uma mudança de roteamento desnecessária. A melhor implantação reduz simultaneamente a incerteza e o tempo de resposta, preservando um registro que possa ser verificado após o incidente.

Fontes

  • Site do projeto ARTEMIS
  • Arquitetura de código aberto de ARTEMIS no RIPE Labs
  • Repositório de código-fonte e documentação de ARTEMIS
  • “ARTEMIS: Neutralizing BGP Hijacking within a Minute”
  • Explicação operacional de ARTEMIS no RIPE Labs
  • Artigo de demonstração de ARTEMIS na ACM SIGCOMM 2016
  • Lançamentos de ARTEMIS
  • Relatório anual de 2019 da CAIDA
  • Fluxo de mensagens BGP RIPE RIS Live
  • RouteViews da Universidade do Oregon
  • CAIDA BGPStream
  • Repositório ExaBGP
  • Route Origin Validation, RFC 6811
  • Beneficiários do RIPE Community Projects Fund de 2019
  • Code BGP
  • Implantação experimental de ARTEMIS pela CAIDA
  • Demonstração ao vivo de ARTEMIS
  • BGP Monitoring Protocol, RFC 7854
  • RIPE Atlas