Resumo

  • A janela para correções de segurança da APNIC está marcada para 13 de outubro, das 08h às 09h (UTC+10). O aviso prevê até dois minutos sem rsync em rpki.sub.apnic.net e não espera interrupção nos outros serviços de RPKI.
  • O ponto atende à publicação para clientes RPKI autogeridos, segundo a CPS publicada pela APNIC. O aviso não informa como cada cliente tentará novamente, se seu cache mudará ou se haverá efeito sobre o roteamento.

Análise

No aviso publicado em 9 de outubro, a APNIC reservou uma hora na terça-feira, 13 de outubro, das 08h às 09h (UTC+10), para aplicar correções de segurança ao sistema RPKI. Dentro desse intervalo, o texto delimita uma possível interrupção: o serviço rsync em rpki.sub.apnic.net poderá ficar indisponível por até dois minutos. A APNIC não espera interrupção nos demais serviços de RPKI.

São três informações diferentes: uma janela de uma hora para o trabalho, uma possível pausa de no máximo dois minutos em um serviço rsync identificado e uma expectativa para o restante dos serviços de RPKI. Chamar o episódio de uma interrupção de RPKI por uma hora ampliaria o impacto anunciado. Dizer que não haverá interrupção apagaria o aviso dirigido a quem usa esse ponto.

O nome do host tem uma função específica na Declaração de Práticas de Certificação (CPS) publicada pela APNIC. O documento distingue o repositório das autoridades certificadoras da APNIC do serviço de publicação para clientes RPKI autogeridos. Para este último, lista rpki.sub.apnic.net via rsync e rrdp.sub.apnic.net via RRDP. A CPS diz que entrou em vigor em 4 de maio de 2021; ela ajuda a entender a arquitetura publicada, mas não é um inventário recente das configurações dos clientes.

Essa distinção define a escala correta do aviso. A superfície mencionada não é cada função de RPKI da APNIC nem toda rede que consome dados RPKI. É um método de busca em um repositório específico. A expectativa de que os outros serviços não serão interrompidos é uma previsão da APNIC; o aviso não descreve separadamente o comportamento de cada cliente ou método de acesso.

A camada de protocolo mostra por que essa delimitação importa. A RFC 8897 descreve o software de relying parties buscando objetos assinados pelos mecanismos aceitos pelo repositório consultado, como rsync ou RRDP, para atualizar um cache local. A RFC 8182 define o RRDP como um protocolo de acesso a repositórios baseado em HTTPS. Essas normas não revelam qual método cada operador configurou, se o software mudará de método automaticamente nem quando ocorrerá a próxima atualização do cache.

Uma pausa curta pode, portanto, adiar uma tentativa de busca de um cliente que dependa desse rsync. Isso não demonstra que o cache existente ficará desatualizado, que uma autorização de origem de rota mudará ou que um roteador alterará o tratamento de uma rota. O aviso não informa a quantidade de clientes, observações de validadores, mudanças de rota nem efeitos para usuários. O trabalho ainda está previsto; não há resultado posterior à manutenção.

A leitura útil é a do escopo: uma hora reservada para a manutenção, até dois minutos de possível indisponibilidade rsync em um ponto e nenhuma interrupção esperada nos demais serviços de RPKI. Depois de 13 de outubro, os registros de serviço da APNIC e os logs locais das relying parties poderão substituir a previsão por observações.

Fontes