Propuesta de una fuente confiable de enrutamiento para la región de LAC

Introducción

Recientemente fue publicado un artículo por Job Snijders llamado: “A New Source For Authoritative Routing Data”, su traducción viene a ser algo como: “Una nueva fuente de información de enrutamiento autoritativa”. (Snijders 2017)

El documento trata sobre un trabajo donde explica como varios expertos y en contribución con varias instituciones construyeron una manera de proveer a la comunidad información confiable sobre enrutamiento. Para ir entrando en detalles técnicos podemos verlo como algo entre un IRR (“Internet Routing Registry - Wikipedia” n.d.) y RPKI (“Resource Public Key Infrastructure - Wikipedia” n.d.)

En este documento se describe una propuesta de LACNIC a la comunidad, con el fin de proveer una fuente de información autoritativa confiable sobre enrutamiento que pueda utilizarse por parte de los operadores de Internet de la región.

Un poco de historia

En el post de Job Snijder se explica cómo se tomó como fuente de información confiable la base de datos de Whois de ARIN y especificamente un campo llamado Origin el cual especifica cual AS (Sistema Autónomo) es quien anunciará determinado prefijo.

Posteriormente lo que se hace con esa información es construir un archivo JSON (“JSON - Wikipedia, La Enciclopedia Libre” n.d.) el cual puede ser utilizado fácilmente por programadores y diferente software de forma muy similar a lo que hace un IRR actualmente.

¿Qué hicimos en Lacnic?

Luego de analizar el post anterior y nuestras opciones, concluimos que el campo OriginAS prácticamente no es utilizado en el WHOIS de LACNIC, por lo que no estaríamos en condiciones de extraer esa información a partir de esa fuente. Sin embargo, dado el gran porcentaje de ROAs creados en varios países de la región (“Statistics — RIPE Network Coordination Centre” n.d.), creemos conveniente utilizar RPKI como fuente de información.

¿Cómo se tomó la información de RPKI?

Para utilizar la informacion de RPKI de LACNIC trabajamos con el validador RPKI de RIPE (“Tools and Resources” n.d.), con la diferencia que removimos todos los TAL (Trust Anchor Locator) exceptuando el de LACNIC. De esta manera el validador unicamente estaría procesando los ROAs correspondientes a nuestra región. Finalmente lo que hicimos fue exportar los ROAs en formato JSON, una funcionalidad que ofrece el propio validador.

Proceso de la información de RPKI

Finalmente, utilizando un script en python3 y en base al JSON exportado del Validador de RIPE construimos un nuevo archivo de JSON, (“Tools and Resources” n.d., “Website” n.d.) con una similitud sintáctica de 95% al del proyecto previo (“Website” n.d.)(Job Snijders y compañía). En este sentido, la manera como se crea la fecha, las posiciones relativas en el archivo, los nombres de las llaves son identicos, de esta manera facilitamos la interoperatividad con scripts y software ya existente.

Adicionalmente, esta misma información se publica en format RPSL(“Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre” n.d.), un formato que es más habitual para los operadores. De esta forma, se puede elegir entre ambos formatos para procesar o utilizar la información autoritativa.

Avances actuales

En base a todo lo mencionado anteriormente actualmente:

• Se publica diariamente un dump de todos los ROAs en formato JSON
• Se publica en RPSL la información correspondiente al AS de Origen y el prefijo (tanto v4 como v6) Lo anterior viene acompañado de un un hash de comprobación bajo SHA384 URL http://stats.labs.lacnic.net/RPKI/RPKItoJSON/

Espacio para mejoras

Sabemos que existen muchas cosas para mejorar, por el momento debemos mencionar:

1. Publicar los archivos en un server con soporte de https

Conclusiones

Dentro de Lacnic este proyecto aun se encuentra en una etapa Alfa, a lo sumo Beta. Dependeremos 100% de los comentarios recibidos de la comunidad si deseamos llevar esta idea a un ambiente con carácter de producción. Por ello no dude en comunicarse con nosotros, somos muy buenos recibiendo quejas, comentarios y felicitaciones.

Consideraciones adicionales

