O papel da RPKI no reforço da segurança do encaminhamento à escala global

Os elementos de verificação partilhados são examinados por cada rede. O seu efeito depende dos dados que cada uma recebe e das políticas que aplica.

Um erro de encaminhamento numa rede pode afetar pessoas que se encontram muito longe. Quando uma origem incorreta se propaga, um sítio Web em funcionamento pode tornar-se inacessível ou o tráfego pode ser dirigido para um destino não pretendido. A RPKI dá às redes recetoras uma forma de verificar uma parte de um anúncio antes de confiarem nele.

O seu valor resulta de uma cadeia de ações: um titular publica uma autorização utilizável, o software verifica-a e um operador aplica uma política de encaminhamento. Compreender essa cadeia permite perceber tanto a proteção como os pontos em que pode falhar.

O que se está a verificar?

As redes trocam informação de alcançabilidade através do BGP. Um prefixo é um bloco de endereços IP; um ASN identifica um sistema autónomo. Uma autorização de origem de rota, ou ROA, indica que ASN o titular autoriza a originar rotas para determinados prefixos.

O software de validação verifica os registos assinados e os certificados e fornece depois dados de autorização validados. Um encaminhador compara a origem e o comprimento do prefixo de uma rota com esses dados. O operador decide o que fazer com o resultado. Esta divisão mantém distintas a publicação dos registos, a validação dos elementos de verificação e as decisões de encaminhamento.

Três resultados, com significados diferentes

• Valid: pelo menos uma autorização que abranja o prefixo permite a origem e o comprimento de prefixo anunciados.
• Invalid: existem dados de autorização que abrangem o prefixo, mas nenhuma entrada permite essa combinação.
• NotFound: os dados em uso não contêm qualquer autorização que abranja a rota.

Estas regras provêm da RFC 6811. Em particular, a ausência de uma ROA que abranja o prefixo não é o mesmo que uma rota Invalid. Valid também não significa que todo o percurso anunciado tenha sido autenticado.

Onde a proteção produz efeito

Se uma rede recetora rejeitar anúncios Invalid, uma origem em conflito pode ser travada nessa rede, em vez de continuar a propagar-se através dela. O efeito depende das autorizações, dos dados disponíveis e da política efetivamente aplicada. Publicar mais ROA e ter mais redes a utilizar a validação da origem são formas de adoção relacionadas, mas diferentes.

A RFC 8481 explicita o papel do operador: atribuir um estado de validação é diferente de agir com base nele. Não existe um interruptor global único que faça todas as redes seguir a mesma política ao mesmo tempo.

Uma rota propagada indevidamente pode conservar uma origem autorizada. Um percurso falsificado também pode preservar esse valor de origem. Por isso, a validação da origem deixa por resolver riscos importantes de encaminhamento; os operadores continuam a precisar de outros controlos e de visibilidade sobre a forma como as rotas se propagam.

O sistema de verificação também exige cuidados

Uma autorização que indique o ASN errado ou exclua um comprimento de prefixo pretendido pode fazer com que um anúncio de rota legítimo seja classificado como Invalid. Problemas no repositório, nos certificados ou nos validadores também podem alterar os dados disponíveis para os encaminhadores. As diferenças entre caches e tempos de atualização fazem com que as várias redes não tenham necessariamente a mesma visão em simultâneo.

A preparação prática inclui autorizações precisas, alterações de encaminhamento testadas, validadores monitorizados e uma resposta documentada a dados desatualizados ou em falta. Um segundo validador só é útil na medida em que reduza as falhas a que se pretende resistir. Não elimina todas as dependências partilhadas. A RFC 7115 trata das operações; a RFC 8211 examina ações prejudiciais no sistema de publicação e certificação da RPKI.

A proteção não deve transformar-se em dependência permanente

Esta é também uma questão de conceção institucional. Uma entidade que controla elementos essenciais de verificação pode afetar redes que não opera nem representa politicamente. Na Nota 28, Lu Heng defende que a função de registo deve continuar a ser uma administração rigorosa, em vez de se tornar um meio de coerção.

A sua Nota 64 estabelece uma ambição de conceção mais exigente: as regras comuns devem ser mínimas e verificáveis localmente, os registos devem ser portáveis e as alterações futuras devem depender da adoção voluntária pelos participantes. A segurança e a capacidade de substituir uma entidade coordenadora que falha têm de ser concebidas em conjunto.

A urgência é concreta. Depois de os utilizadores perderem o acesso, descobrir quem controla um registo necessário torna-se uma emergência. Identifique essas dependências enquanto as redes estão a funcionar. Em seguida, acompanhe como a alteração de um registo pode levar à rejeição de uma rota.