Resumo

  • A disponibilidade do RPKI é uma propriedade de ponta a ponta. Uma verificação de saúde do servidor pode estar verde enquanto os validadores externos recebem dados desatualizados, incompletos, inconsistentes ou criptograficamente inutilizáveis.
  • Uma interrupção curta não necessariamente altera a validação de roteamento, pois as partes usuárias armazenam em cache os objetos previamente validados. A mesma interrupção se torna crítica quando um manifesto ou lista de revogação de certificado excede seu campo nextUpdate, um certificado expira ou uma alteração necessária nunca se torna visível externamente.
  • Os incidentes públicos mostram classes de falhas distintas: a APNIC relatou uma inconsistência rsync enquanto o RRDP permanecia válido em 2019; o RIPE NCC relatou uma CRL expirada após uma falha de publicação silenciosa em 2020 e uma publicação inconsistente de certificado pai-filho em 2021; o JPNIC relatou que os ROAs se tornaram NotFound após a paralisação da publicação por tempo suficiente para que os campos de atualização expirassem em 2022.
  • Um compromisso de serviço crível deve medir as recuperações bem-sucedidas a partir de redes independentes, a completude por protocolo, a validade criptográfica, a margem de atualização, as mudanças na carga útil validada, a convergência de recuperação e qualquer alteração associada na validação de roteamento observada.
  • A atribuição exige um registro cronológico desde a mudança autorizada até a produção do certificado, a publicação, a recuperação externa, a validação, a entrega ao roteador e a política de roteamento. Sem essa cadeia, um registro, um repositório, um fornecedor de software e um operador de rede podem cada um apontar para outra camada.
  • O impacto no roteamento não pode ser deduzido apenas da falha do repositório. Os operadores escolhem sua política local, usam diferentes softwares e intervalos de atualização, e veem diferentes caminhos BGP. Os relatórios devem indicar a população observada e manter as incógnitas em vez de reivindicar uma taxa de falha universal.
  • A NRS pode fortalecer a legitimidade dos registros ao patrocinar sondas neutras, campos de incidentes comuns e um padrão de garantia reproduzível externamente. Sua contribuição positiva seria tornar testáveis as afirmações institucionais limitadas, não declarar que toda interrupção de repositório causou perda de clientes.

Uma falha começa na parte usuária, não na sala de servidores

O evento determinante do RPKI não é uma luz vermelha no console do operador do repositório. É a incapacidade de uma parte usuária externa recuperar e validar os dados nos quais uma rede conta para basear suas decisões de origem de rota. Os dois eventos podem coincidir, mas não são idênticos.

Um operador de repositório pode observar processos saudáveis, sockets abertos e requisições locais bem-sucedidas enquanto usuários em outros lugares encontram falha de DNS, um nó de distribuição de conteúdo quebrado, uma incompatibilidade TLS, uma árvore rsync incompleta, uma inconsistência de sessão RRDP ou um conjunto de objetos cujas assinaturas não formam mais um caminho válido. Inversamente, um repositório pode ficar inacessível por várias horas sem alterar a visão validada já detida pelos operadores, desde que o material em cache permaneça utilizável e nenhuma atualização urgente seja perdida.

Essa distinção é mais do que uma pontuação técnica. Os documentos de política frequentemente usam a disponibilidade como se fosse uma propriedade de uma máquina: minutos de funcionamento divididos por minutos em um mês. O RPKI é um serviço de publicação integrado a uma decisão de segurança distribuída. Sua produção útil é um conjunto validado de assertivas, não uma página web que responde. Uma medida que para na borda do repositório mede, portanto, a capacidade do operador de se servir a si mesmo, não a capacidade da parte usuária de confiar nele.

A pergunta correta é observável externamente: em um dado momento, a partir de uma rede dada, usando um protocolo e uma versão de validador dados, uma parte usuária conseguia recuperar o material completo necessário para um caminho de certificação dado, validá-lo de acordo com os padrões aplicáveis e produzir as cargas úteis validadas esperadas antes que as margens de atualização se esgotassem?

Essa pergunta é mais longa do que "o servidor estava online?" porque o serviço é mais longo. Ela também distribui as responsabilidades de forma mais justa. Ela pode mostrar uma falha no lado do repositório, um problema de acessibilidade específico ao caminho, um defeito de validador, um cache local desatualizado ou um atraso na entrega ao roteador sem pretender que todos os cinco são um único evento.

A publicação RPKI é uma cadeia de dependências temporais

O RPKI dá aos operadores um meio de avaliar se um sistema autônomo está autorizado a anunciar um prefixo. Um detentor de recursos cria uma autorização de origem de rota. Os certificados ligam os recursos digitais pertinentes em um caminho de certificação. Os repositórios publicam certificados, ROAs, manifestos e listas de revogação de certificados. O software da parte usuária recupera e valida esses objetos, produz cargas úteis validadas e as fornece aos sistemas de roteamento, geralmente via protocolo RPKI-to-Router. O roteador aplica uma política local aos anúncios BGP classificados como Valid, Invalid ou NotFound.

Cada verbo dessa sequência tem sua própria fronteira de falha. Um detentor pode submeter uma origem ou comprimento máximo errado. Um serviço de certificação pode emitir um certificado inconsistente. Um serviço de publicação pode não expor uma alteração concluída. Um protocolo de acesso pode funcionar enquanto outro falha. Uma parte usuária pode rejeitar demais, reter muito pouco ou se atualizar muito lentamente. Uma sessão RTR pode parar de transportar um conjunto atualizado. Um roteador pode receber o conjunto e aplicar uma política inesperada. Uma rota pode ser filtrada por uma rede e aceita por outra.

O repositório é central porque todas as partes usuárias precisam de uma visão de publicação recuperável, mas não é um roteador e não comanda uma resposta universal. A RFC 7115 torna a política de roteamento local. Isso limita o que um relatório de repositório pode honestamente afirmar. Ele pode estabelecer que objetos estavam indisponíveis ou inválidos, que certas cargas úteis validadas desapareceram sob um software definido e que rotas observadas mudaram de estado em pontos de observação selecionados. Ele não pode deduzir desses fatos apenas a política de cada operador ou a acessibilidade de cada cliente.

