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

De Wiki BPF
Ir para: navegação, pesquisa
(→‎Software para validar e gerar "cache validado")
(10 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 7: Linha 7:
 
* '''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 16:
  
 
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 22:
  
 
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" ===
Linha 26: Linha 29:
 
* 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
−
* OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/
+
* 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/
−
 
+
<!-- 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 47: Linha 49:
 
* 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
−
 
+
<!-- but doing it this way is fine -->.<!-- and so is doing it like this -->
 
== Lista de redes que implementam descarte de rotas '''inválidas''' ==
 
== Lista de redes que implementam descarte de rotas '''inválidas''' ==
  
−
Última atualização: Dez/19
+
Última atualização: Fev/20
−
{| class="wikitable"
+
{| class="wikitable" style="margin-left: auto; margin-right: auto;"
 
|+
 
|+
 
!ASN
 
!ASN
Linha 57: Linha 59:
 
!Inválidos
 
!Inválidos
 
!Observações
 
!Observações
 +
|-
 +
|13335
 +
|'''CloudFlare'''
 +
|<span style="color:#FF0000"> ''Drop'' </span>
 +
|
 
|-
 
|-
 
|7018
 
|7018
Linha 62: Linha 69:
 
|  <span style="color:#FF0000"> ''Drop'' </span>
 
|  <span style="color:#FF0000"> ''Drop'' </span>
 
|Sessões de peering
 
|Sessões de peering
−
|-
 
−
|2914
 
−
|'''NTT'''
 
−
|<span style="color:#FF0000"> ''Drop'' </span>
 
−
|
 
 
|-
 
|-
 
|
 
|
Linha 80: Linha 82:
 
|
 
|
 
|'''IX.br'''
 
|'''IX.br'''
−
|
+
|<span style="color:#FF0000"> ''Drop'' </span>
−
|A partir de Janeiro/2020
+
|Apenas nos Route Servers de SP
 +
|-
 +
|174
 +
|'''Cogent'''
 +
|<span style="color:#FF0000"> ''Drop'' </span>
 +
|Sessões de peering
 +
|-
 +
|3491
 +
|'''PCCW'''
 +
|<span style="color:#FF0000"> ''Drop'' </span>
 +
|Sessões de peering
 
|}
 
|}
 +
[[Categoria:Roteamento]]

Edição das 13h56min de 20 de fevereiro de 2020

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: Fev/20

ASN Nome Inválidos Observações
13335 CloudFlare Drop
7018 ATT Drop Sessões de peering
DE-CIX Drop Apenas nos Route Servers
1299 Telia Drop
IX.br Drop Apenas nos Route Servers de SP
174 Cogent Drop Sessões de peering
3491 PCCW Drop Sessões de peering
Disponível em "https://wiki.brasilpeeringforum.org/index.php?title=Redes_que_descartam_RPKI_Invalidos&oldid=2191"