Quem controla a ROA em uma locação IPv4?

Resumo

Uma Route Origin Authorization (ROA) é uma declaração assinada de que um sistema autônomo nomeado pode anunciar determinados prefixos. Ela não é uma transferência de propriedade, nem uma instrução para roteadores, nem uma garantia de que a rota é segura, nem uma prova de que o AS nomeado ainda está autorizado no âmbito de uma locação privada.
Na maioria das locações, o locador permanece como titular direto do recurso e, portanto, está mais próximo da cadeia de certificação RPKI. O locatário opera a rede e sabe quais ASes de origem e rotas mais específicas são operacionalmente necessárias. O upstream anuncia ou filtra a rota. O RIR opera uma âncora de confiança ou um serviço de certificação superior. Esses são poderes distintos.
RPKI hospedado e delegado alteram a custódia e a execução, não o negócio subjacente. Um serviço hospedado coloca as operações de chave e a publicação em um RIR; um serviço delegado permite que o titular opere uma CA e, normalmente, sua chave privada. Nenhum dos dois acordos concede ao locatário direitos imediatos por si só ou o protege contra uma exclusão contestada.
Cada locação deve incluir um plano de autorização que especifique os prefixos exatos, ASes de origem permitidos, comprimentos máximos, janelas de início e fim, o prazo para alterações comuns, o prazo de emergência, aprovadores, canais de autenticação e registros a serem mantidos. Uma promessa genérica de emitir uma certificação de autorização não é suficiente.
O tempo contratual e o tempo RPKI devem ser conscientemente alinhados. Serviços hospedados podem renovar objetos assinados automaticamente, caches são atualizados em seu próprio ritmo, e uma rota pode permanecer visível após o término do prazo comercial. Portanto, um vencimento à meia-noite não é nem uma revogação técnica imediata nem uma razão segura para excluir a única ROA válida antes que o tráfego seja migrado.
O acesso de emergência deve ser restrito e redundante. Um locatário precisa de uma maneira de adicionar rapidamente uma origem de mitigação de DDoS ou substituta pré-aprovada, enquanto o locador precisa de limites que impeçam a delegação ilimitada. Aprovação mútua, prefixos limitados, poderes de emergência de curta duração, registros independentes e uma revisão pós-incidente podem atender a ambos os requisitos.
Uma disputa comercial não deve ser travada surpreendendo o sistema de roteamento global. Exceto em uma emergência de segurança ativa, a exclusão da ROA deve seguir um aviso, uma breve janela de continuidade, uma escalada independente e uma retirada coordenada da rota. A revogação final deve ser segura; o caminho até ela não deve transformar clientes em ferramentas de pressão.

A locação separa uso da certificação

A questão incômoda em uma locação IPv4 não é de quem é o roteador. Trata-se de quem pode emitir a declaração criptográfica na qual outros roteadores podem confiar.

O locatário pode configurar o AS de origem, anunciar o prefixo, atender clientes, responder a notificações de abuso e pagar os custos de trânsito. No entanto, se o prefixo permanecer certificado pelo locador, o locatário pode não conseguir criar, modificar ou excluir a ROA que descreve seu próprio anúncio ativo. O locador pode ser economicamente passivo e tecnicamente decisivo. Uma conta de portal esquecida ou um signatário indisponível pode transformar uma alteração de roteamento de rotina em um risco de interrupção.

Isso não torna a locação defeituosa. Significa que uma locação está entre dois sistemas de autoridade. O direito contratual determina o que uma parte prometeu à outra. O RPKI determina se uma autorização assinada pode ser validada por uma cadeia enraizada na hierarquia de recursos numéricos. O BGP determina quais caminhos as redes realmente anunciam e selecionam. Os contratos de trânsito estabelecem o que um upstream aceita. Nenhum desses sistemas lê automaticamente os outros.

RFC 9582define uma ROA como um objeto assinado pelo qual um titular de bloco de endereços autoriza um AS a originar rotas para um ou mais prefixos. A seção de segurança é incomumente útil para governança: o RPKI fornece autorização, não autenticação de identidade ou não repúdio. O objeto prova que um caminho de certificação válido apoiou a declaração quando foi processada por partes confiáveis. Ele não publica a locação, o preço, o cliente, o beneficiário efetivo, o motivo da rota ou o prazo no contrato comercial.

Essa distinção refuta dois simplificadores comuns. O primeiro é que a parte que pode criar a ROA deve ser o proprietário efetivo. Isso não decorre daí. O segundo é que a parte listada como origem na ROA deve controlar os direitos de endereço. Também não decorre. Um titular pode autorizar o AS de um cliente, um upstream, uma rede em nuvem ou um provedor de mitigação de DDoS sem transferir o recurso. O objeto assinado é intencionalmente mais restrito do que o relacionamento circundante.

A pergunta correta, portanto, não é simplesmente: “Quem controla a ROA?” É um conjunto de perguntas: Quem pode solicitar uma alteração? Quem decide que a solicitação está dentro do escopo da locação? Quem opera o sistema de assinatura? Quem pode interromper uma alteração insegura? Quem pode agir quando a parte principal não está disponível? Quem arca com a perda se uma alteração prometida está atrasada? Quem deve remover a autorização quando o direito de anunciar a rota termina?

Uma locação que responde apenas à primeira pergunta deixa o resto para a improvisação.

Quatro atores detêm quatro tipos diferentes de poder

Locador, locatário, upstream e CA do RIR são frequentemente descritos como pontos em uma única cadeia de comando. Eles são melhor compreendidos como quatro atores com poder sobreposto, mas não idêntico.