En los ROAs es posible especificar una longitud máxima y mínima de prefijos a publicar, sin embargo esto no tendría una forma similar de replicarlo en el archivo de salida. Una posibilidad en IPv4 sería generar los prefijos intermedios con el mismo sistema autónomo de origen, pero en IPv6 esto no sería posible por la cantidad de direcciones involucradas. Otra posibilidad es no utilizar las longitudes mínima y máxima en los ROAs, ya que esa es la situación análoga a los IRRs. El formato JSON de salida es fácilmente convertible a RPSL, con lo cual se pueden utilizar las mismas herramientas que se utilizan para procesar la información de un IRR. Un punto a analizar es si resulta necesario poder contar con otros objetos que no están incluidos en esta base de datos auto-generada.

Por:

• Alejandro Acosta alejandro \at lacnic dot net
• Guillermo Cicileo guillermo \at lacnic dot net

https://twitter.com/lacniclabs

Referencias

1. “Internet Routing Registry - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Internet_Routing_Registry.
2. “JSON - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/JSON.
3. “Resource Public Key Infrastructure - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure.
4. “Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/Routing_Policy_Specification_Language.
5. Snijders, Job. 2017. “A New Source For Authoritative Routing Data: ARIN WHOIS.” Medium. Medium. December 19, 2017. https://medium.com/@jobsnijders/a-new-source-for-authoritative-routing-data-arin-whois-5ea6e1f774ed.
6. “Statistics — RIPE Network Coordination Centre.” n.d. Accessed January 19, 2018. https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html.
7. “Tools and Resources.” n.d. RIPE Network Coordination Centre. Accessed January 19, 2018. https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources.
8. “Website.” n.d. Accessed January 19, 2018a. http://stats.labs.lacnic.net/RPKI/RPKItoJSON/.

BGP: Filtrar por tamaño de la red en BGP, he ahí el dilema

Introducción

 El equipo de I+D del área técnica y WARP redactaron en conjunto el presente artículo basado en algunos incidentes gestionados por el centro de respuestas de LACNIC.

 En el mundo de BGP existen decenas de maneras para filtrar prefijos. El objetivo del presente post mostrar una serie de recomendaciones para tener una red más estable, no perder conectividad con ciertos destino y reducir el número de quejas en nuestro NOC.

Situación identificada

  Muchos ISPs no pueden recibir la full routing table de BGP (para el dia de hoy consta de ~610.000 prefijos IPv4) en sus enrutadores.

  Lo anterior puede deberse a diversas razones:

• El enrutador no posee suficiente RAM para aprender todos los prefijos (además recordar que es posible que el router tenga varias sesiones BGP)
• Por ahorro de CPU
• Porque el upstream provider a su vez no entrega toda la tabla de enrutamiento
• Por simplicidad y sencillez

 Entendiendo la situación e independientemente de la razón que sea, el enrutador no aprende toda la tabla de enrutamiento.

Problema

  No aprender toda la tabla de enrutamiento puede traer algunos inconvenientes parciales pero que al final trae problemas de conectividad, quejas de los usuarios, inconvenientes de acceso a ciertos sitios, entre otros.

¿Por qué?

  Imaginemos la siguiente situación:

1. Tengo un router (propiedad de EXAMPLE) en Internet que solo aprende la tabla parcial de enrutamiento
2. El router propiedad de EXAMPLE quedó configurado solo para aprender redes “más grandes” que /21. Es decir, aprende redes /20, /19, /18, etc.  (evidentemente estamos hablando de IPv4)
3. Debido a la configuración establecida en el punto “b”, el router no aprenderá prefijos de tamaño /21, /22, /23 ni /24
4. Mientras tanto en otra parte del mundo, le acaban de secuestrar su red /21 a la empresa ACME (planteamos el caso como un secuestro pero podría ser una mala configuración)
5. ACME decide realizar anuncios más específicos de su red original /21, es decir, anuncia 8 redes /24
6. Por causa de los filtros configurados por EXAMPLE, nunca verá dichos anuncios /24 de ACME
7. EXAMPLE seguirá aprendiendo la red /21 del secuestrador de la red. Lo que puede ocasionar que el tráfico hacia ACME puede ser potencialmente secuestrado (repito, se entiende que esta situación es potencial, no necesariamente el tráfico irá hacia el atacante)

