Mudanças entre as edições de "Redes que descartam RPKI Invalidos"

De Wiki BPF
Ir para navegação Ir para pesquisar
Linha 26: Linha 26:
 
* Projeto FORT de NIC Mexico e LACNIC: https://fortproject.net/
 
* Projeto FORT de NIC Mexico e LACNIC: https://fortproject.net/
 
* RIPE NCC http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources
 
* RIPE NCC http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources
−
* rcynic http://subvert-rpki.hactrn.net/trunk/rcynic/
 
 
* RPSTIR http://sourceforge.net/projects/rpstir/
 
* RPSTIR http://sourceforge.net/projects/rpstir/
 
* OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/
 
* OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/

Edição das 14h38min de 22 de dezembro de 2019

Nesse artigo temos uma introdução rápida ao RPKI além de listar as operadoras e provedores de trânsito Internet que já implementam o descarte de prefixos identificados como inválidos pela validação de origem RPKI.

Introdução

O RPKI (Resource Public Key Infrastructure), utiliza certificados de chaves públicas para promover a segurança no roteamento da Internet, permitindo que roteadores BGP validem a origem de cada prefixo recebido, classificando cada um deles como Válido, Inválido ou Desconhecido e garantindo assim uma proteção contra sequestro de prefixos por uma rede ou ASN não detentor daquelas rotas.

  • Válido = O estado válido significa que há um ROA correspondente ao prefixo e ao número AS usado para originar o prefixo.
  • Inválido = Inválido significa que existe um ROA, mas o número do AS ou a máscara de rede do prefixo não corresponde ao ROA.
  • Desconhecido = Desconhecido significa que não há ROA que cubra o prefixo.

Como o roteador faz a validação de origem

Os detentores de endereços IP geram ROAs (Route Origination Authorizations) que associam um prefixo a um ASN, dando a ele permissão para originar o prefixo em questão. O detentor do endereço assina o ROA com a chave privada do certificado. O ROA também contém um comprimento máximo da máscara de rede e uma data de validade. Por exemplo, se o AS 1111 assinar um ROA para 143.205.0.0/16 com um comprimento máximo de prefixo de /22, o AS 1111 poderá originar 143.205.0.0/16, 143.205.0.0/22 e 143.205.248.0/22, mas não 143.205.0.0/23 ou 143.205.0.0/24. No entanto, ele pode gerar um ROA adicional para permitir que o AS 1111 (ou outro ASN!) origine os prefixos mais longos a qualquer momento, pois os ROAs podem se sobrepor.

Certificados e ROAs são publicados em repositórios acessíveis publicamente, onde podem ser baixados e usados para gerar listas de quais prefixos podem ser originados por quais ASNs. Nesse ponto, as assinaturas e a data de validade dos certificados e ROAs são verificadas. Se a data de início de um ROA (e todos os certificados na cadeia do certificado raiz) estiver no futuro ou sua data final estiver no passado, as assinaturas forem inválidas ou foram revogadas, o ROA será ignorado.

A partir desse ponto, os softwares que validam são usados para criar um "cache validado". Este é um processo que toda rede executa independentemente utilizando de aplicações ou softwares para gerar o "cache" (exemplos:.

Em seguida, o "cache validado" é usado para gerar um filtro que é carregado nos roteadores através do protocolo "RPKI to Router protocol (RFC 6810)"

Garantindo a segurança

Uma abordagem mais segura é rejeitar prefixos para os quais um ROA está presente, mas o anúncio no BGP não está valido, ou seja, descartar os inválidos.

Você pode pensar que, se um certificado ou ROA expirar antes da instalação de um novo, a conectividade for perdida e, sem a conectividade, pode ser difícil gerar e fazer upload de novos certificados e ROAs e isso pode gerar problemas para o detentor do recurso. Mas certificados expirados (ou ainda não válidos) e seus ROAs são simplesmente ignorados; portanto, os prefixos em questão voltam a ser desconhecidos e não inválidos e, portanto, permanecem acessíveis a toda Internet.

Software para validar e gerar "cache validado"

Alguns dos software de validação são:

Como verificar se meus prefixos estão corretamente validados?

Para verificar que seus prefixos tenham sido assinados corretamente e que não existem erros que marquem rotas como invalidas pode visitar a ferramenta de validação de origem de LACNIC:

Quais roteadores suportam validação de origem?

Para poder gerar certificados e ROA não é necessário que os roteadores suportem RPKI. No entanto, para que os roteadores possam tomar decisões de roteamento baseadas na autenticidade das rotas baseadas no RPKI, e de preferência descartem os inválidos, é preciso suporte RPKI no sistema operacional do mesmo.

A maioria dos fabricantes já suportam validação de origem, entre eles Cisco, Juniper, Nokia, e Huawei.

  • Cisco IOS – disponível a partir da versão 15.2
  • Cisco IOS/XR –disponível a partir da versão 4.3.2
  • Juniper –disponível a partir da versão 12.2
  • Nokia –disponível a partir da versão R12.0R4
  • Huawei –disponível a partir da versão V800R009C10
  • FRR –disponível a partir da versão 4.0
  • BIRD –disponível a partir da versão 1.6
  • OpenBGPD–available from OpenBSD release 6.4

Lista de redes que implementam descarte de rotas inválidas

Última atualização: Dez/19

ASN Nome Inválidos Observações
7018 ATT Drop Sessões de peering
2914 NTT Drop
DE-CIX Drop Apenas nos Route Servers
1299 Telia Drop
IX.br A partir de Janeiro/2020
Disponível em “https://wiki.brasilpeeringforum.org/index.php?title=Redes_que_descartam_RPKI_Invalidos&oldid=1782”