O locador geralmente mantém o relacionamento registrado do qual a certificação de recurso é derivada. Em um serviço RPKI hospedado, um usuário autorizado da organização do locador pode criar configurações de ROA por meio da interface do RIR. Em um acordo delegado, o locador pode operar sua própria CA e possuir a chave privada correspondente. A capacidade crítica do locador é a certificação: ele pode fazer com que uma declaração sobre um prefixo e um AS de origem seja adicionada ou removida do conjunto RPKI validado.

O locatário possui conhecimento operacional. Ele conhece a origem pretendida, o design upstream, o estado da migração do cliente, rotas mais específicas de engenharia de tráfego, acordos de mitigação de DDoS e a data em que uma nova rota precisa funcionar. Sua capacidade crítica é a utilização: ele ou seus provedores podem configurar e originar anúncios BGP. Essa capacidade pode persistir mesmo quando a rota se torna RPKI Invalid, pois o RPKI não desliga o BGP. As consequências práticas dependem de quais redes aplicam a validação de origem de rota e como.

O upstream tem poder de aceitação e propagação. Ele pode exigir uma certificação de autorização, um objeto IRR, uma ROA correspondente, evidências contratuais ou uma combinação. Ele pode construir filtros de prefixo de cliente a partir de seus próprios registros, de um IRR, de dados RPKI validados ou de verificação manual. Ele pode rejeitar uma rota de outra forma válida porque o relacionamento com o cliente não foi verificado, ou pode transportar uma rota Not Found de acordo com sua política. Uma ROA válida é uma evidência relevante, não uma instrução para o upstream.

O CA do RIR está na hierarquia de certificação.RFC 6480descreve uma arquitetura alinhada com a alocação de recursos numéricos. Os serviços do RIR emitem ou mantêm o certificado de recurso pai, hospedam a assinatura para muitos titulares, publicam material e vinculam alterações em recursos certificados à hierarquia. O RIR não é parte na maioria das locações e geralmente não conhece seus termos comerciais completos. Seu sistema pode autenticar a conta do titular e validar a cobertura de recursos sem saber se uma fatura do locatário está em disputa.

Esses poderes não devem ser agrupados. A capacidade de um locador excluir uma ROA não significa que ele deva controlar o roteador do locatário. A capacidade de um locatário enviar um anúncio não significa que ele deva ter poder de assinatura ilimitado sobre o agregado do locador. O filtro de um upstream não governa a locação. O certificado de um RIR não decide sobre o uso econômico.

Uma boa governança começa com o reconhecimento de que nenhum ator individual tem visão total do relacionamento.

Uma ROA autoriza uma origem, não uma rota em todas as suas dimensões

A estreiteza da ROA é uma força, mas torna-se perigosa quando os contratos a interpretam de forma muito ampla.

Uma ROA identifica um AS de origem e um ou mais prefixos. Pode incluir um comprimento máximo que permite anúncios mais específicos. Se vários ASes estiverem autorizados a anunciar o mesmo prefixo, são necessárias ROAs separadas. O objeto não especifica qual upstream pode transportar a rota, qual caminho AS é aceitável, se a origem tem um contrato de serviço atual, qual tráfego de cliente pertence aos endereços ou se um anúncio é esperado geograficamente.

É por isso que uma “locação compatível com RPKI” pode ocultar mais do que revela. Um locador pode criar uma ROA tecnicamente válida para a ASN de uma parte comercial errada. Um locatário pode continuar anunciando pela origem autorizada após o término de um contrato de serviços. Um AS autorizado pode vazar acidentalmente ou intencionalmente um anúncio mais específico permitido por um comprimento máximo muito amplo. Uma rota pode ser RPKI Valid e ainda assim operacionalmente incorreta ou abusiva.

RFC 6483adverte que uma ROA pode afetar outros anúncios que envolvam o mesmo espaço de endereço: rotas de origens não listadas ou rotas mais específicas além do comprimento permitido podem se tornar Invalid. Recomenda considerar todas as origens legitimamente autorizadas e rotas mais específicas relevantes.RFC 7115trata a validação de origem também como uma entrada operacional, não como um julgamento universal de seleção de rota.

Para uma locação, isso significa que o plano não pode simplesmente dizer: “O locador criará uma ROA.” Ele deve especificar os pares prefixo-origem exatos e explicar a política para rotas mais específicas. Se um /20 for anunciado apenas como /20 a partir da ASN do locatário, um comprimento máximo desnecessariamente generoso não deve ser concedido por conveniência. Se o locatário precisar de anúncios /24 de duas origens durante a migração, ambas as origens e o período temporário devem ser explícitos.

O papel do upstream permanece separado. Asações MANRS para operadores de redeexigem que os operadores garantam a correção de seus próprios anúncios e de clientes, mantenham contatos utilizáveis e publiquem informações que outros possam validar. Um provedor de trânsito que apenas verifica se uma ROA existe não está cumprindo essa tarefa. Ele ainda precisa saber que seu cliente é a parte autorizada a contratá-lo para transportar a rota.

A locação deve, portanto, prometer vários fatos coordenados, não um status mágico: permissão comercial do locador, instrução operacional do locatário, autorização de origem no RPKI, informações de roteamento precisas e aceitação pelo upstream pretendido.

RPKI hospedado concentra a execução na conta do titular

O RPKI hospedado é atraente porque remove a maior parte do gerenciamento criptográfico do titular do recurso. Essa conveniência também destaca onde está a dependência da locação.