O tempo liga as camadas. Uma interrupção de dez minutos com ampla margem de atualização difere de uma interrupção de dez minutos que ultrapassa o nextUpdate de um manifesto. Um novo ROA atrasado difere do desaparecimento de um ROA previamente válido. Um cache que protege a continuidade para um validador pode estar ausente ou já próximo da expiração para outro. A qualidade de serviço deve, portanto, ser expressa como uma sequência de provas temporais, não como uma duração única.

O tempo de funcionamento interno é necessário e radicalmente insuficiente

O monitoramento de disponibilidade convencional pergunta se um host ou aplicação responde. Isso ainda é útil. Um operador precisa saber se os servidores de origem, armazenamento, serviços de assinatura, trabalhadores de publicação, DNS, terminação TLS e nós de distribuição estão saudáveis. Mas um controle interno tem três pontos cegos estruturais.

Primeiro, ele geralmente começa dentro ou perto da rede do provedor. Ele pode contornar o resolvedor DNS, o caminho de peering, a família de endereços, o nó de distribuição de conteúdo ou o controle de acesso encontrados por um validador externo. Uma requisição bem-sucedida a partir da mesma instalação prova pouco sobre a acessibilidade a partir da África, Ásia, Europa ou Américas.

Segundo, ele tende a testar o transporte em vez do significado. Um código HTTP 200 pode entregar um arquivo de notificação RRDP antigo. Um daemon rsync pode responder enquanto expõe uma árvore parcialmente atualizada. Um arquivo pode estar presente mas ausente do manifesto atual, listado com um hash errado, assinado sob uma cadeia inválida ou associado a uma CRL expirada. O servidor está vivo; a assertiva é inutilizável.

Terceiro, o monitoramento interno frequentemente sabe que uma ação de publicação foi tentada, mas não se usuários independentes a receberam. Uma fila pode marcar uma tarefa como concluída quando os dados alcançaram um diretório de origem, mesmo que uma camada de distribuição tenha mantido a visão anterior. A diferença entre uma publicação tentada e uma publicação visível externamente é precisamente onde um serviço de garantia deve olhar.

Um padrão reproduzível externamente não rejeita a telemetria do provedor. Ela a coloca no lugar certo. As evidências internas explicam a causa e aceleram o reparo. As evidências externas estabelecem o estado visível pelo usuário. O compromisso de serviço deve exigir ambas e especificar como os desacordos são resolvidos. Se os controles internos dizem "saudável" enquanto vários validadores externos falham semanticamente, o serviço está degradado até que a discrepância seja explicada.

Os caches transformam uma simples falha em uma corrida contra o relógio criptográfico

O RPKI foi projetado com cache local porque os repositórios e caminhos de rede não podem ser considerados permanentemente acessíveis. A RFC 8182 aconselha as partes usuárias a reter objetos antigos, e a RFC 9286 recomenda continuar usando objetos em cache associados a uma recuperação falhada até que se tornem obsoletos ou possam ser substituídos com sucesso. Esta é uma importante funcionalidade de continuidade. É também por que o tempo de inatividade bruto é uma má descrição do risco.

No início de uma interrupção, duas partes usuárias podem deter estados de cache diferentes mas válidos. Uma se atualizou momentos antes; a outra está se aproximando de sua próxima recuperação programada. Suas margens de atualização restantes diferem. Se o repositório se recupera rapidamente, ambas podem continuar produzindo as mesmas cargas úteis validadas. Se a recuperação chega após os limites temporais pertinentes, uma pode perder objetos antes da outra. Uma terceira implementação pode seguir uma política local diferente para material obsoleto.

O incidente tem, portanto, pelo menos três relógios. O primeiro mede a falha de recuperação externa. O segundo mede a margem de atualização para cada ramo de certificação afetado. O terceiro mede quando a saída validada realmente muda. Os relatórios de política geralmente publicam apenas o primeiro, se é que publicam algum. No entanto, o segundo identifica a urgência e o terceiro a consequência para o serviço de segurança.

O cache também pode mascarar uma atualização falhada. Objetos existentes permanecem válidos, então a validação geral parece estável, mas uma correção recém-criada por um detentor está ausente. Se a mudança faltante deveria autorizar uma migração ou reparar um estado Invalid acidental, a continuidade do material antigo não significa que o serviço estava disponível para o detentor afetado. A disponibilidade de leitura e a disponibilidade de publicação de mudanças precisam de medidas separadas.

Um relatório sensato traça esses relógios juntos. Ele indica quando as recuperações independentes falharam primeiro, o tempo mínimo observado até a expiração ou obsolescência pertinente, quando as mudanças esperadas pararam de aparecer, quando os validadores mudaram de saída e quando uma parcela definida de sondas convergiu para a recuperação. Essa narrativa mostra se a resiliência do cache funcionou e o quão perto o sistema chegou de uma consequência mais grave.

Os manifestos e listas de revogação tornam a disponibilidade semântica testável

Um repositório RPKI não é simplesmente um diretório de arquivos assinados. Os manifestos enumeram os objetos assinados associados a uma autoridade certificadora e incluem hashes. Eles ajudam as partes usuárias a detectar remoção, substituição e visões incompletas. As listas de revogação de certificados identificam certificados revogados. Seus campos temporais criam expectativas visíveis externamente quanto à atualização.

A RFC 9286 fornece uma base incomumente útil para a medição de serviço. Uma parte usuária deve recuperar o manifesto identificado pelo certificado, verificar se o tempo atual cai dentro do intervalo do manifesto, adquirir cada arquivo listado e verificar cada hash. Um manifesto inválido ou obsoleto, um arquivo listado ausente ou uma incompatibilidade de hash é uma recuperação falhada. A parte usuária deve continuar usando as versões em cache apropriadas até que se tornem obsoletas ou uma recuperação bem-sucedida as substitua.

Isso significa que um observador externo não precisa confiar na declaração do operador de que a publicação estava completa. O observador pode testar o inventário assinado em relação aos arquivos recuperados. Ele pode registrar a autoridade certificadora exata onde a validação parou, o motivo, o protocolo e a margem de cache restante. Repetir esse teste a partir de redes independentes cria um histórico de disponibilidade verificável.

O mesmo método evita o exagero. Um ramo falhado não invalida automaticamente ramos não relacionados. Um ponto de publicação delegado indisponível não deve ser relatado como evidência de que cada objeto sob uma âncora de confiança regional desapareceu. Os resultados devem ser limitados à autoridade, objetos e validadores afetados. Rótulos muito amplos obscurecem tanto a engenharia quanto a responsabilidade.

