Resumo
- O certificado EE precisa conter recursos IP explícitos, sem
inherit, e não pode conter a extensão de delegação de identificadores AS. - O
asIDda carga assinada recebe a autorização do titular do espaço. Essa prova não autentica quem opera o ASN, não cria não repúdio e não observa uma rota. - Objeto, VRP, sessão com o roteador, anúncio BGP, política, melhor caminho e serviço são etapas independentes.
Três equipes olharam para três verdes diferentes
A equipe de certificados dizia que o ROA era válido. A equipe do validador mostrava um VRP. A equipe de rede não via o anúncio esperado. Ninguém necessariamente estava errado; cada tela respondia a uma pergunta diferente.
No RFC 9582, o certificado EE prova autoridade sobre recursos de endereços. Sua extensão RFC 3779 deve conter todos os prefixos da carga e não pode usar inherit. A extensão de recursos AS, porém, não é usada e deve estar ausente.
O número do AS aparece no asID da carga RouteOriginAttestation. A assinatura vincula esse valor aos prefixos. O desenho não certifica que o signatário é o AS, nem identifica a empresa ou pessoa que opera o ASN. A seção de segurança é explícita: o PKI oferece autorização, não autenticação explícita, e o ROA não pretende produzir não repúdio.
Assim, “certificado verde” significa algo forte e limitado: quem possui a autoridade certificada sobre o endereço assinou uma permissão para um AS. Não significa que a rota existe, que o AS está sob determinado controle ou que o tráfego chegou.
A carga define o perímetro
Um ROA contém um AS. Dois AS autorizados exigem dois objetos. Essa separação deve sobreviver aos bancos operacionais para que uma retirada, renovação ou falha possa ser atribuída ao objeto certo.
Cada endereço tem prefixo e maxLength opcional. Sem o campo, apenas o prefixo exato é permitido. Com ele, mais específicos até o limite entram no conjunto autorizado. O RFC 9319 alerta que valores amplos podem abrir uma superfície maior que a necessária.
Mesmo uma autorização mínima não atesta identidade. maxLength responde quais comprimentos podem coincidir; não responde quem configurou BGP, quem guarda as chaves ou se o anúncio está presente.
O RFC 9582 também canoniza a lista. Família, primeiro endereço, comprimento e máximo efetivo formam uma chave de ordenação; chaves iguais são duplicadas. A forma reduz ambiguidade entre codificações, mas não elimina divergência de tempo entre repositório, validador e roteador.
Primeiro se valida o objeto
O relying party executa as verificações genéricas do RFC 6488 e as regras específicas. Confere cadeia, assinatura, conteúdo, contenção dos endereços, ausência de inherit, ausência da extensão AS e conformidade total. Uma falha invalida o ROA inteiro.
Somente então surge um VRP. O RFC 6811 compara essa autorização derivada com um anúncio recebido. A rota fornece prefixo, comprimento e origem. O resultado Valid, Invalid ou NotFound depende desse encontro; o arquivo ROA sozinho não observa BGP.
Depois vem a distribuição. O RFC 8210 liga cache e roteador. A sessão pode estar atrasada ou reiniciada. Em seguida vem a política local descrita em RFC 7115 e RFC 8893. Um estado pode causar rejeição, preferência, exceção ou registro, conforme a decisão do operador.
Ainda faltam seleção, propagação e dados. Uma rota classificada como válida pode perder para outra; uma rota escolhida pode encontrar falha de encaminhamento; pacotes entregues podem alcançar um serviço indisponível. O ícone RPKI não atravessa essas fronteiras.
Um incidente precisa de junções, não de um print
A linha do tempo útil une identificadores: hash e URI do ROA, manifesto e snapshot, cadeia e trust anchor, tupla do payload, VRP e versão do validador, sessão e serial no roteador, observação BGP, estado calculado, regra aplicada, caminho selecionado e teste de serviço.
O princípio de running code impede que o registro fale pelo roteador. A especificação mínima torna o objeto interoperável; a decisão futura continua local. As camadas permanecem auditáveis justamente porque nenhuma delas recebe autoridade para anunciar o resultado da seguinte.
Fontes
- https://www.rfc-editor.org/rfc/rfc9582.html
- https://www.rfc-editor.org/info/rfc9582/
- https://www.rfc-editor.org/rfc/rfc9582.txt
- https://www.rfc-editor.org/rfc/rfc9582.xml
- https://datatracker.ietf.org/doc/rfc9582/
- https://datatracker.ietf.org/doc/rfc9582/history/
- https://www.rfc-editor.org/errata/rfc9582
- https://www.rfc-editor.org/rfc/rfc6480.html
- https://www.rfc-editor.org/rfc/rfc6488.html
- https://www.rfc-editor.org/rfc/rfc3779.html
- https://www.rfc-editor.org/rfc/rfc6811.html
- https://www.rfc-editor.org/rfc/rfc8893.html
- https://www.rfc-editor.org/rfc/rfc9319.html
- https://www.rfc-editor.org/rfc/rfc8210.html
- https://www.rfc-editor.org/rfc/rfc7115.html
- https://www.rfc-editor.org/rfc/rfc6483.html
- https://www.iana.org/assignments/rpki/rpki.xhtml
- https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