Oguia para CA hospedada do RIPE NCCafirma que o serviço hospedado assina, publica e renova objetos ROA a partir de configurações gerenciadas por uma conta autorizada. O usuário gerencia as informações de origem e prefixo pretendidos; o serviço cuida das chaves, renovação de objetos e publicação. Adocumentação do RPKI hospedado da ARINtambém coloca a CA e a assinatura na ARIN e afirma que organizações downstream devem contratar seu provedor upstream para enviar ROAs em seu nome se não puderem participar diretamente.

Para um locador, o serviço hospedado pode reduzir falhas operacionais. Não há repositório de CA privado que o locatário precise monitorar, nem chave de assinatura colocada em um laptop de funcionário. Para um locatário, no entanto, o gerenciamento de contas torna-se a questão central. Quais pessoas no locador podem aprovar uma solicitação? Há cobertura 24 horas? O locatário pode receber uma função restrita ou cada alteração deve ser transmitida pelo titular? O que acontece se a conta do locador for bloqueada durante uma verificação de identidade, mudança corporativa ou disputa?

Os acessos ao portal não devem ser compartilhados levianamente. Dar ao locatário as credenciais gerais do locador pode expor prefixos não relacionados, outros clientes e ações destrutivas. Também confunde a atribuição: o locador pode não conseguir determinar depois se foi seu funcionário, contratado ou cliente que fez a alteração. Mesmo que uma interface suporte vários usuários, a autorização deve ser limitada à organização e às tarefas que cada pessoa pode executar.

O modelo hospedado mais seguro trata o locatário como solicitante autenticado e o locador como aprovador limitado. As solicitações usam um canal definido, identificam a locação e os prefixos, contêm a origem proposta e o comprimento máximo, e recebem um registro de transação. As alterações rotineiras têm um prazo de serviço. As alterações de emergência usam um canal mais rápido com autenticação separada. Duas pessoas no locador devem ser capazes de agir, e o locatário deve ter pelo menos dois solicitantes aprovados.

A automação pode reduzir atrasos, mas deve impor o plano de autorização, não contorná-lo. Uma solicitação para um prefixo listado, uma ASN listada e o comprimento máximo permitido pode ser elegível para aprovação rápida. Uma solicitação para autorizar uma ASN desconhecida ou um intervalo mais específico mais amplo deve ser pausada para revisão humana. A diferença está em automatizar uma promessa conhecida versus estender a promessa silenciosamente.

O serviço hospedado resolve a operação de chave. Ele não resolve a delegação comercial, a menos que o contrato e as funções de conta o façam.

RPKI delegado move a chave, não o relacionamento pai

O RPKI delegado pode dar a um titular de recurso mais autonomia técnica. Também pode criar a crença equivocada de que o titular escapou de qualquer dependência upstream.

Acomparação de serviços hospedados e delegados do RIPE NCCafirma que um operador delegado controla seu certificado de recurso e chave privada correspondente e pode escolher onde publicar. Asopções de implantação da ARINindicam que um titular direto pode operar sua própria CA, assinar ROAs e emitir certificados de recurso para clientes no modo delegado. O APNIC também identifica o modo auto-hospedado como RPKI delegado em seumaterial de certificação de recursos.

Essa arquitetura pode suportar uma divisão mais direta. Um locador experiente pode operar uma CA pai e emitir um certificado de recurso filho limitado aos prefixos do locatário. O locatário pode então assinar objetos dentro desse conjunto limitado, sem obter autoridade sobre os outros recursos do locador. No final da locação, o locador pode revogar o certificado filho ou deixá-lo expirar de acordo com a ordem acordada.

A aparente elegância traz deveres operacionais. Alguém deve proteger a chave privada, manter a CA, publicar objetos atuais, gerenciar manifestos e informações de revogação, monitorar a disponibilidade, rodar chaves e preservar acessos de recuperação. Apolítica do RIPE NCC para CAs delegadas persistentemente não funcionaisilustra as consequências de uma falha prolongada: após uma incapacidade prolongada de descobrir e validar material atual, o pai pode revogar o certificado de recurso delegado. Delegação é controle combinado com manutenção, não uma transferência única.

O relacionamento pai também persiste. Um certificado delegado existe dentro de uma hierarquia. Se os recursos certificados mudarem ou o certificado pai for revogado, a autoridade filha é afetada.RFC 8211examina ações adversas ou errôneas de CAs e gerenciadores de repositórios, justamente porque a propriedade local de uma chave não elimina dependências hierárquicas e de publicação.

Para muitos locatários, operar uma CA seria desproporcional. Para grandes operadores com mudanças de origem frequentes, múltiplos upstreams ou requisitos rigorosos de continuidade, uma delegação limitada pode valer o custo. A escolha deve depender da frequência de mudanças, tolerância a falhas, capacidade de pessoal e design do portfólio do locador, não do prestígio de possuir uma chave.

Mais importante, o RPKI delegado não deve se tornar uma concessão permanente informal. Os recursos filhos, a validade do certificado, a regra de renovação, eventos de revogação, deveres de repositório, contatos de emergência e a prova de destruição ou transferência na saída pertencem todos à locação. Mover a chave privada para mais perto do locatário reduz um atraso, mas aumenta a importância de um término disciplinado.

O plano de autorização é o instrumento comercial ausente

O acordo principal pode estabelecer o negócio econômico. Um plano de autorização separado deve estabelecer o negócio de segurança de roteamento em termos que tanto um engenheiro quanto um advogado possam revisar.