A medição semântica também impede o erro inverso: tratar um ponto de acesso acessível como um repositório saudável quando os campos temporais ou a consistência dos objetos já falharam. No RPKI, as verificações de integridade fazem parte da disponibilidade porque um arquivo no qual não se pode confiar com segurança não é o serviço prometido.

A interrupção do JPNIC em 2020 mostra por que o tempo de inatividade decorrido não é o impacto

O JPNIC relatou que seu ROAWeb e repositório RPKI estavam indisponíveis de 15 de maio às 23h29 a 16 de maio de 2020 às 10h01, horário do Japão, após uma falha de energia relacionada a hardware. Os usuários não podiam criar ou excluir ROAs, e partes externas não podiam baixar certificados, ROAs e outros arquivos. Foi manifestamente uma interrupção de serviço.

No entanto, o JPNIC também relatou que os resultados de validação baseados nos ROAs previamente baixados não haviam mudado porque a expiração dos certificados e os valores nextUpdate da CRL e do manifesto não haviam sido ultrapassados. Essa é a distinção que um compromisso de serviço externo deve preservar. O ponto de publicação falhou por cerca de dez horas e meia, mas a função de validação em cache descrita no aviso continuou para os objetos e usuários nas condições indicadas.

O evento ainda teve importância. Os detentores perderam temporariamente a capacidade de fazer alterações. Uma nova autorização ou revogação necessária não pôde ser realizada. Validadores sem o cache anterior pertinente, ou com uma condição local diferente, podem não ter se beneficiado da mesma continuidade. O aviso público não estabeleceu o estado de cada parte usuária nem a acessibilidade de cada rota. Ele estabeleceu uma afirmação limitada, tecnicamente significativa, sobre o conteúdo publicado inalterado e os prazos de atualização não esgotados.

Isso é melhor do que qualificar o evento como inofensivo ou catastrófico. Uma métrica bem projetada relataria uma indisponibilidade separada para ações de gerenciamento e recuperações de publicação, e depois uma mudança nula observada na saída validada entre os estados de cache testados. Ela divulgaria as sondas, os ramos de objetos e os validadores usados para chegar a essa conclusão.

A lição é positiva. O tempo criptográfico e o cache podem absorver uma falha de repositório como projetado. A política deve recompensar essa resiliência enquanto registra o serviço de mudança negado. Um provedor não deve perder crédito de disponibilidade pela continuidade de roteamento, nem receber crédito completo enquanto os detentores não podiam emitir uma atualização necessária.

O evento de 2019 da APNIC mostra por que cada protocolo de acesso precisa de seu próprio resultado

O anúncio de serviço da APNIC para 13 de dezembro de 2019 descreve uma falha parcial de vinte minutos do RPKI. O estado do repositório rsync estava incompleto e um manifesto desatualizado e revogado foi publicado, tornando um certo número de certificados e ROAs inválidos. Validadores usando o RRDP não foram afetados e continuaram vendo validade completa.

Um incidente, portanto, produziu duas realidades externas materialmente diferentes. Um monitor que testava apenas o RRDP teria declarado sucesso. Um monitor que testava apenas rsync teria constatado uma falha semântica. Um agregado no nível do servidor poderia ter calculado a média dos dois em uma porcentagem tranquilizadora enquanto escondia que os usuários de um método padronizado recebiam uma visão inutilizável.

A diversidade de protocolos só pode fornecer resiliência se as medidas mantiverem a distinção. Os indicadores relevantes incluem a recuperação de notificação RRDP, a integridade de snapshots e deltas, o progresso de sessão e série, a acessibilidade rsync, a completude da árvore e se o failover ocorreu quando o método preferido falhou. Um provedor também deve divulgar se ambos os métodos compartilham uma origem, sistema de armazenamento, caminho de rede ou processo de atualização, pois métodos de acesso nominalmente separados podem ter um modo de falha comum.

O comportamento da parte usuária pertence ao relato. A RFC 8182 permite mecanismos de acesso alternativos quando o RRDP tem problemas, mas um failover configurado ou implementado não é garantido de funcionar em cada implantação. O estudo de 2020 sobre partes usuárias encontrou comportamento de recuperação inconsistente em suas condições experimentais. Esses resultados vieram de um conjunto limitado de autoridades certificadoras e testes observados; eles não constituem um denominador para todos os validadores atuais.

Eles mostram por que os operadores de publicação devem testar o comportamento real dos clientes em vez de deduzi-lo do design do protocolo.

Um compromisso externo nunca deve publicar um único número de disponibilidade do RPKI sem uma discriminação por protocolo. Se um método fornece uma visão válida completa e outro não, o serviço é resiliente para alguns usuários e degradado para outros. Ambos os fatos pertencem ao título.

A falha de 2020 do RIPE NCC mostra o perigo de um silêncio de publicação

Em fevereiro de 2020, o RIPE NCC relatou que um problema de disco impediu que ROAs recém-criados, modificados ou excluídos alcançassem seu servidor de publicação. O aviso identificou 176 dessas mudanças. As informações afetadas eram mantidas em outro lugar, mas a publicação não ocorreu e o disco não sinalizou um problema que alertaria os engenheiros.

Isso já era uma falha antes da expiração de qualquer objeto criptográfico. A ação do lado do detentor e o estado visível externamente haviam divergido. Um usuário podia razoavelmente acreditar que uma mudança havia sido aceita enquanto as partes usuárias continuavam recuperando o estado antigo. O serviço falhou no nível da confirmação de publicação mesmo que os arquivos ainda estivessem sendo servidos.

O evento então cruzou uma segunda fronteira. O RIPE NCC relatou que a CRL havia expirado, após o que os objetos subjacentes também expiraram. A condição anormal apareceu de forma diferente dependendo do software da parte usuária. O reparo exigiu mais do que resolver o problema do disco; a organização acabou realizando uma rotação completa da chave da autoridade certificadora antes da resolução.

O tempo de funcionamento tradicional perde tanto a fase silenciosa quanto o precipício semântico. Um teste reproduzível externamente teria comparado uma referência de mudança aceita assinada ou de outra forma verificável com a publicação observada, acompanhado a margem de atualização da CRL e acionado um alarme quando a visão do repositório não avançava mais. Validadores independentes mostrariam então como o ramo expirado afeta a saída sob versões nomeadas.

