Resumo

  • O atributo src-members proposto pelo GROW vincula a referência imediata de um conjunto RPSL a um registro IRR, mas o vínculo não se propaga às referências internas do objeto encontrado.
  • Na convivência entre ferramentas novas e legadas, um objeto válido pode gerar políticas diferentes; uma decisão de implantação precisa guardar o caminho de resolução e a diferença exata entre os resultados.

Uma reunião de auditoria costuma começar pela configuração que chegou ao roteador. Se a lista de prefixos tem hash, data e aprovação, parece haver uma cadeia suficiente. A pergunta difícil surge quando alguém tenta regenerá-la: qual cópia de AS-EXAMPLE foi usada em cada nível de uma expansão RPSL distribuída por vários registros?

draft-ietf-grow-rpsl-registry-scoped-members-00 oferece uma resposta parcial e importante. O texto adiciona src-members às classes as-set e route-set. Em vez de referenciar apenas AS-EXAMPLE, o mantenedor pode escrever RIPE::AS-EXAMPLE. O resolvedor compatível passa a conhecer a chave e o registro desejado para aquela consulta.

Essa precisão tem alcance local. Confundi-la com procedência de ponta a ponta seria criar uma garantia que o próprio projeto não oferece.

A recursão atravessa fronteiras independentes

Conjuntos RPSL incluem números de AS, prefixos e outros conjuntos. A referência pode continuar por muitos níveis. Os registros IRR são administrados separadamente, e as chaves primárias não são globalmente únicas. Um servidor que espelha várias fontes pode guardar objetos homônimos.

O projeto descreve o efeito operacional da ambiguidade. Um resolvedor pode buscar o objeto de um registro diferente daquele pretendido pelo operador e gerar política não intencional. Também pode deixar de encontrar o objeto correto e omitir rotas que deveriam ser aceitas. O texto relaciona esses casos a vazamento de rotas, auxílio a sequestro e perda de alcance. Não se deve ampliar a evidência: a revisão 00 não identifica um novo incidente nem mede quantas redes já adotaram a solução.

Ao ler src-members, o resolvedor deve combinar nome do registro e chave primária. Se o registro não estiver disponível, não existe objeto correspondente. Um fallback silencioso para uma cópia sem escopo destruiria a escolha explícita.

A regra seguinte é menos intuitiva. O escopo termina no objeto selecionado. As referências desse filho são avaliadas pelos próprios atributos. Um novo src-members pode escolher outro registro. Um members ou mp-members antigo devolve a decisão ao algoritmo tradicional de seleção de fontes. O prefixo usado no pai não desce pela árvore.

A restrição na consulta inicial também não desce. O software precisa permitir que a busca da raiz seja limitada a um registro, mas não pode aplicar essa limitação às consultas recursivas. Começar por RIPE::RS-FIRST não prova que todos os objetos usados vieram de RIPE.

A compatibilidade produz uma projeção sem a fonte

A mudança foi desenhada para ser gradual. Ferramentas antigas não entendem src-members; objetos existentes podem nunca ser atualizados ou podem migrar aos poucos. Por isso members e mp-members continuam no contrato.

Quando um objeto autoritativo contém src-members, o registro deve verificar que cada valor, sem o prefixo, também aparece nos atributos legados. Se o usuário não informar os campos antigos, o software autoritativo pode gerá-los conforme a recomendação. Se já forem fornecidos, não deve alterá-los. Servidores não autoritativos não podem gerar essa projeção.

Não existe conversão segura no sentido contrário. A partir de RS-SECOND, o sistema não pode deduzir se a intenção era RIPE, ARIN ou outro registro. O projeto proíbe essa inferência porque a origem perdida é justamente a ambiguidade a ser corrigida.

Assim, o mesmo objeto aceito sustenta duas leituras. O resolvedor novo escolhe RIPE::RS-SECOND. O legado enxerga RS-SECOND e utiliza sua preferência local. A validação demonstra correspondência entre os nomes depois da remoção do escopo; não demonstra que os objetos recuperados são iguais.