O plano começa com CIDRs exatos. Em seguida, lista cada AS de origem permitido, a entidade legal que controla esse AS, o relacionamento de trânsito ou hospedagem pretendido e o comprimento de prefixo permitido para cada anúncio. Se várias origens forem temporárias, o plano fornece datas de início e remoção. Se o locatário puder usar um provedor de mitigação de DDoS, sua ASN pode ser pré-aprovada sem ser ativada até um incidente.

Em seguida, vêm as funções. Nomeie o responsável pelo serviço do locador e o aprovador substituto, o líder de rede do locatário e o solicitante substituto, e os contatos em cada upstream pretendido. Use endereços de função e canais autenticados, não apenas funcionários nomeados. Funcionários vão e vêm; a autorização deve sobreviver sem deixar contas pessoais desatualizadas.

O plano então define prazos. Uma solicitação normal pode exigir conclusão dentro de um dia útil. Uma migração planejada pode exigir um aviso prévio de cinco ou dez dias úteis. Uma falha grave pode exigir resposta em quinze minutos e uma alteração limitada em sessenta minutos. Os números exatos dependem do serviço, mas silêncio não é um nível de serviço.

O registro de alteração deve incluir o horário da solicitação, o solicitante autenticado, o prefixo afetado, a origem antiga e nova, o comprimento máximo, o motivo comercial, a aprovação, a observação de publicação e a observação de validação. Isso não é burocracia por si só. Se uma rota se tornar Invalid, as partes precisam saber se a ROA nunca foi alterada, foi alterada mas ainda não está visível, foi alterada incorretamente ou foi invalidada por outra ROA sobreposta.

Finalmente, especifique quais solicitações o locador pode recusar. Uma solicitação fora do prefixo locado, uma ASN não controlada por um operador aprovado, um comprimento máximo mais amplo que o design de roteamento acordado, ou uma alteração que invalidaria as rotas de outro cliente podem exigir alteração em vez de execução imediata. Uma recusa deve ser motivada e carimbada com data/hora, não uma vaga apelação à segurança.

O plano deve ser versionado com assinaturas ou aceitação autenticada equivalente. O conjunto ativo de ROAs deve ser comparado a ele na ativação, após cada alteração aprovada, na revisão periódica e antes do término. O acordo tem então uma resposta mensurável ao controle: o locador controla a certificação dentro de um mandato pré-acordado; o locatário controla as solicitações operacionais dentro do mesmo mandato; nenhum pode aumentar silenciosamente o risco da outra parte.

Tempo contratual e tempo RPKI são relógios diferentes

Locações usam datas porque datas são legíveis para tribunais e equipes financeiras. A segurança de roteamento opera por publicação e recuperação, que raramente compartilham o mesmo limite.

Uma locação pode começar na segunda-feira às 00:00 UTC. A ROA pode ser criada mais cedo para que os caches das partes confiáveis possam baixá-la antes do primeiro anúncio. Um serviço hospedado pode renovar o objeto assinado automaticamente enquanto sua configuração permanecer ativa. Quando a locação termina, o direito comercial pode expirar, embora a autorização publicada mais recentemente permaneça válida e visível. Por outro lado, excluir a configuração à meia-noite não prova que toda parte confiável removeu os dados validados correspondentes à 00:01.

O contrato, portanto, precisa de três momentos em vez de um. O momento de prontidão da autorização é quando a rota pretendida tem uma autorização válida visível e o upstream confirmou seus filtros. O momento de uso do serviço é quando o locatário pode anunciar e colocar tráfego de cliente no prefixo. O momento de fim da autorização é quando a origem antiga não deve mais ser apresentada como permitida no RPKI, depois que o tráfego foi retirado.

Esses momentos podem se sobrepor sem contradição. Uma ROA pode ser preparada antes do uso comercial, desde que o locatário esteja proibido de anunciar precocemente. Ela pode persistir brevemente durante uma retirada ordenada, desde que o locatário esteja proibido de adicionar novos clientes e deva reduzir o tráfego. A autorização remanescente é capacidade de transição controlada, não uma extensão da vida econômica da locação.

Isso também explica por que a expiração de uma ROA é um substituto pobre para o término. Uma vida útil longa de certificado ou objeto pode ultrapassar a locação. Uma vida útil curta pode criar riscos de renovação evitáveis durante a vigência. Sistemas hospedados podem renovar bem antes da expiração, enquanto sistemas delegados dependem da operação local. O evento determinante deve ser uma instrução explícita de término, apoiada por observação, não a esperança de que um timer coincida com o negócio.

O desalinhamento reverso também é importante. Se um locador exclui a ROA antes que os endereços substitutos ou a origem alternativa do locatário estejam prontos, redes que rejeitam rotas Invalid podem parar de transportar tráfego. Os clientes sofrem a interrupção, mesmo que o locador esteja contratualmente correto sobre a data de término. Se ele nunca excluir, o ex-locatário mantém uma possibilidade mais fraca, mas real, de originar uma rota que alguns validadores considerarão autorizada.

A coordenação de tempo não é, portanto, indulgência. É a disciplina de fazer a autorização aparecer antes da dependência e desaparecer depois, com o mínimo de sobreposição incerta que o serviço possa tolerar.

Direitos de alteração de emergência devem ser projetados antes da emergência

O teste mais revelador para a governança de ROA não é uma migração planejada. É uma falha no sábado, quando a origem aprovada não pode transportar tráfego e o único engenheiro que normalmente assina alterações está dormindo ou inalcançável.