O incidente também demonstra por que a descoberta de estado faz parte da qualidade de serviço. A falha começou em um sábado, a CRL se tornou obsoleta no domingo e a organização disse ter sido notificada na segunda-feira. Um repositório pode ser monitorado continuamente e ainda ser operacionalmente cego se seus controles não verificarem se o novo estado autoritário está presente externamente.

A política deve perguntar não apenas a rapidez com que os engenheiros corrigiram um evento conhecido, mas por quanto tempo o serviço esteve errado antes que alguém soubesse. O tempo médio de detecção externa é um indicador RPKI de primeira ordem.

O incidente de 2021 do RIPE NCC mostra que a completude pode falhar apenas para alguns validadores

Em 7 de janeiro de 2021, uma transferência de recursos de saída levou o sistema do RIPE NCC a publicar um certificado pai atualizado antes do certificado filho associado. Durante o intervalo inconsistente, o filho reivindicava recursos que não estavam mais presentes no pai. A organização relatou que implementações mais antigas da parte usuária usando uma interpretação estrita do manifesto rejeitavam todos os certificados listados no manifesto quando uma entrada era inválida.

O mesmo estado publicado, portanto, produziu resultados diferentes dependendo da versão do software. O RIPE NCC estimou a partir dos logs de acesso que 327 instâncias de parte usuária foram afetadas e alertou que o incidente poderia ter causado falhas aclientes. Não afirmou que 327 redes perderam acessibilidade, muito menos que cada rota sob a âncora de confiança falhou. Essa contenção é importante: um número de instâncias não é um número de redes, e certificados rejeitados não são um denominador universal de impacto ao cliente.

O evento expõe uma fraqueza nos relatórios de política que usam um único validador de referência. A conformidade evolui. As implementações interpretam de forma diferente os casos difíceis, bugs são corrigidos e os operadores atualizam em velocidades diferentes. Um repositório pode ser bem-sucedido com a implementação mais recente enquanto cria consequências graves para uma população mais antiga implantada.

A garantia externa deve manter um painel de compatibilidade divulgado dos validadores suportados e materialmente implantados. Ela deve registrar as diferenças de saída no nível do ramo de certificação e da carga útil validada. O painel não é um voto sobre a conformidade com os padrões; uma implementação não conforme deve ser identificada como tal. É uma medida da exposição operacional previsível enquanto as atualizações se propagam.

As soluções propostas pelo RIPE NCC também apontam para a métrica correta. Ele buscou uma publicação atômica e janelas de inconsistência mais curtas. O objetivo do serviço deve medir a atomicidade observada externamente: nenhuma sonda deve recuperar um estado pai e um estado filho que não possam ser validados juntos. Isso é mais significativo do que medir a rapidez com que duas tarefas de atualização internas terminaram.

O evento de 2022 do JPNIC mostra a conversão retardada de Valid para NotFound

O aviso de fevereiro de 2022 do JPNIC relatou que um log de acesso crescente encheu o disco do servidor de repositório entre 26 de janeiro e 2 de fevereiro. O processo de publicação não conseguia atualizar os campos nextUpdate nas CRLs ou manifestos. Uma vez que esses campos foram ultrapassados, os ROAs associados não podiam mais ser validados pelos clientes, e as rotas que cobriam foram detectadas como NotFound.

Essa sequência é importante. O serviço não moveu necessariamente as rotas diretamente de Valid para Invalid. Ele removeu as provas de autorização utilizáveis, produzindo NotFound para a visão de validação afetada. Muitas políticas operacionais aceitam NotFound, frequentemente com uma preferência diferente de Valid. A consequência de segurança pode ser uma perda de proteção em vez de uma perda imediata de acessibilidade. Um relatório que qualifica cada ROA desaparecido como uma falha de roteamento confunde esses resultados.

O evento durou tempo suficiente para que a continuidade do cache se esgotasse. Uma medida de disponibilidade baseada apenas em uma conexão TCP bem-sucedida teria sido particularmente enganosa se o servidor ainda respondesse enquanto a atualização da publicação havia parado. O alarme útil era o tempo decrescente até o nextUpdate combinado com a ausência de observação de um novo manifesto e nova CRL.

O JPNIC também disse que um usuário competente relatou o problema. Esse fato apoia uma reforma institucional: monitores independentes devem ter um canal definido, autenticado e com pessoal contínuo para as operações do repositório. A descoberta externa não deve depender de um especialista notar uma anomalia e encontrar o contato certo.

Um relatório para essa classe de evento deve quantificar, no conjunto medido, quando cada ROA afetado parou de produzir uma carga útil validada, quais rotas passaram de Valid para NotFound em pontos de observação BGP selecionados, e se operadores relataram consequências de política ou para clientes. Se os dados do cliente não estiverem disponíveis, eles devem permanecer indisponíveis em vez de serem inferidos do número de ROAs.

A degradação de 2022 da ARIN mostra o valor e os limites da redundância de transporte

A ARIN relatou uma degradação de serviço RRDP de noventa minutos em 11 de agosto de 2022 após uma mudança de configuração instalar certificados discordantes em alguns nós de serviço. A organização removeu os nós afetados da rotação DNS, restaurou os certificados correspondentes e reiniciou a geração do repositório. Seu serviço rsync permaneceu funcional durante todo o período, enquanto a publicação de seis ROAs foi atrasada.

Este é um caso útil de resiliência parcial. O método de publicação alternativo permaneceu disponível, e o provedor deu um número limitado de mudanças atrasadas. Mas não se segue que cada parte usuária obteve essas mudanças por failover. Os operadores podem preferir o RRDP, aplicar agendas de novas tentativas, não ter failover funcional ou ter caminhos de rede que alcançam um serviço de forma diferente de outro.

O painel correto mostraria a recuperação bem-sucedida por protocolo e ponto de observação, as tentativas e resultados de failover, o atraso de publicação para os seis ROAs afetados e a convergência da saída validada após o reparo. Ele também distinguiria o estado existente do repositório público da pausa temporária na geração de novo estado. A disponibilidade para um operador com um cache atual não era idêntica à disponibilidade para um detentor aguardando um dos ROAs atrasados.

A redundância só merece crédito quando é exercida independentemente. Duas URLs servidas pelo mesmo pool de nós mal configurados não são dois controles. O RRDP e rsync com modos de falha separados podem melhorar a continuidade, mas o provedor deve provar que os validadores podem usar o caminho sobrevivente antes da expiração da atualização. Exercícios planejados, como uma retirada controlada de um método, podem revelar se o failover funciona sem esperar uma emergência.

