Mudanças entre as edições de "Redes que descartam RPKI Invalidos"
| (25 revisões intermediárias por 10 usuários não estão sendo mostradas) | |||
| Linha 1: | Linha 1: | ||
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. | 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. | ||
| + | |||
| + | '''Autor: Tiago Setti''' | ||
=== Introdução === | === Introdução === | ||
| Linha 28: | Linha 30: | ||
Alguns dos software de validação são: | Alguns dos software de validação são: | ||
* Projeto FORT de NIC Mexico e LACNIC: https://fortproject.net/ | * Projeto FORT de NIC Mexico e LACNIC: https://fortproject.net/ | ||
| − | * | + | * OpenBSD rpki-client https://www.rpki-client.org/ (exige o GoRTR para a função de servidor RTR) |
* OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/ (exige o GoRTR para a função de servidor RTR) | * OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/ (exige o GoRTR para a função de servidor RTR) | ||
* Routinator https://nlnetlabs.nl/projects/rpki/routinator/ | * Routinator https://nlnetlabs.nl/projects/rpki/routinator/ | ||
| Linha 49: | Linha 51: | ||
* BIRD –disponível a partir da versão 1.6 | * BIRD –disponível a partir da versão 1.6 | ||
* OpenBGPD–available from OpenBSD release 6.4 | * OpenBGPD–available from OpenBSD release 6.4 | ||
| − | + | == Lista de redes Globais que implementam descarte de rotas '''inválidas''' == | |
| − | == Lista de redes que implementam descarte de rotas '''inválidas''' == | + | Você pode acompanhar uma lista ofertada pela CloudFlare em: https://isbgpsafeyet.com/ |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
[[Categoria:Roteamento]] | [[Categoria:Roteamento]] | ||
Edição atual tal como às 18h28min de 9 de agosto de 2024
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.
Autor: Tiago Setti
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:
- Projeto FORT de NIC Mexico e LACNIC: https://fortproject.net/
- OpenBSD rpki-client https://www.rpki-client.org/ (exige o GoRTR para a função de servidor RTR)
- OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/ (exige o GoRTR para a função de servidor RTR)
- Routinator https://nlnetlabs.nl/projects/rpki/routinator/
.
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:
- http://localcert.ripe.net:8088/bgp-preview
- No looking glass da Telia: https://lg.telia.net/
.
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 Globais que implementam descarte de rotas inválidas
Você pode acompanhar uma lista ofertada pela CloudFlare em: https://isbgpsafeyet.com/