Resumo

  • O maxLength de uma ROA informa o comprimento máximo que um AS pode originar; não identifica quais rotas mais específicas foram realmente aprovadas.
  • Uma autorização exata pode tornar Invalid uma desagregação legítima que não foi preparada; uma autorização frouxa pode validar um específico sem intenção operacional.
  • O controle deve vincular cada prefixo a ASN, finalidade, janela, mudança de ROA, observação, responsável pela retirada e prazo de rollback.

O agregado 203.0.0.0/16 é normalmente originado pelo AS 64496 e tem uma ROA para esse comprimento exato. Durante um ataque, a equipe anuncia 203.0.113.0/24 para levar um serviço a um provedor de mitigação. A alteração BGP foi autorizada, mas a autorização RPKI não foi preparada. Redes que executam validação de origem podem classificar o /24 como Invalid, pois ele é mais específico do que a ROA permite.

Ampliar a entrada para 203.0.0.0/16 com maxLength 24 resolve o teste imediato. Também autoriza o AS indicado a originar qualquer /24 dentro do /16: 256 blocos possíveis nesse comprimento. A ROA não sabe qual deles pertence ao incidente, quais têm serviços e quais possuem monitoração ou dono de retirada. Uma falha de coordenação pontual passa a ser tratada com uma permissão criptográfica muito maior.

A semântica do RFC 9582 é precisa. Uma ROA registra que o titular do espaço de endereços autoriza um AS a originar os prefixos listados. O elemento opcional maxLength define o maior comprimento autorizado; sem ele, somente o comprimento escrito é permitido. O objeto não inclui ordem de engenharia de tráfego, janela de mudança, ticket de incidente nem data de desativação.

O RFC 6811 também limita o significado da validação. A rota recebida é comparada com payloads ROA validados que a cobrem, com o AS de origem e com o comprimento permitido. O resultado trata da origem. Não confirma o AS_PATH completo, entrega de pacotes, vantagem da desagregação ou aprovação humana para manter o anúncio.

Autorização mínima preserva a intenção

O RFC 9319 recomenda ROAs mínimas sempre que possível: autorizar os prefixos realmente originados em BGP, não um conjunto potencial. Em geral, recomenda evitar maxLength, embora descreva situações específicas em que ele pode ser justificável. A distinção é importante. O campo é válido; usá-lo como atalho sem relação com o plano de origem é que aumenta a superfície autorizada.

Considere uma rede que anuncia o /16 e quatro /24 específicos para entrada regional. Quatro autorizações exatas tornam esse desenho visível. Uma autorização /16–24 inclui os quatro, mas também 252 outros /24 naquele comprimento. Como a validação RPKI confirma a origem e não autentica todo o caminho, um atacante pode construir um caminho falso terminado no AS autorizado e mirar um subprefixo não utilizado, porém coberto pela ROA ampla.

Objetos exatos exigem coordenação entre custódia de recursos, engenharia, segurança e fornecedor. Cada nova origem precisa chegar junto com sua autorização. Esse trabalho produz uma evidência valiosa: quem aprovou aquele prefixo, para qual finalidade e até quando.

Flexibilidade de emergência exige sequência testada

Mitigação DDoS é o caso em que exceções bem desenhadas importam. Um fornecedor pode exigir rota mais específica, outro ASN de origem ou rota de descarte baseada no destino. O RFC 9319 aborda esses casos. O cliente deve conhecer antecipadamente os requisitos exatos e testar a ordem entre a mudança RPKI e o anúncio BGP.

Primeiro são aprovados prefixo, ASN, escopo e duração. Depois a ROA é criada ou substituída e validadores independentes devem mostrar o payload esperado. A rota é anunciada em escopo controlado, seu estado e propagação são observados, e só então o alcance aumenta. Ao encerrar o evento, retira-se o anúncio, confirma-se seu desaparecimento e remove-se a autorização temporária conforme o plano.

Repositório RPKI, coleta do validador, entrega do resultado ao roteador e propagação BGP não convergem no mesmo instante. Os RFCs públicos também não provam como cada rede trata Invalid. Por isso o RFC 7115 enquadra a validação como implantação de política operacional: observar efeitos, entender exceções locais e aplicar consequências gradualmente.

Fontes