É aqui que os testes externos superam os diagramas arquiteturais. Eles mostram o caminho que os clientes realmente percorreram, a visão que realmente validaram e o momento em que as afirmações atrasadas se tornaram úteis.

Um compromisso de serviço de repositório requer quatro objetivos de serviço distintos

O primeiro objetivo é a disponibilidade de recuperação. A partir de pontos de observação independentes, uma parte usuária consegue resolver o nome do repositório, conectar-se via família de endereços suportada, negociar o transporte necessário e recuperar o material RRDP ou rsync? Os resultados devem ser divididos por protocolo, versão IP, região e provedor de rede. Uma média mensal não deve esconder uma falha completa para uma combinação.

O segundo é a disponibilidade semântica. A visão recuperada contém um manifesto válido atual, os objetos listados com hashes correspondentes, uma CRL utilizável e um caminho de certificação válido? O validador consegue produzir o conjunto de cargas úteis esperado sem rejeitar um ramo não relacionado? Este objetivo converte a correção criptográfica em indicador de serviço.

O terceiro é a pontualidade da publicação. Após uma ação autorizada ser aceita, quanto tempo leva para que sondas independentes observem o novo objeto e produzam a mudança de carga útil correspondente? Este objetivo cobre criação, modificação, revogação, transferência e correção de emergência. Ele requer uma referência que preserve a privacidade e permita que um auditor associe a ação à publicação sem expor segredos de conta.

O quarto é a convergência de recuperação. Após um reparo, quanto tempo leva para que um painel definido de validadores independentes alcance a mesma visão atual e os sistemas de roteamento a recebam? Um repositório que é corrigido na origem mas permanece desatualizado nos nós de distribuição não se recuperou totalmente. Tampouco um repositório cujos arquivos estão atualizados enquanto as sessões RTR ainda fornecem um conjunto antigo de cargas úteis.

Cada objetivo precisa de um denominador explícito. A recuperação pode usar tentativas de sonda programadas. A disponibilidade semântica pode usar os ramos de certificação supostamente atuais. A pontualidade da publicação pode usar as ações aceitas elegíveis para publicação imediata. A recuperação pode usar sondas ativas com um estado pré-incidente conhecido. Misturar essas populações produz uma porcentagem atraente mas sem sentido.

O modelo de quatro objetivos também suporta uma atribuição justa. Um repositório pode satisfazer a recuperação enquanto falha na integridade semântica, ou satisfazer ambas enquanto uma mudança solicitada por um detentor permanece errada. Operadores e órgãos de supervisão podem ver exatamente qual promessa falhou.

Sondas independentes devem ser diversas o suficiente para desafiar as suposições do provedor

Uma rede de medição neutra deve incluir sondas em várias regiões e sistemas autônomos, usando tanto IPv4 quanto IPv6 onde oferecido. Deve evitar concentrar todas as sondas em uma única nuvem cujo caminho ou resolvedor pode falhar como uma unidade. O número e a localização não devem pretender representar cada usuário da internet; devem ser divulgados para que os leitores entendam a população observada.

Cada sonda deve usar um relógio controlado, registrar respostas DNS, endereço de destino, temporização de transporte, resposta do protocolo, hashes de objetos, nome e versão do validador, material de âncora de confiança, estado do cache e resumo final da carga útil validada. Detalhes operacionais sensíveis podem ser protegidos, mas evidências suficientes devem ser publicadas para que outra parte qualificada possa repetir o teste.

Os modos cache frio e cache quente são ambos necessários. Um validador frio mostra se uma nova parte usuária pode construir a visão. Um validador quente mostra se um operador estabelecido pode continuar através de uma falha. Testar apenas instâncias frias exagera a perda imediata; testar apenas instâncias quentes esconde o risco de integração e esgotamento do cache.

As sondas devem recuperar em intervalos realistas, respeitando a capacidade do repositório. Um sistema de medição que sobrecarrega o serviço cria a condição que pretende observar. Provedores e pesquisadores podem concordar com limites de taxa e uma identificação dedicada sem dar ao provedor um caminho que contorna a distribuição ordinária.

Falsos alarmes exigem gerenciamento disciplinado. Uma falha de sonda única pode vir de seu resolvedor, relógio local, disco, validador ou caminho upstream. A declaração de incidente deve usar uma regra pré-anunciada, como uma falha semântica em um número mínimo de redes independentes ou confirmação do provedor. Falhas localizadas ainda pertencem aos dados, mas nem todas se tornam um aviso global.

O padrão deve publicar o código da sonda, vetores de teste e definições de resultados. A reproduzibilidade vem de um método compartilhado e observações assinadas, não do prestígio institucional.

A margem de atualização é o indicador de risco que um painel verde não pode fornecer

A qualquer momento, um ramo de repositório tem um intervalo restante antes que um manifesto ou CRL pertinente se torne obsoleto ou um certificado expire. Esse intervalo é sua margem de atualização. Ele converte um problema de recuperação comum em uma medida de risco operacional.

Suponha que sondas externas falhem em recuperar um ramo enquanto seu manifesto atual ainda tem dezoito horas. O evento merece atenção, mas os validadores em cache têm margem para continuar. Se a margem cair para uma hora sem recuperação, a mesma condição de transporte se torna urgente. Se uma nova revogação necessária também está pendente, o risco de segurança já pode ser alto apesar dos objetos antigos não expirados.

O provedor deve relatar a margem mínima, mediana e a distribuição da margem sobre os ramos afetados, não apenas o mínimo em todo o repositório. Uma autoridade delegada com um intervalo incomumente curto não deve ser usada para sugerir que cada ramo está próximo da falha. Da mesma forma, um certificado pai de longa duração não deve mascarar um manifesto filho próximo da obsolescência.

A margem suporta um alerta de taxa de consumo. Se um evento consome a margem de atualização mais rápido do que a confiança de reparo aumenta, a escalada deve ocorrer antes da expiração. Isso é análogo à gestão de uma reserva: o serviço ainda não falhou semanticamente, mas sua capacidade de absorver atraso está diminuindo.

A temporização dos objetos não é o risco inteiro. Um detentor aguardando uma nova autorização pode ter uma margem prática zero porque uma migração de rede está em andamento. O arquivo de incidente deve permitir que detentores afetados marquem uma mudança esperada urgente, com provas e revisão, sem expor publicamente planos comerciais confidenciais.

