RPKI e ROA: o que compradores e locatários têm realmente de fazer

Porque é que deixou de ser opcional

Durante anos, o RPKI era algo que os operadores concordavam ser uma boa ideia e nunca chegavam a fazer. Isso mudou quando as grandes redes começaram realmente a aplicá-lo. Os principais fornecedores de trânsito, as grandes plataformas cloud e várias grandes redes de conteúdos fazem agora Route Origin Validation e descartam as rotas que aparecem como invalid.

A consequência prática é crua. Um prefixo com um ROA errado não fica apenas desprotegido, fica inalcançável a partir de uma parte crescente da Internet. E a falha é parcial e confusa: alguns utilizadores chegam até si, outros não, e os traceroutes parecem bem a partir de onde quer que esteja a testar.

Se está a comprar ou a alugar espaço de endereçamento, este é o pormenor de configuração com maior probabilidade de lhe custar um dia.

O que é realmente um ROA

O RPKI é um sistema de atestações criptográficas ligado ao registo de endereços. O objeto que importa no dia a dia é a Route Origin Authorization, ou ROA, e contém exatamente três coisas:

• O prefixo. Por exemplo 192.0.2.0/24.
• O AS de origem. O número de sistema autónomo autorizado a anunciá-lo.
• Um comprimento máximo. O prefixo mais longo que pode ser anunciado dentro desse bloco.

É esse o objeto inteiro. É uma declaração assinada pelo titular dos endereços que diz «este AS pode originar este espaço, até esta dimensão específica». Os routers não o leem diretamente. Os validadores obtêm e verificam os dados RPKI, e passam o resultado aos routers, que classificam então cada rota como valid, invalid ou not-found.

Cada rota fica num de três estados. Valid: um ROA cobre o prefixo e o anúncio corresponde-lhe. NotFound, que muitas ferramentas mostram como Unknown: nenhum ROA cobre o prefixo. Invalid: um ROA cobre o prefixo, mas o anúncio contradi-lo, seja a partir do AS errado, seja com um prefixo mais longo do que o comprimento máximo permite.

A ordem destes estados importa mais do que se espera. Uma rota sem ROA continua a ser aceite quase em todo o lado: está desprotegida, mas passa. Uma rota que aparece como Invalid é descartada por todas as redes que aplicam a validação. Não ter ROA é melhor do que ter um ROA errado. O objetivo é um correto, mas se os pormenores não estiverem resolvidos no dia em que anuncia, anunciar sem ROA e adicioná-lo quando estiverem é muito mais seguro do que publicar um que contradiz o que envia.

Quem o cria depende de como obteve o espaço

Isto confunde as pessoas constantemente, por isso vale a pena ser explícito.

Se comprou o bloco, está registado em seu nome e cria o ROA por si no portal do seu registo, ou pede ao seu LIR patrocinador que o crie, se for ele a manter a relação com o registo em seu nome. Faça-o depois de a transferência estar concluída, não antes, porque o objeto tem de ser criado sob o novo titular. O espaço legacy comprado na região do RIPE NCC precisa de um contrato com o RIPE NCC ou com um LIR patrocinador antes de poder sequer ter um ROA (o RIPE NCC).

Se está a alugar, o bloco não está registado em seu nome e não pode criar o ROA. É o titular que o faz, para o seu ASN. Isso significa que lhe tem de dizer duas coisas logo de início: o ASN a partir do qual vai anunciar, e se tenciona anunciar algo mais específico do que o bloco inteiro. Um aluguer em que o ROA não foi criado para o seu ASN aparecerá como invalid no momento em que o anunciar.

Se anuncia através de um fornecedor cloud por BYOIP, o ROA tem normalmente de indicar o ASN do fornecedor e não o seu, porque é a rede dele que origina a rota: AS16509 e AS14618 na AWS, AS8075 no Azure, AS396982 na Google Cloud no seu nível Premium. Alguns fornecedores permitem-lhe originar a partir do seu próprio ASN, seja por uma sessão BGP sua (Vultr, Cherry Servers), seja como opção «bring your own ASN» além do BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Nesse caso, um ROA indica o seu ASN, e a AWS e a Oracle Cloud querem também um com o delas. A maioria dos fornecedores documenta o ASN que o ROA tem de indicar, e alguns, entre eles a Gcore, só o dão quando pergunta, por isso verifique antes de criar seja o que for; os nossos guias por fornecedor indicam-nos.

