Resumo

  • A revisão 05, de 1º de outubro, do Internet-Draft do grupo SAVNET distingue o provisionamento feito pelo operador da aquisição de informações pelo sistema de roteamento. Para prefixos BYOIP ou obtidos de outro provedor, o operador deve pedir ao cliente a identificação dos prefixos e evidência de autorização para usá-los como origem, mesmo que não exista rota configurada ou anunciada.
  • O documento continua em elaboração, com intenção informativa, sem status de RFC aprovado. Não institui um formato obrigatório de prova, novo protocolo entre ASes, aprovação centralizada ou descarte automático de pacotes. O avanço concreto está na ligação entre autorização do cliente, interfaces de acesso e regras SAV.

O filtro vê um pacote chegando por uma interface. Sua tabela de rotas, por sua vez, mostra possibilidades de encaminhamento a destinos. Essas duas observações não respondem à mesma pergunta. Um cliente conectado a mais de um roteador pode empregar um prefixo em ambas as entradas; outro prefixo pode ser legítimo como origem sem aparecer na informação de roteamento relevante. Aceitar qualquer origem porque existe uma rota é permissivo demais. Recusar toda origem sem rota também pode bloquear tráfego autorizado.

A revisão de junho da arquitetura já reconhecia roteamento assimétrico, prefixos ocultos e a insuficiência de inferir autorização apenas de rotas. Também descrevia o agente SAV que produz regras. A versão 05 não deve receber crédito por inventar o problema. Ela torna mais explícitas as maneiras de alimentá-lo: o operador pode reutilizar cadastro de clientes, alocação de endereços e configuração; o agente também pode obter dados do sistema de roteamento. As abordagens se combinam, mas uma autorização ausente das rotas precisa vir do provisionamento.

O parágrafo sobre BYOIP dá consequência prática a essa separação. Quando o prefixo foi trazido pelo cliente ou obtido de outro provedor, o AS que recebe os pacotes deve exigir que o cliente o declare e comprove a autorização para colocá-lo no campo de origem. Essa autorização precisa ser representada mesmo sem anúncio de rota. O texto não determina que um ROA, registro externo ou outro documento isolado seja prova suficiente em todos os casos. Cabe ao operador ligar a evidência aceita à relação com o cliente e aos pontos onde aplicará as listas permitidas.

No exemplo da revisão, C conecta-se pelas interfaces i1 e i2. P1 e P2 aparecem em informações de roteamento apropriadas; H é um prefixo oculto, usado apenas como origem. Se C pode usar os três, as regras das duas interfaces precisam contemplá-los. H exige registro explícito porque o roteamento não o fornece. Mudanças de atribuição, autorização ou associação entre cliente e interface devem chegar às regras afetadas. O cenário mostra alternativas de aquisição da mesma informação, não um teste de campo nem economia comprovada de operação.

A arquitetura recomenda listas de permissão, mas alerta que entradas incompletas podem causar bloqueios indevidos. A reação a um pacote classificado como inválido é política local: um operador pode observar, registrar ou limitar antes de descartar estritamente. O projeto não especifica algoritmo nem impõe onde o agente SAV deve rodar. Datatracker ainda o apresenta como documento do grupo em estado I-D Exists. A questão de governança é simples de formular e trabalhosa de demonstrar: qual evidência justificou permitir este prefixo nesta interface, e quando a alteração virou regra efetiva?

Fontes