Um relatório de política que publica a margem explica por que uma falha de dez horas não teve alteração de validação enquanto outra falha de publicação de vários dias teve. Ele dá aos conselhos e operadores uma linguagem comum para a urgência que o tempo de funcionamento bruto não pode fornecer.

A atribuição requer uma sequência compartilhada da ação autorizada ao efeito na rota

Quando um incidente RPKI se torna litigioso, cada entidade vê apenas uma parte da sequência. O detentor sabe o que solicitou. O serviço de certificação sabe o que aceitou e assinou. O repositório sabe o que serviu. A parte usuária sabe o que recuperou e rejeitou. O roteador sabe qual conjunto de cargas úteis e política usou. O cliente sabe que um serviço se tornou inacessível. Sem tempos correlacionados, a responsabilidade se torna uma afirmação.

Um arquivo de incidente comum deve atribuir uma referência estável a cada ação material e registrar seis marcos: autorização aceita, objeto produzido, objeto publicado externamente, objeto recuperado e validado, carga útil entregue a um roteador, e decisão de roteamento pertinente observada. Cada marco deve identificar a instituição responsável e a fonte do relógio. Relatórios públicos podem hash ou agregar referências sensíveis enquanto preservam a sequência para revisão independente.

Este método distingue um objeto errado de um objeto indisponível. Se o detentor solicitou um comprimento máximo errado e o serviço fielmente o publicou, a responsabilidade difere de um defeito de código que produziu um certificado inconsistente com o estado de registro. Se o repositório publicou um objeto correto mas um validador desatualizado rejeitou um ramo mais amplo, o provedor ainda tem deveres de compatibilidade e comunicação, mas a causa técnica direta é diferente.

A atribuição também precisa de testes contrafactuais. Os investigadores podem reproduzir o conjunto de objetos observado através de validadores nomeados e comparar as cargas úteis resultantes, depois aplicar a política de rota declarada do operador aos anúncios BGP capturados. Isso não reconstrói cada pacote ou transação perdida. Testa se a cadeia alegada é tecnicamente possível e onde o estado primeiro divergiu.

Nenhuma instituição deve controlar a única cópia dessas provas. Provedores podem assinar os registros de marcos; monitores neutros podem assinar observações externas; operadores podem manter o histórico RTR e de política de roteamento. Provas compartilhadas tornam possível uma responsabilidade restrita, o que é mais justo que a culpa generalizada e a imunidade generalizada.

O impacto no roteamento deve ser medido, não presumido a partir do número de objetos

Um incidente de repositório pode mudar a segurança do roteamento sem mudar a acessibilidade. Quando um ROA válido desaparece da visão utilizável, um anúncio pode se tornar NotFound e permanecer aceito. A proteção contra uma origem não autorizada pode enfraquecer, mas a rota legítima ainda pode funcionar. Quando um certificado inconsistente faz desaparecer uma autorização válida enquanto outro ROA coberto permanece, o estado da rota pode não mudar nada. Quando um ROA errado torna um anúncio legítimo Invalid, operadores que rejeitam rotas Invalid podem retirar a acessibilidade enquanto outros continuam a aceitá-lo.

O estudo de impacto começa, portanto, pelas diferenças de carga útil validada. Quais tuplas de prefixo, comprimento máximo e origem foram adicionadas ou removidas sob cada validador? O próximo passo junta essas diferenças aos anúncios BGP observados nos coletores nomeados ou fluxos dos operadores. O passo técnico final aplica as suposições de política divulgadas ou, quando disponíveis, a política real do operador.

O impacto ao cliente requer evidências separadas: alarmes, perda de tráfego, sessões falhadas, relatórios de suporte ou violações de nível de serviço. Os coletores de rotas não veem cada caminho de peering privado, e uma mudança de estado de validação não revela quanto tráfego o usava. Os relatórios devem evitar traduzir prefixos em usuários ou receitas sem dados fornecidos pelas redes afetadas.

A mesma disciplina protege os provedores contra alegações infladas. Um incidente que tornou um ramo temporariamente NotFound não deve ser descrito como prova de que a internet regional está offline. Ela também protege os operadores contra a minimização. Se várias redes independentes registraram a rejeição de uma rota Invalid e o tráfego caiu ao mesmo tempo, uma declaração de que o host do repositório permanecia acessível é irrelevante.

O produto apropriado é uma tabela de impacto estratificada: objetos de publicação afetados, cargas úteis validadas afetadas, anúncios observados afetados, redes com resposta política atestada, e clientes ou serviços com consequência documentada. As células desconhecidas permanecem desconhecidas.

Os denominadores devem ser locais, divulgados e resistentes ao reuso promocional

A medição RPKI atrai números impressionantes porque o sistema é de escala global. Mas nenhum observador público tem um censo completo de instâncias de partes usuárias, versões de software, históricos de cache, políticas de roteamento, caminhos BGP privados ou efeitos em clientes finais. Um compromisso de serviço crível não fabrica esse denominador.

Cada taxa deve portar sua população observada. A disponibilidade de sondas é o número de verificações bem-sucedidas dividido pelas verificações programadas do conjunto de sondas nomeado. A compatibilidade do validador é o número de saídas bem-sucedidas dividido pelas versões e casos de teste do painel. A pontualidade da publicação é o número de ações observadas no prazo dividido pelas ações aceitas elegíveis no período do relatório. O efeito nas rotas é o número de anúncios alterados dividido pelos anúncios visíveis nos coletores nomeados. Nenhum é "a porcentagem da internet afetada".

O estudo de 2020 sobre partes usuárias da IMC é valioso precisamente quando é delimitado. Ele observou clientes alcançando três autoridades certificadoras e usou condições controladas para expor recuperações inconsistentes. As proporções relatadas descrevem esse experimento, não cada operador atual ou cada versão futura. Relatórios de política devem preservar esses limites ao citar pesquisas.

As contagens específicas de incidentes exigem contenção similar. A estimativa do RIPE NCC de 327 instâncias de partes usuárias afetadas em janeiro de 2021 veio de logs de acesso e um comportamento de software definido. As instâncias podem compartilhar uma rede, servir várias redes ou ser sistemas de teste. O número é uma evidência de exposição operacional, não uma contagem de organizações desconectadas.