Uma emergência pode exigir um novo provedor de trânsito, uma ASN de mitigação de DDoS, um data center de backup, uma origem substituta após uma falha de roteador, ou um anúncio mais específico temporário. Também pode envolver credenciais RPKI comprometidas ou uma autorização acidental que torna rotas legítimas Invalid. A parte que observa o incidente pode ser o locatário, o upstream, o locador ou uma rede externa.

A locação deve pré-autorizar categorias, não permitir ação ilimitada. Uma lista de ASNs de espera pode ser verificada na assinatura. Um comprimento máximo de prefixo de emergência pode ser definido. O locatário pode ter permissão para ativar apenas os prefixos que loca e apenas por um curto período. Qualquer alteração mais ampla requer um aprovador adicional. Isso dá velocidade ao operador sem lhe dar um cheque em branco permanente.

A autenticação deve sobreviver ao mesmo incidente. Se as solicitações comuns dependem de um domínio de e-mail hospedado atrás do prefixo afetado, o canal pode falhar quando necessário. Use pelo menos um método fora da banda e mantenha contatos em ambas as organizações. O locador deve exigir um código de solicitação, uma função nomeada, um retorno de chamada ou uma aprovação criptográfica proporcional ao risco das partes. Trata-se de resistir a roubo de identidade sem transformar a verificação de identidade em uma barreira de várias horas.

A alteração em si deve ser reversível. Adicione a origem mais restrita necessária; não expanda ROAs não relacionadas. Defina um prazo de expiração ou revisão para a autorização de emergência. Confirme que a nova rota é observada e aceita antes de retirar o caminho antigo. Após o incidente, remova a autorização temporária e reconcilie o conjunto ativo com o plano.

A responsabilidade deve seguir atrasos controláveis. Se o locatário não manteve contatos aprovados ou solicitou uma ASN não listada sem comprovação, ele deve arcar com essa consequência. Se o locador perdeu um prazo de emergência acordado apesar de uma solicitação válida, um crédito de taxa por si só pode não refletir a perda do cliente; o acordo pode precisar de um limite de danos, um direito de rescisão ou o direito de passar para uma delegação limitada. Se o upstream rejeitou uma rota apesar de receber todas as evidências necessárias, seus termos de serviço se aplicam separadamente.

Os direitos de emergência raramente devem ser exercidos. Seu valor está em cada parte conhecer o caminho sob pressão, não em o locador se tornar um interruptor de roteamento 24 horas para alterações rotineiras.

Comprimento máximo é uma decisão de risco comercial

O campo de aparência mais técnica em uma ROA pode ter grandes consequências comerciais.maxLengthdetermina quão específico um anúncio do AS autorizado pode ser permanecendo consistente com essa ROA.

Uma autorização muito restrita pode invalidar uma rota legítima de engenharia de tráfego ou mitigação de DDoS. Uma muito ampla pode permitir anúncios mais específicos que nunca foram necessários para a locação. A decisão afeta o isolamento de falhas, a prática upstream e o escopo de rotas que os validadores podem aceitar como autorizadas.

O erro de design comum é definir o máximo para cada agregado IPv4 locado como /24, porque /24 é geralmente aceito na tabela global. Isso pode ser operacionalmente conveniente, mas delega mais autoridade do que um locatário que anuncia apenas um agregado precisa. Se um /19 for sempre originado como /19, um máximo de /24 cria espaço para 32 rotas mais específicas separadas, sem explicação do motivo.RFC 9582diz que o campo deve ser omitido se for igual ao comprimento do prefixo, e define como ele limita a autorização de rotas mais específicas.

O erro oposto é autorizar apenas o agregado quando o design documentado do locatário depende de rotas mais específicas. Um provedor de limpeza de emergência pode anunciar /24s. Uma migração entre duas origens pode dividir temporariamente um agregado. Se o contrato ignorar esse design, o locatário solicitará uma alteração urgente no pior momento.

O plano de autorização deve corresponder ao menor conjunto de rotas esperadas, não ao conjunto tecnicamente mais amplo possível. Onde vários /24s de origens diferentes são esperados, ROAs explícitas podem tornar a divisão visível. Onde um máximo temporariamente mais amplo é justificado, deve ter uma data de término e um motivo.

Isso também é uma questão de portfólio para locadores. Uma ROA sobreposta ampla pode interagir com locações mais específicas abaixo. Antes de aprovar uma alteração, o locador deve verificar se uma rota válida de outro cliente se tornaria Invalid devido a uma autorização sobreposta com origem diferente ou um máximo restritivo. O inventário do locador deve, portanto, entender sobreposições, não apenas linhas de locação.

O princípio comercial é o privilégio mínimo. O locatário recebe permissão criptográfica suficiente para operar a rede acordada, incluindo resiliência realista a falhas. O locador não retém um veto artificial sobre operações documentadas, mas também não publica permissão mais ampla do que o negócio.

O upstream é um controle independente, não um mensageiro

Provedores de trânsito são frequentemente tratados como o ponto de saída final para uma certificação de autorização. Em uma locação madura, eles devem ser envolvidos mais cedo.

Antes da ativação, o upstream pretendido deve confirmar os prefixos exatos e a ASN de origem que aceitará, as evidências necessárias, o tamanho mínimo de rota, o tratamento de rotas mais específicas, se ele constrói filtros a partir de dados IRR ou RPKI, e a rapidez com que esses filtros são atualizados. Essa confirmação pertence ao lado do plano de ROA, pois uma autorização tecnicamente correta tem pouco valor operacional se o filtro de cliente do upstream ainda rejeitar a rota.