Os dois erros que causam falhas

Quase todas as avarias reais de RPKI se resumem ao comprimento máximo.

Defini-lo demasiado permissivo. Um ROA para 192.0.2.0/24 com um comprimento máximo de /32 significa que qualquer anúncio de qualquer dimensão dentro desse bloco é válido. Isso anula boa parte do objetivo: alguém que desvie a rota anunciando uma rota mais específica a partir do seu número AS continua a aparecer como valid, e as rotas mais específicas ganham no BGP. O valor seguro por omissão é definir o comprimento máximo igual ao comprimento do prefixo, a não ser que tenha uma razão concreta para não o fazer.

Defini-lo demasiado restrito. Se anuncia um /24 coberto por um ROA e mais tarde precisa de o desagregar em dois /25 para engenharia de tráfego, esses /25 tornam-se invalid de imediato e desaparecem de uma grande parte da Internet. Se planeia anunciar rotas mais específicas, o ROA tem de o permitir antes de começar.

A regra que evita ambos: faça o ROA descrever exatamente o que realmente anuncia, e atualize-o na mesma janela de alteração que qualquer mudança de encaminhamento, não depois.

ASPA: a camada seguinte

Um ROA protege o primeiro elo de uma rota: quem a pode originar. Nada diz sobre o caminho depois disso, que é onde acontecem as fugas de rotas, quando uma rede passa adiante rotas que devia ter guardado para si. O ASPA, Autonomous System Provider Authorization, cobre parte dessa lacuna.

Um objeto ASPA é assinado pelo titular de um número AS e indica os AS que são os seus fornecedores upstream. As redes que o validam podem rejeitar um caminho em que o seu AS parece chegar à Internet através de alguém que não é seu fornecedor. É uma norma emergente do IETF. O RIPE NCC descreve-o como pronto a usar para assinatura, e a ARIN e a APNIC também permitem aos titulares assinar ASPA (os registos comparados).

• Se tem o seu próprio ASN, publique um ASPA com todos os upstreams que levam as suas rotas à Internet. Deixe de fora os peers e os seus próprios clientes.
• Mantenha-o atualizado. Um fornecedor ausente do objeto pode fazer com que as suas rotas através desse fornecedor sejam rejeitadas pelas redes que aplicam o ASPA, por isso adicione um novo trânsito antes de o ativar e remova um antigo depois de o desativar.
• Leva o seu próprio ASN para uma cloud? A AWS recomenda um ASPA que indique AS16509 e AS14618 como fornecedores do seu ASN; sem eles, as rotas que ela volta a anunciar por si falham a validação ASPA.
• Está a alugar? O ASPA pertence ao seu ASN, não ao prefixo, pelo que cabe a si publicá-lo, não a nós.

A lista de verificação

Antes de o espaço transportar tráfego de produção:

• O ROA existe para o prefixo correto e o AS de origem correto.
• O comprimento máximo corresponde ao seu plano real de anúncios.
• Os objetos route IRR também estão no lugar. O RPKI não os substituiu. Muitos upstreams ainda constroem filtros de prefixos a partir de dados IRR, pelo que um ROA válido sem objeto route correspondente continua a ser filtrado.
• O ASPA indica todos os upstreams, se publicar um, e nenhum peer ou cliente.
• Valide externamente. Verifique a partir de um looking glass externo ou de um validador RPKI, não a partir da sua própria rede, que aceitará de bom grado as suas próprias rotas.
• Faça a limpeza à saída. Quando um aluguer termina ou deixa de anunciar um bloco, o ROA deve ser retirado ou atualizado. Um ROA desatualizado que aponta para um ASN que já não anuncia o espaço é um problema para quem o receber a seguir.

Onde entra a RTM Networks

Criamos e mantemos os ROA como parte tanto do aluguer como do patrocínio, e não como extra (alugar IPv4, patrocínio de PI e ASN). Num aluguer, indique-nos o ASN a partir do qual vai anunciar, ou o fornecedor cloud para onde leva o espaço, e se precisa de rotas mais específicas, e o ROA fica configurado antes da entrega. Para recursos patrocinados, gerimos a configuração RPKI a par dos outros objetos do registo.

Se está a assumir espaço vindo de outro lado, quem configura o RPKI depende da via: um comprador fá-lo para o próprio bloco, e num aluguer fá-lo o locador. Podemos verificar se existe um ROA para o bloco e, se existir, se é válido.