Uma boa medida ainda pode ser impactante. Ela pode dizer que cada sonda em cinco redes independentes rejeitou o mesmo ramo, que os três validadores atuais testados perderam as mesmas cargas úteis, ou que uma rota nomeada desapareceu em dois coletores. A precisão fortalece a responsabilidade porque a afirmação pode ser reproduzida e contestada.

Relatórios de incidente devem separar causa, condição, consequência e confiança

A causa é a falha inicial: disco cheio, publicação mal ordenada, certificados discordantes, perda de energia ou defeito de software. A condição é o que os usuários externos encontraram: falha de recuperação, manifesto desatualizado, árvore rsync incompleta, caminho de certificação inconsistente ou mudança atrasada. A consequência é a saída observada: remoção de carga útil, mudança de estado, rota rejeitada ou interrupção do cliente. A confiança indica com que força as evidências as ligam.

Muitos avisos colapsam essas camadas em uma única frase. Isso cria confusão quando evidências posteriores mudam. Um provedor pode conhecer a condição antes de conhecer a causa. Um operador pode provar uma consequência em uma rota antes que o provedor reproduza o caminho externo. Relatar as camadas separadamente permite que o relato público melhore sem apagar a observação original.

O aviso deve incluir definições precisas de início e fim. O início pode ser a primeira falha de verificação semântica externa, não o momento em que um engenheiro abriu um incidente. O fim pode exigir validação bem-sucedida por um quórum de sondas e a publicação das mudanças atrasadas, não simplesmente a reinicialização de um processo. Os tempos de detecção, reconhecimento, mitigação e convergência completa devem todos ser visíveis.

A confiança pode ser graduada de acordo com a evidência: confirmada por reprodução de objeto assinado, observada por múltiplos validadores independentes, relatada por um operador afetado, ou inferida do timing. Isso não é um substituto para fatos. Indica aos leitores onde investigação adicional é necessária.

O provedor também deve publicar o que não foi medido. Se nenhum dado de perda de cliente foi coletado, diga-o. Se rsync foi testado mas os logs RRDP estavam indisponíveis, indique a lacuna. Se um coletor BGP não viu a rota afetada, não trate a ausência como prova de ausência de efeito.

Um relatório honesto pode ser conciso e conter esses campos. O objetivo não é o comprimento burocrático. É impedir que uma afirmação estreita de tempo de funcionamento evidencie as evidências de que os operadores precisam.

Os créditos de serviço sozinhos são um mau remédio para a interrupção da segurança de roteamento

A publicação RPKI é frequentemente incluída na associação ou serviço de registro em vez de ser vendida como um serviço público a preço separado. Um crédito convencional sobre as taxas pode, portanto, ser trivial, difícil de calcular ou indisponível para partes usuárias e clientes downstream. Os remédios mais valiosos são operacionais.

Primeiro vem a correção rápida. Provedores precisam de um canal com pessoal contínuo para relatar um objeto errado, ausente ou desatualizado, com autenticação que não depende inteiramente do portal potencialmente afetado. O alvo de resposta deve variar de acordo com a margem de atualização e o risco de roteamento demonstrado.

Segundo vem a preservação de evidências. Versões de objetos, tempos de publicação, estado dos métodos de acesso, resultados de validação e autorizações de mudança devem ser retidos por tempo suficiente para investigação e reivindicações legítimas. Um reparo que sobrescreve evidências deixa as instituições discutindo da memória.

Terceiro vem a comunicação portátil. Um aviso de incidente assinado deve identificar os ramos de certificação afetados e os resumos de objetos para que validadores e operadores possam determinar a exposição sem confiar em capturas de tela ou rumores. As atualizações devem indicar se os caches existentes permanecem utilizáveis e se uma mudança solicitada está atrasada.

Quarto vem a revisão independente para eventos graves ou repetidos. O revisor deve testar os objetivos externos, examinar os controles do provedor e publicar as conclusões dentro dos limites de segurança. Um relato redigido pelo provedor é necessário mas não pode ser a única garantia quando o próprio monitoramento do provedor perdeu a falha.

Remédios financeiros ainda podem contar quando uma perda real e responsabilidade legal são estabelecidas. Seu design depende de responsabilidade, causalidade e lei aplicável. O compromisso de serviço não deve prometer compensação impossível, mas taxas baixas ou zero também não devem ser usadas para negar o dever de publicar com precisão e reparar rapidamente.

Operadores também têm deveres de continuidade mensuráveis

A responsabilidade externa não é um dispositivo para transferir todos os riscos RPKI para um repositório. Os operadores de rede escolhem validadores, intervalos de atualização, redundância, monitoramento e política de roteamento. Detentores de recursos escolhem o conteúdo e o timing dos ROAs. Essas decisões afetam materialmente as consequências.

Um operador deve executar software de parte usuária suportado, monitorar a sincronização bem-sucedida do repositório, manter pelo menos o comportamento de cache recomendado pelos padrões aplicáveis e testar a redundância RTR. Ele deve saber como seus roteadores se comportam quando cargas úteis desaparecem ou validadores se tornam indisponíveis. Um segundo validador que compartilha o mesmo resolvedor, mesma fonte de energia e mesmo defeito de software não é redundância robusta.

Detentores de recursos devem comparar ROAs com anúncios planejados antes de mudanças de rede, evitar comprimentos máximos desnecessariamente permissivos e verificar a publicação externa após criação ou transferência. Devem manter contatos de emergência e entender qual parte controla as chaves em arranjos hospedados e delegados.

Esses deveres devem aparecer na análise de incidente sem se tornar uma desculpa geral para a falha do repositório. Se um operador executou software desatualizado que rejeitou mais do que os padrões exigem, isso é pertinente. Se um repositório publicou um estado inconsistente, isso também é pertinente. Múltiplas causas podem contribuir para uma única perda.

Exercícios compartilhados podem melhorar ambos os lados. Um provedor pode anunciar uma janela de teste na qual um método de acesso é retirado enquanto os operadores verificam o failover. Ramos de certificação sintéticos podem testar alarmes de expiração e atualizações atômicas sem colocar em risco as rotas de produção. Operadores podem relatar resultados de convergência anonimizados.

O objetivo é uma prova recíproca. Provedores demonstram qualidade de publicação externa; operadores demonstram dependência prudente. Quando ambos são medidos, a incerteza residual se torna visível em vez de ser atribuída por contrato ou retórica apenas.

A NRS pode fazer da garantia externa um serviço de legitimidade