O upstream deve autenticar seu cliente de forma independente. Uma ROA válida pode mostrar que uma cadeia de certificação autoriza a ASN de origem para um prefixo. Ela não prova que a pessoa que abre um ticket de trânsito controla essa ASN ou que o locador aprovou a conta comercial. Uma certificação de autorização pode conectar as partes, mas cartas são fáceis de encaminhar e difíceis de revogar globalmente. Dados de conta, contatos verificados e confirmação direta do locador tornam a evidência mais forte.

Durante a locação, o upstream não deve aceitar uma alteração de origem simplesmente porque uma nova ROA apareceu. A alteração pode ser acidental, maliciosa ou destinada a outro provedor. Ele também não deve ignorar um novo status Invalid. Ele deve contatar o locatário e o locador por canais conhecidos, comparar a rota com a lista de prefixos acordada e determinar se a rota ou a autorização está incorreta.

No término, o upstream tem um papel crítico para tornar a revogação real. O locador pode remover uma ROA, mas o ex-locatário ainda pode enviar o anúncio BGP. O upstream pode remover a permissão de prefixo do cliente e rejeitar a rota em seu limite direto. Essa ação local é frequentemente mais rápida e segura do que esperar que toda rede aplique dados de validação atualizados.

Essa divisão é saudável. O RPKI fornece autorização de origem globalmente verificável. O upstream aplica o relacionamento com o cliente mais próximo da fonte. A locação conecta ambos. Nenhum deve ter que suportar a carga inteira.

Um upstream que suporta prefixos locados pode publicar seus requisitos de evidência e caminhos de contato de emergência. Previsibilidade torna a locação segura mais fácil. Verificações secretas e inconsistentes levam os operadores a solicitações de última hora e exceções informais, enfraquecendo tanto a segurança quanto a responsabilidade.

Disputas devem ser isoladas do tráfego do cliente

A cláusula mais difícil trata do caso em que locador e locatário discordam sobre dinheiro, violação de contrato, abuso ou renovação, enquanto o prefixo ainda transporta serviços ativos.

O locador pode temer que uma fase de continuidade recompense o não pagamento ou permita danos. O locatário pode temer que o locador use a exclusão da ROA como um interruptor remoto de desligamento. Ambas as preocupações são legítimas. A resposta não pode ser autorização permanente, mas também não deve ser uma emboscada criptográfica não anunciada.

Comece distinguindo eventos. Um término planejado e uma não renovação comum devem seguir o plano de saída completo. Uma fatura contestada deve acionar uma notificação e um curto período de cura, a menos que o acordo torne o pagamento claramente imediato e crítico. Indícios críveis de abuso ativo podem justificar controles mais rigorosos, mas remover uma ROA não necessariamente interrompe a rota abusiva; o upstream direto e o equipamento do locatário permanecem pontos de intervenção mais próximos. Uma chave de assinatura comprometida exige ação de segurança, mesmo que o relacionamento comercial esteja intacto.

Durante uma disputa real, extensões discricionárias devem ser congeladas. O locatário não deve adicionar clientes, solicitar novas origens ou expandir comprimentos máximos. O locador deve preservar as últimas autorizações seguras conhecidas para o período de continuidade limitado. Ambas as partes devem notificar o upstream de que nenhuma alteração é válida sem dupla confirmação, exceto em uma emergência documentada para proteger o tráfego.

Um contato de escalada independente pode determinar se uma solicitação se enquadra no plano existente sem decidir toda a disputa legal. A questão é restrita: a ação solicitada preserva um serviço já autorizado ou expande direitos? Essa determinação limitada pode manter o roteamento estável enquanto as reivindicações comerciais são buscadas em outro lugar.

O acordo também deve definir uma parada definitiva. A continuidade não pode se tornar uma ocupação indefinida. No final do período de cura ou migração, o locatário deve retirar as rotas, o upstream deve remover os filtros, e o locador deve remover a ROA. A falha de uma parte leva a evidências e remédios definidos. Se a segurança do cliente exigir uma ordem judicial ou medidas emergenciais provisórias, as partes sabem quais ações precisam ser interrompidas.

Registros são mais importantes aqui. Uma parte que alega exclusão ilegal deve ser capaz de apresentar a autorização acordada, a solicitação, a confirmação, o horário da alteração e o impacto na validação. Um locador que alega uso continuado deve ser capaz de apresentar observações de rota após o prazo de retirada. O isolamento de disputas funciona apenas se os fatos puderem ser reconstruídos sem confiar na caixa de entrada de uma parte.

A norma orientadora é simples: Não transforme usuários da internet não envolvidos em mecanismo de execução para dívidas privadas, e não use a dependência deles para tornar uma locação indefinida.

Revogação é necessária, mas exclusão não é remédio completo

Uma locação deve terminar com o ex-locatário não podendo mais confiar na autorização do locador. Isso requer revogação ou remoção no nível apropriado. Também requer mais do que apenas revogação.

Quando o momento de fim da autorização é atingido, o locador deve remover ou alterar a configuração da ROA correspondente. Em acordos delegados, ele pode revogar o certificado filho limitado, após confirmar que nenhuma autorização contínua é necessária. As partes devem observar os dados validados resultantes de mais de um ponto de observação independente. Uma mensagem de sucesso no portal é evidência de uma ação submetida, não prova de que o estado público convergiu.

Ao mesmo tempo, o locatário deve retirar a rota BGP, e seus upstreams devem remover a permissão de cliente. Objetos de rota IRR que ainda listam a origem antiga devem ser excluídos ou atualizados. DNS reverso e contatos públicos não devem mais referenciar um operador antigo se isso desviar notificações operacionais ou de abuso. Esses sistemas têm diferentes tempos de atualização e responsáveis, portanto um único timestamp não pode provar saída completa.

