Resumo

  • Siddiqui propôs restringir os ASN de origem aceitos em ROAs da APNIC e, como presidente do Routing Security SIG, também participou da apresentação de uma pesquisa sobre funções que poderiam ser oferecidas aos operadores.
  • A proposta deixou um histórico público de versões, consenso, publicação de diretriz e status de implementação. A pesquisa registrou preferências por avisos de ROA e APIs; não determinou o lançamento de um produto nem comprovou maior segurança no roteamento.

Dois caminhos institucionais, dois tipos de registro

Um registro regional da Internet pode receber uma preocupação operacional por mais de um canal. Uma proposta de política percorre um processo definido: há versões sucessivas, discussão pública e um ponto de decisão que fica documentado. Uma pesquisa sobre serviços tem outro papel. Ela registra preferências e problemas de trabalho que podem ajudar uma equipe de produto a avaliar opções, mas não substitui a decisão dessa equipe.

A trajetória pública de Aftab Siddiqui na APNIC cruza esses dois caminhos. Em 2021, ele propôs limitar os números de sistemas autônomos que poderiam constar como origem em uma Route Origin Authorization (ROA). Em paralelo, como presidente do Routing Security Special Interest Group (SIG), foi coautor de um relato sobre uma pesquisa a respeito de notificações de ROA e APIs para administrá-las. Os assuntos são próximos no plano técnico; o mecanismo institucional não é o mesmo.

É importante separar o registro mantido pela organização do estado das rotas na Internet. Uma API pode facilitar a alteração de um objeto por uma pessoa autorizada. Uma ROA declara qual sistema autônomo está autorizado a originar um prefixo. Ainda é preciso que a organização publique os dados, que validadores os obtenham e que cada rede decida como usar o resultado. Uma pesquisa sobre uma ferramenta de gestão não demonstra que essas etapas ocorreram.

Um fórum para ouvir operadores, não para aprovar lançamentos

O relatório da APNIC 49, em 2020, descreve uma eleição para a presidência e uma discussão sobre o nome e a carta do Routing Security/RPKI SIG, que já existia. Depois do endosso da comunidade, o grupo adotou o nome Routing Security SIG, aprovou a carta e elegeu Siddiqui como presidente. A carta define um espaço para discutir problemas operacionais e boas práticas. Também prevê coletar a opinião dos operadores sobre serviços da APNIC — como RPKI, IRRd e RRDP — e aconselhar a comunidade sobre aspectos técnicos de propostas de política relacionadas à segurança do roteamento.

Esse mandato aproxima quem opera redes da equipe da APNIC que mantém os serviços. Os operadores podem explicar onde o fluxo de trabalho emperra; a equipe pode avaliar mudanças. Mas o SIG não recebeu poder para escolher prioridades de produto nem para prometer uma data de lançamento. Na declaração de candidatura de 2022, Siddiqui descreveu o grupo como uma ponte para discutir problemas operacionais e recursos ou suporte que a APNIC poderia oferecer. Também afirmou que a pandemia havia reduzido o ritmo. São avaliações dele naquele momento, não uma medição independente de participação ou desempenho.

O passo seguinte mostra quem ainda precisava decidir. Um texto da APNIC publicado antes da reunião de 2022 dizia que a equipe de serviços deveria apresentar uma análise de custos e benefícios das funções sugeridas. O fórum podia formular a questão; a equipe responsável pelo serviço tinha de avaliar a proposta.

O alcance — e as lacunas — da pesquisa

O artigo publicado pela APNIC em setembro de 2022, coassinado por Siddiqui, Di Ma e Afifa Abbas, diz que a pesquisa foi feita após a sessão aberta de outubro de 2021. Sobre o envio de e-mail quando uma ROA fosse criada, 52,4% responderam que sim, 33,3% preferiam uma opção ativada pelo usuário, 9,5% receavam um volume excessivo de avisos e 4,8% pediram mais discussão. Entre os favoráveis à notificação, 47,6% preferiam webhooks, 28,6% consideravam o e-mail suficiente e 23,8% estavam em dúvida.

Sobre APIs para gerenciar ROAs — pelo MyAPNIC ou por software RPKI autogerenciado, como o Krill — os resultados publicados foram 66,7% a favor, 19% contra e 14,3% talvez.