Diagrama:

  El siguiente diagrama representa la hipótesis planteada en el punto anterior de manera gráfica para facilitar su comprensión.

Recomendación

 Realizaremos la siguiente recomendación en base a algunas experiencias vividas, teniendo en cuenta que solo aplican al caso de cuando no se pueda aprender/recibir la tabla completa de BGP:

1. No filtrar permitiendo redes menos específicas. Es conveniente aprender redes más chicas, es decir: /24, /23, /22.
2. Filtrar por AS_PATH de profundidad.
3. Crear los ROAs respectivos a los prefijos (RPKI).

Algunos ejemplos (Cisco like)

1)  Solo queremos aprender redes entre /22 y /24 (hay otras maneras de hacer esto):

router bgp 65002

neighbor 10.0.0.1 remote-as 65001

neighbor 10.0.0.1 route-map FILTRO-IN in

!

ip prefix-list REDESCHICAS seq 5 permit 0.0.0.0/0 ge 22 le 24

!

route-map FILTRO-IN permit 10

match ip address prefix-list REDESCHICAS

!

2) Solo queremos aprender dos AS de profundidad (hay otras maneras de hacer esto):

router bgp 65001

neighbor 10.0.0.2 remote-as 65002

neighbor 10.0.0.2 route-map ASFILTER-IN in

!

ip as-path access-list 5 permit ^[0-9]+_$

ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$

!

route-map ASFILTER-IN permit 10

match as-path 5

!

Mas información

• Demostración de secuestro de prefijo  1/2: https://www.youtube.com/watch?v=X5RNSs8y8Ao&t=39s
• Demostración de secuestro de prefijo 2/2: https://www.youtube.com/watch?v=m51WtuEZOKI
• BGP Prefix-Based Outbound Route Filtering
  http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsbgporf.html
• Ejemplo de configuración de BGP con dos prestadores de servicio diferentes (conexiones múltiples)
  http://www.cisco.com/cisco/web/support/LA/7/75/75930_27.html
• Certificación de Recursos (RPKI)
  http://www.lacnic.net/web/lacnic/certificacion-de-recursos-rpki
• Información General sobre Certificación de Recursos (RPKI)
  http://www.lacnic.net/web/lacnic/informacion-general-rpki

Autores

- Dario Gomez

- Alejandro Acosta (@ITandNetworking)

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 2/2)

En este segundo video se muestra como manipular Quagga para que tome decisiones en base al estado del prefijo RPKI. Continuacion de: https://blog.acostasite.com/2015/05/demostracion-de-secuestro-de-prefijos.html

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 1/2)

El video muestra un ejemplo de como ocurre un secuestro de un prefijo de red en Internet y a su vez muestra como RPKI ayudaría a prevenir esta situación

Configurando Quagga para manipular prefijos (Local Preference) utilizando RPKI

Objetivo:
   En el siguiente mini laboratorio configuraremos Quagga para manipular prefijos BGP y asignar Local Preference segun el estado RPKI (valid, invalid, Not Found).
 
Escenario:
- R1 publica un prefijo con un AS que no le corresponde (segun ROA)
- R2 publica el mismo prefijo que R1 pero desde un AS que si es valido
- R2 publica un prefijo sin ROA.
- En este escenario el validador y el router Quagga estan en el mismo equipo

Diagrama del laboratorio:

Requisitos:
- Quagga con soporte para RPKI
- RPKI Validator de RIPE NCC
- Un prefijo que sepamos que se tiene ROA valido. En nuestro caso utilizamos el prefijo 200.85.64.0 que sabiamos que tiene un ROA que indica que debe ser publicado por el AS 7908
- Ejecutar el validador de RIPE NCC antes de ejecutar Quagga


Configuraciones de todos los equipos

Conf-Quagga-RPKI-Mini-LAB.txt