A exclusão também pode ter danos colaterais. Uma ROA pode cobrir vários prefixos, e um certificado delegado pode conter recursos além de uma locação se o locador o projetou mal. O operador deve identificar o objeto ou autorização exata a ser alterada. “Revogue o RPKI do cliente” não é uma instrução segura, a menos que o limite de certificação coincida com o limite do cliente.

O risco residual existe em ambas as direções. Se a ROA persistir, o ex-locatário mantém uma vantagem de validação se continuar anunciando. Se a ROA desaparecer enquanto uma rota desatualizada persistir, a rota pode se tornar Invalid e ser rejeitada de forma desigual, levando a acessibilidade parcial em vez de silêncio universal. Se nenhuma ROA substituta persistir, a rota pode se tornar Not Found e continuar sendo propagada sob muitas políticas. O status RPKI não é, portanto, um substituto confiável para a retirada na fonte.

Um relatório de encerramento deve registrar: rota retirada da origem antiga; filtros upstream removidos; ROA antiga ausente ou substituída; nenhuma autorização sobreposta não intencional remanescente; certificado delegado fechado, se aplicável; entradas IRR reconciliadas; e monitoramento continuado por um período de observação definido. Exceções devem ser nomeadas, em vez de arredondadas para “concluído”.

Revogação protege o locador e o próximo usuário. Retirada coordenada protege os clientes atuais. Uma saída responsável faz ambas.

O RIR deve autenticar a autoridade de certificação, não decidir a locação

Os RIRs ocupam uma posição sensível porque o serviço hospedado pode torná-los o local onde uma alteração contestada é executada. Isso não significa que eles devam se tornar tribunais para cada locação IPv4.

O RIR tem um interesse legítimo em autenticar a organização autorizada a usar seu serviço de certificação, proteger contas, manter a hierarquia e responder a comprometimento comprovado de credenciais. Pode precisar ajustar recursos certificados após uma transferência, devolução ou mudança de registro. A documentação hospedada do RIPE NCC indica que os certificados de recurso são atualizados quando os recursos são movidos, e as ROAs publicadas são ajustadas quando os recursos são removidos. Essas são consequências da hierarquia de certificação.

Uma disputa de locação privada é diferente. O RIR geralmente não possui o contrato, o histórico de pagamentos, os fatos de migração de clientes e as evidências exigidas pela lei aplicável para decidir qual parte está em violação contratual. Se aceitar instruções não suportadas de um locatário, pode substituir a autoridade do titular. Se tratar cada instrução do titular como conclusiva apesar de uma ordem judicial ou comprometimento de conta comprovado, pode ampliar o dano. A resposta é um papel restrito com processo claro.

O RIR pode manter registros, autenticar titulares de conta, publicar status de serviço, fornecer canais de emergência documentados para incidentes de segurança e cumprir ordens legais válidas. Pode tornar as funções de conta tão granulares que um titular não precise compartilhar credenciais amplas. Pode explicar os impactos técnicos de decisões hospedadas e delegadas. Deve ter cautela ao transformar uma política de locação ambígua em um controle discricionário sobre rotas ativas.

Essa contenção está alinhada com o significado limitado da ROA. O serviço de certificação verifica a autoridade dentro da hierarquia de recursos numéricos. Ele não certifica toda razão privada para exercer essa autoridade. A obrigação comercial permanece exequível entre as partes e, quando necessário, por tribunais ou mecanismos de resolução de disputas acordados.

O nível de registro ainda pode melhorar a locação sem reconhecer uma nova categoria de propriedade. Pode suportar usuários restritos, histórico de alterações legível por máquina, notificações para vários contatos, ações destrutivas atrasadas onde seguro, e evidências exportáveis de configurações atuais e anteriores. Essas ferramentas reduzem a dependência de um único titular de conta e deixam o negócio legal fora da CA.

O objetivo político deve ser execução previsível, não endosso moral a cada locação. Um sistema seguro pode distinguir a pessoa autorizada tecnicamente a assinar da pessoa autorizada contratualmente a solicitar, sem fingir que são sempre a mesma.

Controle tem um preço econômico

O controle da ROA é frequentemente incluído no preço da locação como se fosse uma tarefa administrativa gratuita. É um serviço de continuidade separado.

Um locador que promete alterações rápidas deve manter pessoal treinado, credenciais protegidas, monitoramento, aprovadores substitutos e cobertura de incidentes. Um modelo delegado requer operação de CA e confiabilidade de publicação. Um locatário que precisa de alterações de origem frequentes incorre em custos mais altos e cria mais oportunidades de falha do que um locatário com uma ASN estável. O preço deve tornar essas diferenças visíveis.

A alternativa é um cálculo ingênuo. Uma locação de baixo custo com prazo de resposta de cinco dias para uma alteração emergencial de ROA pode ser inutilizável para uma rede com compromissos rígidos de disponibilidade. Um locatário pode então compartilhar credenciais informalmente, pedir exceções a um upstream ou manter uma autorização muito ampla para evitar atrasos futuros. Cada atalho transforma uma solicitação de serviço não paga em um risco de segurança.

A visão econômica mais ampla da identidade de rede ilustra esse ponto. A observação de Lu Heng sobreidentidade de rede e continuidade do clienteargumenta que um endereço pode estar embutido em listas de permissão de clientes, regras de parceiros, APIs e sistemas de conformidade. Uma vez que isso acontece, uma alteração de ROA malsucedida não é apenas um inconveniente rotineiro. Pode interromper uma identidade comercial na qual terceiros já confiam.