Esses números registram preferências expressas. A publicação não informa o denominador, o método de resposta nem a divisão por tipo de rede. Portanto, não é possível saber quantas pessoas responderam ou se elas representam os membros da APNIC, os operadores em geral ou toda a região. Também não se trata de uma votação sobre política de roteamento: as perguntas são sobre possíveis funções de serviço, e algumas respostas pediram que o tema continuasse em discussão.

As perguntas, ainda assim, identificam fricções concretas. Uma notificação avisa o contato técnico de que uma ROA foi criada; um webhook pode levar esse evento aos sistemas internos do operador; uma API pode automatizar mudanças que antes eram manuais. Cada opção altera uma parte do fluxo de trabalho. Nenhuma determina sozinha se a ROA está correta ou se um roteador vai rejeitar uma rota inválida.

Uma API posterior não comprova a causa

Em outubro de 2024, a APNIC anunciou a disponibilidade do Registry API. Ele permite consultar informações de delegação e administrar registros Whois, DNS reverso, ROAs e objetos de rota. Segundo a APNIC, o serviço atende a pedidos de membros e permite automatizar algumas mudanças que antes exigiam operações manuais no MyAPNIC. O relatório anual de 2022 já descrevia um protótipo disponível para testes públicos e previa começar o desenvolvimento de produção em 2023.

Há uma sobreposição clara entre a pesquisa e o produto: ambos tratam de acesso por API a funções do registro, inclusive à gestão de ROAs. Mas as fontes citadas não dizem que a pesquisa de 2021 iniciou o projeto, que seus respondentes eram os membros que solicitaram a ferramenta ou que o SIG escolheu o desenho do produto. A disponibilidade posterior não comprova que os participantes passaram a usar a API, nem mede queda de vazamentos ou sequestros de rotas.

“Segurança de roteamento” pode encobrir várias camadas. O registro oferece uma interface; o titular de recursos altera objetos; a organização publica dados assinados; um validador os consome; e cada rede decide como agir diante do estado de validação. A evidência de uma etapa não deve ser apresentada como comprovação da próxima.

A proposta de política deixou outro tipo de rastro

A prop-138 de Siddiqui oferece um contraste. A proposta apontava que o sistema de gestão de ROAs da APNIC permitia usar ASN privados, reservados ou não alocados como origem, e sugeria restringir essa prática. A segunda versão estendia a medida aos objetos route e route6. O rastreador público da APNIC registra as versões de agosto e setembro de 2021; informa que, em 16 de setembro, a reunião aberta de política da APNIC 52 chegou a consenso para avançar como diretriz; registra a publicação em dezembro; e mostra o status atual como “Implemented”.

Esse registro é mais formal do que o de uma pesquisa de serviço: identifica a regra proposta, suas versões, a data do consenso e um status de implementação. Ainda assim, não informa quantos objetos problemáticos deixaram de ser criados nem quanto o risco de roteamento mudou. “Implementado” descreve um estágio do processo, não um estudo de impacto.

A comparação não torna a pesquisa irrelevante; mostra que as duas vias produzem resultados institucionais diferentes. O processo de política registra se uma proposta chegou ao ponto de decisão da comunidade. A pesquisa oferece ao responsável pelo serviço um retrato de preferências e dúvidas. Para avaliar resultados, é preciso procurar a evidência adequada: status da regra, especificação e histórico de lançamento do serviço, além de dados operacionais sobre os efeitos posteriores.

O que os documentos permitem afirmar sobre Siddiqui

A página de candidatura da APNIC de 2012 descrevia Siddiqui como gestor de operações de rede no Paquistão, envolvido em implantação de IPv6, segurança de infraestrutura, na IPv6 Task Force Pakistan e em atividades regionais de operadores. Uma página da APNIC de 2022 registra sua própria descrição do cargo de presidente do SIG e o interesse em aproximar problemas operacionais do suporte da APNIC. São registros datados que o colocam entre operações, discussão de políticas e feedback sobre serviços. Não fazem dele o único responsável pela direção do grupo nem o decisor dos sistemas da APNIC.

A conclusão mais segura é específica. Siddiqui apresentou uma proposta cujo percurso pode ser seguido no arquivo de políticas e ajudou a conduzir um fórum que registrou preferências de serviço e as levou à equipe responsável. A primeira via deixou uma trilha de consenso e implementação. A segunda produziu um sinal para a avaliação de um produto. A API lançada depois torna o assunto concreto, mas não preenche o vínculo causal ausente nem comprova um efeito sobre a segurança do roteamento.

Fontes