A NRS defende que os registros de números devem manter registros precisos, respeitar o papel operacional das redes e permanecer limitados por uma função de escrituração. O RPKI complica essa filosofia porque ações de certificado e repositório podem influenciar anúncios de roteamento que os operadores aceitam. A resposta apropriada não é rejeitar o RPKI. É tornar o poder adicionado observável e responsável.

A NRS poderia reunir detentores, operadores, engenheiros de registro, mantenedores de parte usuária e pesquisadores em torno de um perfil de garantia de repositório comum. O perfil definiria os quatro objetivos de serviço, os campos mínimos de incidente, os testes específicos de protocolo, o relato de atualização e os marcos de atribuição descritos aqui. A participação poderia começar voluntariamente, com resultados publicados por serviço e região.

Ela também poderia operar ou encomendar sondas neutras. A independência exigiria financiamento divulgado, código de medição aberto, regras de conflito e múltiplas redes de hospedagem. A NRS não deve certificar sua própria defesa por afirmação. Deve publicar evidências que qualquer operador, registro ou pesquisador possa reproduzir.

Uma revisão anual útil compararia cada repositório entidade com seus próprios objetivos publicados, sem classificar regiões por uma pontuação universal grosseira. Poderia identificar falhas parciais repetidas, failovers não testados, detecção externa lenta ou evidências de recuperação fracas. Provedores teriam o direito de corrigir erros factuais e anexar explicações, enquanto as observações subjacentes permaneceriam disponíveis.

Esse é um papel institucional positivo porque recompensa o bom desempenho. O evento do JPNIC em 2020, por exemplo, poderia receber crédito pela continuidade de validação em cache enquanto registrava a indisponibilidade de gerenciamento e recuperação. O evento da APNIC em 2019 poderia mostrar a resiliência do RRDP e a falha do rsync separadamente. A nuance substituiria tanto o alarmismo quanto a autossatisfação.

A NRS traduziria assim uma demanda geral por responsabilidade dos registros em um bem público prático: evidências comparáveis sobre se as afirmações críticas de segurança de roteamento são utilizáveis externamente.

Compras e políticas públicas devem exigir evidências que sobrevivam ao desacordo

Governos, operadores de infraestrutura crítica e grandes redes dependem cada vez mais do RPKI sem necessariamente operar as camadas de certificação e publicação nas quais confiam. Suas perguntas de compra devem ir além de saber se um provedor afirma alta disponibilidade.

Eles devem perguntar onde o RRDP e rsync estão hospedados, se seus domínios de falha diferem, com que frequência uma validação externa completa é executada, qual margem de atualização aciona a escalada, como as mudanças aceitas são associadas à publicação, quais versões de validador são testadas, como os incidentes são anunciados e como as evidências são preservadas. Devem solicitar resultados recentes de exercícios e exemplos de convergência de recuperação.

Políticas públicas devem resistir a impor uma resposta de rota universal a um evento de repositório. Os operadores têm diferentes posições de risco, e o comportamento de falha aberta tem benefícios de continuidade além de custos de segurança. A exigência mais construtiva é a transparência: divulgar a visão de validação, a política local e o plano de failover para sistemas cuja interrupção afetaria serviços públicos.

O monitoramento também deve distinguir o repositório de um registro regional dos pontos de publicação delegados abaixo. Uma âncora de confiança pode estar acessível enquanto uma autoridade delegada falha. Uma política que atribui cada falha delegada ao pai desencorajará a delegação sem melhorar a medição. O caminho de certificação identifica onde a falha ocorreu; a governança deve seguir essa evidência.

Seguros e revisões de risco por conselhos podem usar o mesmo modelo. Eles podem examinar se uma organização conhece sua margem de cache, possui validadores independentes, mantém histórico de política de rota e pode contatar o contato de repositório apropriado. Isso transforma o RPKI de um controle abstrato de cibersegurança em uma dependência de continuidade auditável.

O padrão não deve garantir roteamento ininterrupto. Deve garantir uma resposta disciplinada a uma pergunta mais restrita: o que estava disponível externamente, quando deixou de ser utilizável, quem controlava o passo falhado e qual consequência de roteamento foi realmente observada?

A falha de repositório que os relatórios de política perdem é aquela escondida entre a publicação e a dependência

Repositórios RPKI já demonstraram que falhas não se encaixam em um único contador de tempo de funcionamento. O hardware pode parar o acesso sem esgotar a validade em cache. Um manifesto desatualizado pode danificar rsync enquanto o RRDP permanece consistente. Um disco pode bloquear silenciosamente mudanças até que uma CRL expire. Certificados pai e filho podem ser individualmente autênticos mas temporariamente inconsistentes. Um nó de distribuição pode servir identificadores de transporte discordantes enquanto um método alternativo permanece disponível.

Esses não são argumentos contra a validação de origem de rota. São evidências de que a segurança de roteamento amadureceu em uma infraestrutura que merece garantia de serviço madura. A criptografia torna a falsificação detectável; não torna a publicação infalível. O cache fornece continuidade; não prova que o novo estado chegou. A política de roteamento local preserva a autonomia do operador; não elimina a responsabilidade do repositório.

A melhor afirmação de disponibilidade é, portanto, modesta e precisa. Um provedor pode dizer que sondas independentes nomeadas recuperaram o material completo atual por métodos indicados, que todos os ramos de certificação testados validaram, que as ações aceitas se tornaram visíveis no prazo, que os validadores suportados convergiram após o reparo e que os efeitos de roteamento observados foram ou não encontrados em uma população definida. Outra parte pode repetir os testes.

Qualquer afirmação mais ampla precisa de mais evidências. Um painel interno não pode provar a recuperabilidade externa. Um ROA ausente não pode provar perda de cliente. Um coletor BGP estável não pode provar que nenhuma rede privada foi afetada. Uma porcentagem global não pode ser construída a partir de uma amostra não divulgada.

A legitimidade do registro cresce quando a instituição não pede ao público que aceite seu tempo de funcionamento na fé. A NRS e a comunidade mais ampla de operadores podem ajudar a estabelecer esse padrão. O repositório deve ser julgado no ponto em que suas afirmações se tornam utilizáveis, antes que seus relógios expirem e depois que suas consequências sejam visíveis.

Essa é a falha que os relatórios de política geralmente perdem: não o momento em que uma máquina parou, mas o intervalo durante o qual as partes usuárias da internet não podiam mais obter a mesma declaração oportuna, consistente e responsável de autoridade de roteamento.

Fontes