hostname RPKI-RTR
password test
!
router bgp 65000
 bgp router-id 10.0.0.10
 bgp bestpath prefix-validate allow-invalid
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 route-map rpki in
 neighbor 10.0.0.2 remote-as 7908
 neighbor 10.0.0.2 route-map rpki in
 neighbor 10.0.0.3 remote-as 65003
 neighbor 10.0.0.3 route-map rpki in
!
route-map rpki permit 10
 match rpki invalid
 set local-preference 10
!
route-map rpki permit 20
 match rpki valid
 set local-preference 30
!
route-map rpki permit 30
 match rpki notfound
 set local-preference 20
!        
line vty
!
enable-rpki
  rpki polling_period 1000
  rpki timeout -1216757171
!
  rpki group 1
    rpki cache 127.0.0.1 8282
! 

R1.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable password test
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.1 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 password test
 login
!
end

R2.cfg

!
!
!
!
hostname R2
!
no ip domain lookup
no ip icmp rate-limit unreachable
ip tcp synwait 5
!
!
interface Ethernet0
 ip address 10.0.0.2 255.255.255.0
 half-duplex
!
!
router bgp 7908
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

R3.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.3 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 192.168.0.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
end

Salida final en Quagga:
(Notese los flags N, I, V) (Notese los local preference)

RPKI-RTR# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
N*> 192.168.0.0      10.0.0.3                 0     20      0 65003 i
I*  200.85.64.0      10.0.0.1                 0     10      0 65001 i
V*>                  10.0.0.2                 0     30      0 7908 i

Total number of prefixes 2

Verificar el origen de un prefijo BGP

Historia:
  En algunas situaciones queremos estar seguros que el prefijo BGP aprendido en nuestro router sea efectivamente originado por quien debería ser. Han ocurrido ciertas eventualidades en la historia del mundo de Internetworking donde un Sistema Autonomo ha publicado redes no debidas (ej: http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study).
  Hoy en día un poco más del 10% de los prefijos asignados por los RIRs (Lacnic, RIPE, Afrinic, ARIN y APNIC) tienen asignado un ROA (Route Origin Authorization) el cual indica de manera segura quien es el sistema autonomo asignado para publicar cierto prefijo. A lo anterior se le conoce como Resource Public Key Infrastructure (RPKI) 


Problema:
  Deseo saber cual debería ser el sistema autónomo de un prefijo especifico (por ejemplo una red aprendida por BGP). 


Solución:
  Seguramente en un futuro cercano tendremos decenas de páginas Web donde podamos consultar el sistema autonomo que debería publicar cierta red (quizás hoy en día existen y yo no las conozco), en fin, nuestro buen amigo whois nunca nos falla. En esta oportunidad nos apoyaremos en el servidor whois de bgpmon.net


  Aquí les dejo los comandos y unas salidas ejemplos:

• ROA con problemas (
  Se esperaba el AS 17NN9 y esta siendo publicado por el 79NN)):

aacosta@bind:~$ whois -h whois.bgpmon.net 2001:NNNN::0


Prefix:              2001:NNNN::/32
Prefix description:  
Country code:        VE
Origin AS:           79NN
Origin AS Name:      NNNNNN.
RPKI status:         ROA validation failed: Invalid Origin ASN, expected 17NN9

• ROA satisfactorio:

aacosta@bind:~$ whois -h whois.bgpmon.net 2001:NNNN::0


Prefix:              2001:NNNN::/32
Prefix description:  
Country code:        VE
Origin AS:           79NN
Origin AS Name:      NNNNNNN.
RPKI status:         ROA validation successful

• SIN ROA (en este prefijo no podremos saber que AS debería publicarlo):

aacosta@bind:~$ whois -h whois.bgpmon.net 2800:NN::0

Prefix:              2800:NN::/32
Prefix description:  
Country code:        AR
Origin AS:           79NN
Origin AS Name:      NNNNNN
RPKI status:         No ROA found

Más información:
http://acostanetwork.blogspot.com/2011/03/historico-de-tablas-bgp-hijack-de-mi.html (Histórico de tablas BGP)
https://labs.ripe.net/Members/Paul_P_/content-serving-roas-rpsl-route-objects
http://bgpmon.net/blog/?p=414