Sua discussão sobrelocação gerenciada de IPv4 e risco de registrotraz um ponto de mercado relacionado: adquirir endereços é apenas a transação visível; a capacidade operacional contínua depende de como os riscos de registro, roteamento e ciclo de vida são suportados. Uma análise neutra não precisa aceitar toda conclusão institucional nesse argumento para reconhecer o fato operacional. A parte que vende continuidade deve descrever e precificar as ações que a continuidade exige.

Isso pode levar a níveis de serviço. Uma locação básica pode permitir origem estável e alterações em horário comercial. Uma locação resiliente pode incluir duas origens, mitigação de DDoS pré-aprovada, resposta 24 horas e reconciliação periódica. Um locatário com sua própria CA capaz pode optar por delegação limitada e assumir mais deveres. Níveis transparentes são melhores do que fingir que toda locação inclui administração RPKI imediata e ilimitada.

O controle também deve afetar os remédios. Se o locador cobra pela cobertura de emergência e não a fornece, a consequência deve ser tangível. Se o locatário escolhe um nível mais lento e depois exige ação imediata, o locador não deve ser tratado como se tivesse prometido o que não vendeu.

O mercado se torna mais seguro quando a dependência criptográfica é nomeada como parte do produto, em vez de escondida atrás de “suporte”.

Uma divisão prática de direitos

Não há regime universal, mas um padrão defensável pode ser claramente nomeado.

O locador retém o controle final sobre o relacionamento de certificação de recursos e pode recusar alterações fora do escopo locado. Ele deve manter pelo menos dois operadores autorizados, proteger credenciais, criar as ROAs iniciais antes da ativação, cumprir prazos de alteração normais e de emergência definidos, notificar antes de ações destrutivas, exceto em uma emergência de segurança real, e remover a autorização após a saída verificada.

O locatário controla seu design de rede dentro do plano. Ele deve identificar cada ASN de origem e provar seu controle, fornecer planos de rota precisos, manter dois solicitantes autenticados, notificar o locador sobre alterações planejadas, evitar anúncios fora da autorização, monitorar o status RPKI, retirar prontamente no término e manter evidências de fechamento upstream.

O upstream verifica independentemente o relacionamento cliente-prefixo, prepara filtros antes da ativação, monitora desvios, suporta um contato de emergência direto, rejeita alterações de origem não planejadas até confirmação e retira a permissão na saída. Ele não confia em uma ROA como única evidência da autoridade do cliente.

O RIR ou CA pai autentica o titular do recurso, opera ou suporta o modelo de certificação escolhido, protege a hierarquia pai, fornece registros de publicação e alteração confiáveis e lida com eventos comprovados de credenciais ou legais dentro de uma estrutura transparente. Ele não deriva a locação privada do BGP nem decide sobre faturas comuns.

Em locações com alterações frequentes ou alta dependência, uma CA filha limitada pode mover a execução para mais perto do locatário. Em locações com poucas alterações, um serviço hospedado com obrigações de resposta rigorosas pode ser mais seguro. Em prazos muito curtos, os custos de transição RPKI e upstream podem justificar um prazo de notificação mais longo ou um design de endereço diferente. A escolha deve seguir a dependência operacional, não a ideologia.

Cada modelo precisa das mesmas salvaguardas: escopo exato, privilégio mínimo, contatos redundantes, resposta medida, estado visível, sobreposição segura, término firme e evidências independentes. Remova uma, e o controle se desloca para quem por acaso possui as credenciais quando algo dá errado.

O teste é se a autoridade segue a responsabilidade

Uma locação IPv4 é sustentável quando a parte responsável pelo serviço pode obter a autorização necessária, enquanto a parte responsável pelo recurso pode impedir extensão não autorizada e garantir a revogação final.

Esse equilíbrio não é alcançado atribuindo a ROA a um ator em uma frase. É alcançado vinculando a permissão comercial a eventos operacionais. A autoridade de certificação do locador não deve se tornar um veto não pago sobre alterações de rede rotineiras. A necessidade de velocidade do locatário não deve se tornar poder de assinatura permanente sobre um agregado. O upstream não deve terceirizar a verificação do cliente a um objeto criptográfico. O RIR não deve ser pressionado a decidir sobre um contrato que não pode ver.

A tecnologia já expõe as distinções relevantes. Uma ROA nomeia um prefixo, uma origem e um comprimento máximo opcional. O serviço hospedado centraliza as operações de assinatura. O serviço delegado move o controle de chave e a manutenção. Partes confiáveis baixam e validam material publicado. Roteadores aplicam políticas locais. A tarefa de governança é tornar a locação igualmente precisa.

A locação mais segura cria a autorização antes que o tráfego dependa dela, mantém a autorização alinhada com as rotas documentadas, permite ajuste emergencial restrito, isola disputas dos clientes e retira tanto a rota quanto sua permissão criptográfica no final. Ela registra quem fez cada ação e quando.

A resposta final para “Quem controla a ROA?” é, portanto, intencionalmente plural. O locador controla a autoridade certificada. O locatário controla a solicitação operacional. O upstream controla a aceitação direta. O RIR controla um serviço pai ou hospedado dentro de seu escopo. O contrato controla como esses poderes se encontram.

Se o contrato se cala, o titular da credencial controla a crise. Se o contrato é preciso, nenhum ator controla mais do que a responsabilidade que concordou em suportar.