Resumo
- A revisão 03 do rascunho do GROW sobre termos usados em operações de roteamento é deliberadamente descritiva e não autoritativa; registra usos atuais, inclusive quando uma palavra muda de sentido entre contextos.
Route hijackclassifica um anúncio que o AS não está autorizado a fazer, mas o próprio texto admite origem acidental ou maliciosa. Automação não pode converter o rótulo em intenção, culpabilidade ou resposta punitiva sem uma cadeia separada de evidências.
O painel marcou o evento em vermelho: HIJACK. Em poucos segundos, outro sistema preencheu “ator malicioso”, abriu um caso de abuso e propôs bloquear permanentemente o ASN. O primeiro rótulo tinha base: um caminho observado contrariava a autorização conhecida. Os passos seguintes não tinham. O dado técnico descrevia uma diferença; a plataforma o promoveu a uma história sobre intenção.
Esse tipo de expansão semântica aparece com nitidez na revisão 03 de Currently Used Terminology in Global Routing Operations, apresentada por Tobias Fiebig e Wolfgang Tremmel em 2 de outubro de 2026. O documento reúne linguagem empregada hoje por operadores, mas declara que não é uma fonte autoritativa da terminologia correta. Seu escopo é descritivo, situado no tempo e sujeito a mudança. Um termo pode surgir em mais de uma seção com descrições diferentes.
No Datatracker, a revisão consta como Internet-Draft ativo do grupo GROW, no fluxo IETF. O status pretendido é Informational, com expiração em 5 de abril de 2027. Não há RFC, Area Director responsável, shepherd, telechat ou conclusão do processo. O texto não pede ação à IANA. Em Security Considerations, afirma que, por descrever termos sem fazer recomendações, o próprio documento não traz considerações de segurança.
Essa frase não imuniza os sistemas consumidores. Um glossário não bloqueia rotas nem acusa pessoas. Um pipeline que transforma seus nomes em comandos, sanções ou conclusões de atribuição pode criar consequências de segurança. O risco nasce quando o alcance da evidência deixa de acompanhar o alcance da decisão.
A classificação observa um desvio, não lê uma mente
O rascunho descreve um BGP ou route hijack como a situação em que um AS anuncia uma rota que não está autorizado a anunciar. Logo em seguida, registra que isso pode resultar de configuração acidental ou de ação maliciosa. A distinção não é uma nota lateral: ela define o limite entre detecção e atribuição.
Um observador pode comparar um anúncio com um ROA, uma lista de autorização, um acordo operacional ou um histórico. Pode demonstrar que, segundo aquela fonte e naquele instante, a origem não era autorizada. Ainda assim, não sabe automaticamente quem inseriu a configuração, se houve credencial comprometida, teste vazado, erro de automação, base desatualizada ou intenção deliberada.
Até a palavra “autorizado” exige coordenadas. Autorizado por qual titular, para qual prefixo, comprimento máximo, período, origem e política? Uma fonte de autorização pode estar atrasada ou cobrir apenas a origem, não a propagação. A evidência deve registrar a versão e o ponto de vista, em vez de esconder tudo sob hijack=true.
Uma cadeia madura separa pelo menos seis registros: observação do anúncio; comparação com uma autorização identificada; classificação técnica; hipóteses causais; atribuição a um principal; decisão de resposta. Cada transição precisa de evidência e responsável. O rótulo inicial não deve preencher os campos seguintes por herança.
RPKI responde a uma pergunta estreita
RFC 6480 apresenta a arquitetura de certificação de recursos. RFC 9582 especifica os Route Origin Authorizations, pelos quais um detentor autoriza um AS a originar rotas para prefixos dentro de determinado escopo. Essa infraestrutura oferece evidência valiosa e verificável sobre a origem.
Um estado Valid, porém, não afirma que o caminho respeitou relações comerciais, que não houve vazamento, que a rota está instalada em toda parte ou que os pacotes chegaram. Ele também não certifica a intenção de quem operou o AS. É uma resposta sobre compatibilidade entre anúncio de origem e objetos validados por um ponto de validação.
Invalid ou NotFound tampouco são ordens universais que dispensam política local. O estado depende do conjunto de objetos disponível, do instante de sincronização e da implementação do validador. O roteador aplica uma política configurada. Depois, a seleção e o encaminhamento produzem resultados que precisam ser observados.
Se um sistema resume tudo isso como safe ou malicious, elimina precisamente as diferenças que permitem investigar. Validador, sessão RTR, cache, política do roteador, decisão, RIB, FIB e telemetria devem permanecer identificáveis.
Vazamento também depende da política esperada
RFC 7908 organiza route leaks como propagação de anúncios além do escopo pretendido, em violação às políticas esperadas. A descrição do caminho pode mostrar que uma rota atravessou uma relação inesperada. Para afirmar que houve violação, contudo, o investigador precisa conhecer a política que deveria vigorar.
Essa política não nasce da existência de uma sessão. O rascunho de terminologia usa peer de duas formas relevantes: como relação entre ASes que trocam suas rotas e as de downstreams, e como simples vizinho BGP que troca NLRI. Um cliente e seu provedor também são vizinhos BGP. Tratar todo vizinho como relação de peering altera a expectativa de exportação e pode classificar o evento errado.
RFC 9234 introduz BGP Roles negociados em OPEN para ajudar a prevenir leaks. É um recibo mais específico que inferir pelo nome, mas continua sendo uma peça. Relação contratual, declaração operacional, Role negociado, filtro instalado e exportações observadas podem concordar ou divergir. A divergência é evidência, não ruído a ser esmagado.
RFC 4271 descreve uma decisão local do speaker. Uma rota selecionada por um roteador não comprova como outro roteador interpretou a relação, nem por onde os pacotes seguiram. A atribuição precisa resistir à tentação de usar um fato local para completar um enredo global.
A revisão 03 melhora os limites das palavras
A passagem da revisão 02 para a 03 inclui ampliação de siglas, definições e referências, além de correções editoriais substantivas. A descrição de BFD deixa de sugerir que o protocolo verifica se um vizinho está “vivo” e passa a falar em verificar se o vizinho configurado está alcançável, notificando protocolos como BGP quando essa alcançabilidade se perde.
Trocar “vivo” por “alcançável” reduz uma inferência excessiva. BFD Up é evidência sobre uma sessão e um caminho sob condições configuradas. Não é recibo de disponibilidade do serviço, de correção da política ou de legitimidade institucional. BFD Down detecta uma falha, mas não resolve sozinho a causa.
O texto também refina atributos BGP e adiciona ou esclarece entradas como BGP, EGP, IGP, EIGRP, IS-IS, OSPF e RIR. Essas mudanças tornam o mapa mais preciso para leitores de outros documentos.
Ainda assim, a revisão permanece um retrato descritivo. Um banco de incidentes que adote a versão nova deve guardar procedência e versão. Não pode reclassificar automaticamente eventos antigos, pois os operadores talvez tenham empregado outro sentido no momento da decisão. Onde o significado histórico não for recuperável, a resposta correta é ambiguidade.
Um sintoma e uma intervenção podem ter o mesmo nome
Blackholing ilustra uma mudança ainda mais perigosa. Em uso geral, pode designar pacotes descartados silenciosamente, sem retorno ICMP: um sintoma observado. Em contexto de mitigação, pode designar o anúncio de prefixos com uma comunidade específica para solicitar que vizinhos descartem o tráfego: uma ação deliberada.
Se o classificador de incidentes produz blackhole e o orquestrador entende “execute blackholing”, a organização transforma diagnóstico em autorização. Um falso positivo de perda pode gerar uma indisponibilidade real. Para agir, são necessários prefixo, comunidade, alcance, vizinhos, janela, principal autorizado, critério de retirada e observação do efeito.
O mesmo cuidado vale para depeering. Remover sessões com um AS vizinho não prova que a relação institucional terminou nem que todo tráfego cessou. Outra interconexão, trânsito, rota padrão ou estado de encaminhamento pode continuar transportando pacotes. O recibo de configuração responde “o comando foi aplicado”; o plano de dados responde “o efeito aconteceu”.
Nomear ambas as coisas com a mesma palavra pode ser confortável para humanos que conhecem o contexto. Para a máquina, o contexto precisa virar campo obrigatório.
Cones, bordas e conjuntos não são metáforas inofensivas
O termo cone pode representar o conjunto recursivo de ASes downstream e, conforme o contexto, o conjunto conjunto dos prefixos que eles originam. Conjunto de ASN e conjunto de prefixos são tipos diferentes. Uma consulta de pertinência pode ser formalmente válida e semanticamente absurda se o tipo estiver ausente.
A passagem de ASes a prefixos requer um mapeamento datado, uma fonte e um ponto de observação. Origem vista em BGP não é necessariamente autorização. Direitos institucionais, anúncios e tráfego são relações distintas. Um incidente atribuído a um “cone” sem tipo torna impossível reconstruir quem ou o que foi incluído.
Network edge e Provider Edge também não são sinônimos operacionais. O último roteador sob controle de um operador pode não desempenhar o papel de PE em uma rede MPLS. Um inventário que usa apenas edge pode enviar uma política funcional ao limite administrativo errado.
Esses exemplos importam para atribuição porque delimitam o objeto observado. Se o conjunto, a borda ou a relação estiverem errados, o sistema pode apontar para a organização errada antes mesmo de discutir intenção.
“Tabela completa” e “convergido” precisam de coordenadas
O rascunho chama de Full Table uma tabela com rota para todos os prefixos da Global Routing Table e sem rota padrão. Para avaliar “todos”, é preciso declarar família de endereços, speaker ou coletor, política de importação, instante e conjunto de referência.
Uma tabela IPv4 completa em um ponto não implica IPv6, outra localidade ou outro vizinho. A RIB pode parecer completa enquanto a FIB está incompleta por limitação, recursão, filtro ou atraso. Mesmo uma FIB programada não prova entrega fim a fim.
Converged também tem alcance. Um speaker pode terminar sua seleção enquanto outros recebem atualizações, o hardware muda ou o tráfego oscila. Uma plataforma que fecha a investigação ao ler converged pode perder a janela em que a atribuição ainda está sendo testada.
A evidência deve manter estados simultâneos: convergência local verdadeira, estabilidade global desconhecida, entrega parcial, intenção não determinada. Forçar um único semáforo destrói essas distinções.
O envelope mínimo de significado
Antes que um termo descritivo provoque ação, o consumidor deveria exigir: a palavra original; o vocabulário e sua versão; um identificador estável de sentido; o contexto; sujeitos e direção; ponto de observação e tempo; fonte ou prova; ação pedida e principal autorizado; incerteza e interpretações concorrentes.
Para incidentes, mais dois limites são essenciais: classificação não equivale a atribuição; atribuição não equivale a autorização de resposta. O sistema pode automatizar coleta e comparação sem automatizar um salto probatório que não ocorreu.
Minimum Initial Specification não pede uma ontologia perfeita. Pede o menor contrato que impeça o erro de categoria. A interface pode continuar mostrando “sequestro”. O registro precisa dizer qual anúncio, qual fonte de autorização, qual validador, quando, de onde e que conclusões ainda permanecem abertas.
Running-Code Primacy exige canários adversos: um leak acidental rotulado como ataque; um ROA Valid em caminho que viola política; um Invalid causado por repositório atrasado; um blackhole observado que não autoriza blackholing; um depeering com tráfego alternativo. O sistema seguro preserva o desconhecido e impede escaladas automáticas.
Dados legados com apenas hijack=true não devem ganhar intenção retroativa. Uma migração pode propor interpretações com evidência, mas precisa marcar inferência, versão e confiança. Sem isso, o banco de incidentes se torna uma máquina de fabricar passado.
A humildade do rascunho é uma propriedade útil
A revisão 03 vale justamente porque não reivindica poder que não possui. Ela organiza linguagem contemporânea, mostra polissemia e melhora definições. Faz com que equipes percebam pressupostos antes invisíveis.
O consumidor precisa terminar o trabalho. Inventários tipam objetos. Motores de política exigem predicados. Agentes recebem capacidades limitadas. Processos de incidente separam observação, classificação, causa, intenção, decisão e resultado. Nenhum deles deve pedir ao glossário que julgue em seu lugar.
Nas camadas de realidade de Heng Lu, o rótulo é coordenação simbólica; autorização e relação são fatos institucionais; configuração e sessão são estados executáveis; propagação e entrega são observações. Uma palavra pode aparecer em todas, mas não atravessa as fronteiras sem evidência.
O painel do início poderia manter route hijack como classificação técnica e, ao lado, mostrar cause: unknown e intent: unestablished. Isso não seria fraqueza. Seria precisão. A decisão madura não começa apagando a dúvida; começa impedindo que a dúvida se transforme, por conveniência, numa acusação e numa ação irreversível.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/
- https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/history/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-grow-routing-ops-terms/
- https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/references/
- https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-03.txt
- https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-03.html
- https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-03.xml
- https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-02.txt
- https://datatracker.ietf.org/wg/grow/about/
- https://www.rfc-editor.org/rfc/rfc4271.html
- https://www.rfc-editor.org/rfc/rfc9234.html
- https://www.rfc-editor.org/rfc/rfc7908.html
- https://www.rfc-editor.org/rfc/rfc6480.html
- https://www.rfc-editor.org/rfc/rfc9582.html
- https://www.rfc-editor.org/rfc/rfc7454.html
- https://www.rfc-editor.org/rfc/rfc5880.html
- https://www.rfc-editor.org/rfc/rfc5925.html
- https://www.rfc-editor.org/rfc/rfc8174.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
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
