Resumo

  • A PE BGPsec configurada com os dois ASN deve ter chaves válidas para ambos e preservar a chave do ASN antigo até que suas sessões eBGP relevantes tenham migrado. A regra protege um caminho sob condição; não certifica uma operação societária.
  • ROAs concorrentes, duas assinaturas e pCount=0 são fatos de autorização ou de construção de caminho. Não demonstram compra, controle, aceitação por clientes, fim da transição nem sucesso de encaminhamento.

Há uma diferença entre uma credencial que permanece necessária e uma identidade que permanece politicamente independente — e BGPsec não decide essa diferença. A RFC 8206 parte de um caso em que um provedor pode combinar AS, manter ASN legados durante a mudança e fazer uma PE parecer o ASN antigo diante de um peer. É uma moldura de engenharia. Não é a ata de uma fusão nem a identificação de uma empresa que a tenha feito.

A própria escala da migração impede uma leitura apressada. Ela pode durar muito tempo, sem uma virada simultânea em todos os roteadores e sem coordenação obrigatória com cada cliente. O ASN antigo pode permanecer porque uma adjacência ainda foi configurada para esperá-lo. Isso dá à chave antiga um papel específico: ela permite que a PE cumpra a condição criptográfica daquela sessão. Não revela quantas sessões já mudaram, quem controla uma entidade jurídica ou se alguma contraparte aprovou a operação.

O caso dos ROAs é instrutivo. Enquanto PE do ASN anterior continuam originando um prefixo, o ASN substituto pode precisar de um ROA para originá-lo também. RFC 8206 aceita essas autorizações simultâneas. O significado de um ROA é uma autorização para validação de origem no RPKI. Ele não é uma prova de propriedade empresarial, de transferência de cadastro, de seleção da melhor rota por terceiros ou de que os dados chegaram a uma aplicação. Dois ROAs descrevem uma permissividade de origem; não encerram uma história de migração.

A validação BGPsec não amplia essa permissão. RFC 8205 define certificados RPKI que atestam alocações de ASN e espaço de endereços. Quem anuncia assina usando a chave privada correspondente; quem valida não precisa da chave. Uma validação positiva fala de um Secure_Path e da relação local de confiança e negócio usada pelo validador. Não fala, por si, de FIB, pacotes, disponibilidade, contrato ou controle corporativo.

Também não se deve perder de vista o desenho exato da RFC 8206. A solução opera numa PE com os dois ASN configurados localmente e uma relação eBGP existente. Na saída, a PE assina para os dois ASN; a parte que representa o ASN antigo recebe pCount=0. Para um peer que não usa BGPsec, o AS_PATH reconstruído não mostra essa parte, embora o Secure_Path a retenha. Na direção de entrada, uma CE que ainda espera o ASN antigo leva a PE a adicionar o segmento nas condições previstas. A técnica preserva significado numa fronteira conhecida; não transporta uma declaração de fusão para além dela.

O RFC é explícito ao recusar a ideia de que um domínio de cliente não coordenado deva aceitar pCount=0. Não há exigência de mudança remota, sincronização global ou caminho visivelmente maior. Essa modéstia é essencial: a regra comum resolve o mínimo para a interoperabilidade local. Ela não prova que atores fora do conjunto compatível implementaram, validaram ou adotaram a mudança.

Por isso, a obrigação de reter a chave antiga até que as sessões relevantes migrem não deve ser lida como um contador público de conclusão. É uma obrigação de manutenção do operador da PE. Para verificar que as sessões migraram, são necessários inventário de adjacências, configuração, datas de validade das chaves, logs do validador e observação independente de encaminhamento e serviço. Outro validador pode chegar a uma decisão distinta por sua própria política.

O princípio de Heng Lu sobre especificação inicial mínima dá uma linguagem institucional para essa disciplina. A camada compartilhada fixa regras determinísticas de interoperabilidade e segurança; escolhas de cronograma, custódia, pares, coordenação e adoção permanecem locais. Adoção voluntária só se torna real onde participantes compatíveis executam, verificam e aceitam. Uma RFC publicada e uma chave em uso não substituem essa cadeia.

A leitura correta conserva degraus: norma, ROA, estado de chave, caminho assinado, decisão do validador, estado da sessão, encaminhamento observado, resultado de serviço e, separadamente, provas de registro ou de empresa. Wesley George coassinou a norma. A norma não transforma a chave preservada num comunicado empresarial.

Fontes