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

De Wiki BPF
Ir para navegação Ir para pesquisar
(Criou página com '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 c...')
 
 
(43 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 7: Linha 9:
 
* '''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.
 
* '''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.
 
* '''Desconhecido''' = Desconhecido significa que não há ROA que cubra o prefixo.
−
 
+
<!-- but doing it this way is fine -->.<!-- and so is doing it like this -->
 
=== Como o roteador faz a validação de origem ===
 
=== 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.
 
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.
Linha 16: Linha 18:
  
 
Em seguida, o "cache validado" é usado para gerar um filtro que é carregado nos roteadores através do protocolo "RPKI to Router protocol (RFC 6810)"
 
Em seguida, o "cache validado" é usado para gerar um filtro que é carregado nos roteadores através do protocolo "RPKI to Router protocol (RFC 6810)"
 +
<!-- but doing it this way is fine -->.<!-- and so is doing it like this -->
  
 
=== Garantindo a segurança ===
 
=== Garantindo a segurança ===
Linha 21: Linha 24:
  
 
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.
 
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.
 +
 +
<!-- but doing it this way is fine -->.<!-- and so is doing it like this -->
  
 
=== Software para validar e gerar "cache validado" ===
 
=== Software para validar e gerar "cache validado" ===
 
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/
−
* RIPE NCC http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources
+
* OpenBSD rpki-client  https://www.rpki-client.org/ (exige o GoRTR para a função de servidor RTR)
−
* rcynic http://subvert-rpki.hactrn.net/trunk/rcynic/
+
* OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/ (exige o GoRTR para a função de servidor RTR)
−
* RPSTIR http://sourceforge.net/projects/rpstir/
 
−
* OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/
 
 
* Routinator https://nlnetlabs.nl/projects/rpki/routinator/
 
* Routinator https://nlnetlabs.nl/projects/rpki/routinator/
−
 
+
<!-- but doing it this way is fine -->.<!-- and so is doing it like this -->
 
=== Como verificar se meus prefixos estão corretamente validados? ===
 
=== 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:
 
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:
−
* https://milacnic.lacnic.net/lacnic/rpki/state
 
 
* http://localcert.ripe.net:8088/bgp-preview
 
* http://localcert.ripe.net:8088/bgp-preview
 
* No looking glass da Telia: https://lg.telia.net/
 
* No looking glass da Telia: https://lg.telia.net/
−
 
+
<!-- but doing it this way is fine -->.<!-- and so is doing it like this -->
 
=== Quais roteadores suportam validação de origem? ===
 
=== 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.
 
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.
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''' ==
 +
Você pode acompanhar uma lista ofertada pela CloudFlare em: https://isbgpsafeyet.com/
  
−
== Lista de redes que implementam descarte de rotas '''inválidas''' ==
+
[[Categoria:Roteamento]]
−
 
 
−
Última atualização: Dez/19
 
−
{| class="wikitable"
 
−
|+
 
−
!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''
 
−
|
 
−
|}
 

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:

.

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 Globais que implementam descarte de rotas inválidas

Você pode acompanhar uma lista ofertada pela CloudFlare em: https://isbgpsafeyet.com/

Disponível em “https://wiki.brasilpeeringforum.org/index.php?title=Redes_que_descartam_RPKI_Invalidos&oldid=3781”