Há ainda uma restrição reveladora: RIPE::AS-OTHER e ARIN::AS-OTHER não podem aparecer juntos no mesmo src-members. A sintaxe nova distingue os dois, mas a projeção antiga reduziria ambos a AS-OTHER. Para manter compatibilidade, o formato preciso não pode expressar essa dupla referência.

Nada disso invalida o desenho. Mostra apenas que a aceitação pelo registro e a equivalência entre consumidores são fatos diferentes, exigindo provas diferentes.

O recibo de procedência da resolução

Uma lista final não explica a própria produção. Contagens iguais podem esconder membros distintos. Conjuntos iguais podem depender de instantâneos e regras diferentes e se separar na atualização seguinte. É preciso guardar o cálculo antes que a exportação o achate.

O recibo proposto por Daniel Kade começa com a chave raiz, a eventual restrição de registro e a identidade da ferramenta. Registra implementação e versão, suporte efetivamente ativado para src-members, registros habilitados e um serial, instantâneo ou hash verificável de cada fonte.

Cada aresta recursiva ganha uma linha de evidência: registro e chave do pai, atributo lido, referência exatamente como publicada, escolha explícita ou implícita da origem, registro e chave selecionados e hash do objeto. Registro desconhecido, ausência, colisão, ciclo, profundidade máxima e limite de volume são resultados, não ruído descartável.

Na migração, o operador calcula duas saídas. A primeira segue a semântica com escopo. A segunda reproduz os leitores legados que ainda podem gerar política. Os dois hashes e a diferença exata de membros ficam no recibo. Uma divergência aceita precisa de revisor, motivo, validade, consumidores afetados e autoridade de rollback.

O último vínculo é com a versão do compilador, filtros, normalização, hash da configuração gerada, alvo e autorização da mudança. Sem isso, uma organização consegue provar que consultou os dados corretos, mas não que implantou o artefato revisado.

Procedência não é validação de origem

O recibo não torna um objeto IRR verdadeiro por decreto. Não confirma titularidade de recursos, relação comercial ou anúncio BGP, nem substitui RPKI. Ele documenta a transformação e a decisão, mantendo as demais camadas em seus lugares.

Também não exige publicar segredos. Hashes, identificadores de fontes, funções responsáveis, diferenças e referências de mudança preservam a sequência sem expor credenciais ou políticas completas.

Quando as duas saídas divergem, a resposta não é escolher automaticamente a nova. O escopo explícito pode corrigir um erro antigo, mas um gerador legado ainda em uso por uma unidade ou fornecedor continua sendo um fato operacional. A diferença abre uma decisão sobre consumidores, intenção, prazo de migração e reversão.

O projeto ainda exige a detecção de referências circulares e recomenda limites de profundidade ou tamanho. Alterar esses controles pode mudar a política sem alterar os objetos. Por isso eles precisam aparecer no recibo e na aprovação.

src-members transforma uma escolha implícita em informação escrita. O ganho só chega à governança se a informação sobreviver ao processo que gera a configuração. O prefixo para no próximo objeto; a responsabilidade acompanha o caminho inteiro.

Fontes

  1. Registro do projeto sobre membros RPSL com escopo
  2. Histórico do projeto atual
  3. Revisão 00 em HTML
  4. Revisão 00 em texto
  5. XML da revisão 00
  6. Registro do projeto predecessor
  7. Histórico do predecessor
  8. Revisão 01 do predecessor
  9. Escopo do grupo GROW
  10. Documentos do GROW
  11. Comunicado de adoção pelo GROW
  12. Repositório dos autores
  13. RFC 2622: Routing Policy Specification Language
  14. RFC 4012: RPSL de próxima geração
  15. RFC 2725: segurança do sistema de políticas
  16. RFC 2650: RPSL na prática
  17. RFC 7682: considerações sobre os IRRs
  18. RFC 7909: problema e uso de RPKI na validação de origem
  19. Lu Heng: especificação inicial mínima, decisão futura localizada e adoção voluntária
  20. Lu Heng: The Policy Mirror