Resumo

  • O draft-geng-sidrops-bgp-drip-00 propõe associar rotas, devolver risco ao relying party, distribuir ROAs marcadas e sinalizar risco entre roteadores BGP.
  • A autorização criptográfica da origem pode continuar válida enquanto uma avaliação operacional reduz a preferência de rotas relacionadas.
  • O texto é um Internet-Draft individual na versão 00, sem endosso ou posição formal no IETF; detecção, associação, transporte, decisão local, validade e rollback precisam de recibos distintos.

A validação de origem não foi projetada para responder a todas as perguntas de segurança de uma rota. Ela verifica se um AS está autorizado a originar um prefixo. Não certifica o caminho inteiro, o estado do roteador, a intenção do vizinho ou a ausência de vazamento. O DRIP começa justamente onde essa resposta termina.

O rascunho descreve quatro esquemas. Primeiro, um roteador pode relacionar uma rota inválida ou suspeita a outras que compartilham o AS de origem, o vizinho imediato ou um padrão de AS_PATH e reduzir o Local_Pref. Depois, pode enviar ao RP um feedback com prefixo, origem ou peer suspeito, identificador da ROA e código de motivo. O RP pode guardar o risco e distribuir uma ROA com metadados adicionais. Por fim, uma Extended Community proposta pode carregar o sinal para outros roteadores.

O fluxo parece uma melhoria de telemetria, mas termina em uma decisão de política. Uma observação feita por um equipamento pode afetar caminhos que não falharam na validação. Quando o sinal cruza uma fronteira administrativa e encontra uma regra automática, o emissor passa a influenciar o tráfego de outra rede.

Uma assinatura válida não encerra a análise

O ponto mais esclarecedor do rascunho é que uma ROA marcada como risco pode preservar a assinatura criptográfica válida. Os registros têm funções diferentes. A ROA documenta autorização de origem; o rótulo comunica uma avaliação operacional temporária.

Misturá-los em um único estado produz falsa certeza. “Risco” pode significar ROV Invalid, salto inesperado no AS_PATH, suspeita sobre um peer ou apenas uma correlação com o incidente inicial. Se a interface não mostra a origem do julgamento, uma inferência revogável parece uma propriedade permanente do objeto RPKI.

O sistema deve preservar o resultado ROV, a observação bruta, o horário, o método, o motivo, a confiança e a identidade do avaliador. A regra local que converte o risco em mudança de Local_Pref precisa de registro próprio. Assim, retirar um julgamento não exige alterar o fato histórico de que a ROA era válida.

A correlação define quem sofre o efeito

Mesma origem, mesmo vizinho e caminho semelhante são pistas. Não são prova de controle comum. Um AS pode anunciar prefixos de clientes independentes. Um peer pode transportar muitas organizações. Padrões de AS_PATH semelhantes podem resultar da topologia normal.

O detector pode acertar o evento inicial e errar o conjunto associado. Quando a correlação gera depreference automática, esse erro passa a determinar tráfego real. Prefixos legítimos, não envolvidos no gatilho, podem ser desviados.

O rascunho pede um piso mínimo de Local_Pref e distingue redução de preferência de bloqueio explícito. Isso evita algumas formas de blackholing total, mas não garante continuidade. O caminho alternativo pode estar congestionado, custar mais, ter latência maior ou não suportar o serviço. O recibo deve registrar alternativas disponíveis, diferença aplicada, prefixos e clientes afetados, além da alcançabilidade medida antes e depois.

Segurança de transporte não é segurança de inferência

A seção de segurança reconhece que a injeção de risco falso pode virar negação de serviço. Ela exige proteção para sessões RTR, recomenda retirar a comunidade em fronteiras eBGP sem acordo bilateral e mantém um piso de preferência.

Essas barreiras autenticam o canal e limitam o alcance. Elas não provam que o conteúdo está correto. SSH ou TLS pode entregar com integridade uma avaliação produzida por sensor defeituoso. A identidade do remetente não valida sua regra de associação. Um acordo de confiança também precisa explicar auditoria, expiração e revogação.

Faltam semânticas completas para prazo, renovação, retirada, replay, recurso e override. O banco do RP precisa guardar a ligação entre o score derivado e a evidência original. Sem isso, a automação distribui o resultado, mas não distribui a capacidade de contestá-lo.

Os valores do rascunho ainda não são alocações

O Datatracker mostra apenas a versão 00 como Internet-Draft individual ativo. Não há RFC stream, Intended RFC status, endosso do IETF ou posição formal no processo de padronização.

O texto propõe os tipos RTR 0x0B e 0x0C e coloca a versão 2 no diagrama do PDU de risco. No registro atual da IANA, o tipo 11 (0x0B) já corresponde a ASPA na versão 2; o tipo 12 continua não alocado. O subtipo da comunidade BGP opaca transitiva permanece por definir, e não há entrada com o nome proposto.

Isso não equivale a uma rejeição. Significa que numeração, compatibilidade e processo ainda estão abertos. Não há base para tratar os códigos como padronizados, interoperáveis ou implantados.

A rede receptora continua responsável

A doutrina de Lu Heng separa registro de autoridade: um registro descreve realidade; não a cria. Um alerta pode ser evidência sem se tornar mandato. No DRIP, o detector observa, o RP registra e o BGP transporta. A rede que assume custo, clientes e disponibilidade precisa conservar a decisão final.

Para isso, cada efeito deve apontar para identidade e mandato do detector, observação, validação, regra de associação e confiança, proteção do sinal, escopo de propagação, política de importação, delta de preferência, alternativas, prazo, retirada, recurso, rollback e alcance medido.

O DRIP acerta ao mostrar que autorização de origem e risco operacional não são sinônimos. A solução segura é compartilhar contexto sem centralizar soberania. O rótulo só merece influenciar a rota quando a rede receptora consegue explicar por que o aceitou, por quanto tempo e como remover todo o efeito.

Fontes