En el video se realiza un demo del funcionamiento de una ruta estática flotante utilizando IPv6. Comienza explicando que es una ruta estática flotante y luego se procede al demo donde existen tres enrutadores, dos de ellos hablan OSPFv3 mientras que el enlace de backup se realiza de manera estática, la ruta flotante configurada se encuentra en el primer router/enrutador. El demo fue realizado utilizando equipos Cisco sin embargo el principio es el mismo en cualquier sistema operativo.
Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
Mostrando entradas con la etiqueta routing. Mostrar todas las entradas
Mostrando entradas con la etiqueta routing. Mostrar todas las entradas
miércoles, 9 de junio de 2021
martes, 23 de marzo de 2021
RFC 7911- BGP Add-path en acción
En el video se realiza un demo de la capacidad de BGP llamada Add-Path definida en el RFC 7911 utilizando FRR sobre Ubuntu. Para la realización del video se utilizó únicamente prefijos IPv6 a pesar de que la capacidad es agnóstica al prefijo transportado
lunes, 25 de enero de 2021
Roles en BGP - Reduciendo fugas de redes/prefijos en BGP con mensajes OPEN y UPDATE
El video muestra una característica muy novedosa aún discutida dentro de IETF de como prevenir routing leaks utilizando un nuevo concepto llamado: "Roles BGP"
jueves, 10 de septiembre de 2020
BGP Vecinos Dinámicos en FRR utilizando IPv6 - BGP Dynamic Neighbors
En el video se realiza una demostración de configuración de BGP Vecinos Dinámicos
utilizando FRR e IPv6
.
viernes, 4 de septiembre de 2020
Solucion: Closing connection because of an I/O error en FRR
Hola,
Si recibes el siguiente error en FRR:
Closing connection because of an I/O error
la solución que yo tuve fue compilar de nuevo agregando el flag:
--enable-systemd
Sería algo como:
./configure \
--prefix=/usr \
--includedir=\${prefix}/include \
--enable-exampledir=\${prefix}/share/doc/frr/examples \
--bindir=\${prefix}/bin \
--sbindir=\${prefix}/lib/frr \
--libdir=\${prefix}/lib/frr \
--libexecdir=\${prefix}/lib/frr \
--localstatedir=/var/run/frr \
--sysconfdir=/etc/frr \
--with-moduledir=\${prefix}/lib/frr/modules \
--with-libyang-pluginsdir=\${prefix}/lib/frr/libyang_plugins \
--enable-configfile-mask=0640 \
--enable-logfile-mask=0640 \
--enable-snmp=agentx \
--enable-multipath=64 \
--enable-user=frr \
--enable-group=frr \
--enable-vty-group=frrvty \
--enable-systemd \
--with-pkg-git-version \
--with-pkg-extra-version=-MyOwnFRRVersion
Puedes seguir las las instrucciones en: http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-ubuntu2004.html y agregar mi propuesta.
Suerte.
miércoles, 5 de agosto de 2020
miércoles, 22 de julio de 2020
Alta disponibilidad utilizando VRRP e IPv6 con IPv6 en VyOS 1.3
En el video se realiza una demostración básica de VRRP y BGP con IPv6 en VyOS 1.3. Se realiza
la configuración de VRRP entre dos dispositivos y configuración BGP entre 3 diferentes routers.
sábado, 23 de mayo de 2020
BGP Conditional en el mundo IPv6 - BGP Condicional
En el video se muestra la característica de BGP condicional aplicado
al mundo IPv6. En la demostración se conectan 3 ASs y uno de ellos solo realiza el anuncio de un prefijo IPv6 solo cuando una condición se cumpla.
jueves, 31 de octubre de 2019
Una mirada al uso de BGP AS_SET en la DFZ
Introducción:
Como algunos de ustedes saben, en BGP existe un argumento llamado AS-SET, en muchas
nomenclaturas lo conseguiremos como route-aggregation.
¿Qué es BGP AS-SET?
El AS-SET en pocas palabras lo que permite es agregar/sumarizar varias rutas en un prefijo
más grande. Como muchas cosas, tiene ventajas (reducir el tamaño de la tabla global BGP)
y además tiene inconvenientes (prevenir loops y validación de origen RPKI).
¿Por qué el estudio?
Para el momento que se escriben estas líneas (Octubre 2019), en IETF existe un draft
(que pensamos se convertirá en estándar) donde se propone que AS-SET pase a ser obsoleto.
El draft puede se conseguido
Si este draft pasa a ser RFC eventualmente los fabricantes van a dejar de soportar
AS-SET y puede existir (pero no pensamos que ocurra) algún riesgo de perder algunos
prefijos & ASs en la tabla global
Origen de la data para el presente estudio
Se utilizó las tablas BGP de Potaroo.net. Se pueden obtener en:
IPv4: http://bgp.potaroo.net/as2.0/bgptable.txt
Para la información sobre los recursos se utilizó los APIs de RIPE.
Fecha del estudio
Mes de Octubre de 2019
Estudios realizados
- Buscar ASs que hagan AS_SET
- Buscar prefijos que sean sometidos a AS_SET
¿Cómo se identifica un AS-SET en la tabla BGP?
Identificar AS-SET puede variar según el vendor/fabricante del software que realiza BGP.
Para el presente estudio utilizamos la tabla BGP publicada por Potaroo.net, la misma
es una salida BGP del comando “show ip bgp” de Cisco.
En la salida del comando se puede apreciar líneas similares a:
* i2001:QWER::/32 QWER:300::6 0 152 0 65412 65001 {65002,65003}
La salida anterior se puede leer:
- AS 65002 realiza al menos un anuncio BGP
- AS 65003 realiza al menos un anuncio BGP
- AS 65001 Realiza AS-SET y anuncia el prefijo 2001:cd8::/32 (una supernet de los
- prefijos recibidos por 65002 y 65002)
- 65412 hace tránsito a los AS anteriores sin embargo no es relevante para este estudio
Gracias a las llaves ( { } ) es sencillo ubicar quien hace el AS-SET
Resultados generales:
Tabla #1 Resumen General
IPv4
|
IPv6
| |
Prefijos en la tabla
|
803999
|
77438
|
Prefijos sometidos a AS-SET
|
387
|
26
|
ASs únicos haciendo AS-SET
|
128
|
20
|
ASs haciendo AS-SET en IPv4 e IPv6
|
7
|
7
|
Resultados específicos por RIR:
IPv4
|
IPv6
| |
RIPE ASs
|
52
|
9
|
RIPE Prefijos
|
111
|
9
|
ARIN ASs
|
50
|
5
|
ARIN Prefijos
|
127
|
10
|
APNIC ASs
|
11
|
4
|
APNIC Prefijos
|
46
|
8
|
AFRINIC ASs
|
1
|
0
|
AFRINIC Prefijos
|
7
|
0
|
LACNIC ASs
|
14
|
2
|
LACNIC Prefijos
|
96
|
7
|
Colocando la lupa sobre LACNIC
Datos específicos sobre LACNIC (IPv4):
Resumen:
.- 96 prefijos únicos a los cuales se les hace AS-SET
.- Existen prefijos de LACNIC anunciados por ASs de RIPE, ARIN y LACNIC
.- Se consiguió un AS de LACNIC que realiza AS-SET de prefijos de ARIN
.- Conseguimos 14 ASs haciendo AS-SET
Datos específicos sobre LACNIC (IPv6):
Resumen:
- Se obtuvieron 7 prefijos
- 2 AS diferentes que se consiguieron haciendo AS-SET
- Hubo un caso interesante donde el mismo prefijo se le hace AS-SET desde 2 ASs
- diferentes y además uno es de LACNIC y el otro de RIPE
- Prefijos de LACNIC son anunciados por ASs de LACNIC, RIPE y/o ARIN
- ASs de LACNIC no hacen AS-SET de prefijos no-LACNIC
Referencias:
martes, 30 de abril de 2019
Como verificar si un sitio Web se encuentra bloqueado
Hola,
Si en google por ejemplo buscamos "como revisar si un sitio web esta bloqueado" será difícil conseguir información de como revisar nosotros mismos, los resultados serán principalmente sitios Web que pueden abrir la página Web por tí, mostrarte desde otros sitio si puede conectarse, algún plugin que puedas instalar. En estás páginas se puede revisar si un sitio está arriba o no: https://www.blocked.org.uk/check y https://downforeveryoneorjustme.com/
NOTA: Este post es básicamente como podemos revisar nosotros mismos un bloqueo. Estamos hablando de bloqueos por parte de un ISP/país, no de bloqueos en el firewall en una empresa o compañía. Se aceptan sugerencias y quejas.., comentarios están abiertos al final del documento
Introducción:
Como algunos de ustedes saben, existen muchas manera de bloquear sitios Web, principalmente los bloqueos ocurren de 4 maneras:
1) DNS
2) Routing
3) Capa 4 (bloqueo de puertos TCP/UDP a ciertos destinos)
4) Capa 7 (bloqueo de por ejemplo la URL/dominio)
Ahora bien, antes de continuar quiero dejar claro mi posición en cuanto a los bloqueos en Internet: ME PARECEN MUY MALA IDEA y no trae nada bueno al país/ISP..., y en el supuesto que traíga una cosa buena, trae 10 cosas malas. Tengo algunas cosas plasmadas en este post: https://blog.acostasite.com/2014/10/la-mala-idea-de-bloquear-internet.html
Pasos para revisar un bloqueo de un sitio Web:
Ahora bien, en el supuesto que queramos saber si algún sitio se encuentra bloqueado, podemos seguir estos pasos (preferiblemente Linux y/o MAC):
1) Revisar si el bloqueo es por DNS. ¿Cómo lo hacemos?
Podemos usar dos herramientas de resolución DNS. Para este ejemplo utilizaremos dig y/o nslookup.
.- Utilizando dig
.- Utilizando nslookup
¿Qué hay que revisar de la salida?
Básicamente con el comando, le pedimos a dig que muestre de manera resumida, que direcciones IP resuelve www.example.com. En este sentido 172.XX.YY.39 será el IP al cual nuestra computadora se va a conectar. Lo importante aquí es identificar si 172.XX.YY.39 corresponde al IP destino que nos queremos conectar (si, ciertamente pueden resolver direcciones diferentes y eso, pero si sabes eso no necesitas leer este documento :) !! ) Muchas veces algunos ISPs cambian la resolución de un dominio y no verías el IP correcto sino otra al cual es imposible conectarse (por ejemplo, 127.0.0.1)
2) Routing
La idea es en lineas generales ver si podemos alcanzar el destino desde nuestra computadora:
Utilizando traceroute:
¿Qué hay que revisar de la salida?
Como se puede ver en el traceroute de arriba, se llegó satisfactoriamente al destino.
En el caso de ver algún "!" seguido por una letra, es mala noticia. Por ejemplo ver esto en el traceroute significa que hay algo mal, quizás el ISP bloqueó las direcciones IP destino de alguna manera.
Errores comunes (tomados de la página del manual de traceroute):
!U or !W (destination network/host unknown)
!I (source host is isolated)
!A (communication with destination network administratively prohibited)
!Z (communication with destination host administratively prohibited)
!Q (for this ToS the destination network is unreachable),
!T (for this ToS the destination host is unreachable),
!X (communication administratively prohibited),
!V (host precedence violation),
!C (precedence cutoff in effect), or
! (ICMP unreachable code ).
Extra:
Otra herramienta que recomiendo para revisar este punto es MTR (My traceroute) ; https://es.wikipedia.org/wiki/MTR_(software).., es una combinación de ping y trace. MUY buena.
3) Capa 4 (bloqueo de puertos a ciertos destinos)
Para revisar bloqueos de capa 4, principalmente la idea es revisar conectividad a nivel de puertos (TCP) desde tu computadora al destino.
La herramienta más sencilla para revisar esto es telnet, la intención al ejecutarlo es chequear que efectivamente "se conectó" nuestra computadora al destino.
Utilizando telnet:
Ejemplo 1: (conecta¡ándose al puerto http)
Ejemplo 1: (conectándose al puerto https)
Cuando el destino se encuentra bloqueado a nivel de 4 veríamos algo así:
Depende el tipo de bloqueo, el telnet puede ser rechazado muy rápido (reject *), quizás el telnet solo dure mucho hasta que haga timeout.
* tu computadora recibe un icmp error desde el dispositivo que se encuentra bloqueando
4) Capa 7 (bloqueo de por ejemplo la URL/dominio)
¿Qué hay que revisar de la salida?
El bloqueo de sitios Web en Internet no trae beneficios.
Si en google por ejemplo buscamos "como revisar si un sitio web esta bloqueado" será difícil conseguir información de como revisar nosotros mismos, los resultados serán principalmente sitios Web que pueden abrir la página Web por tí, mostrarte desde otros sitio si puede conectarse, algún plugin que puedas instalar. En estás páginas se puede revisar si un sitio está arriba o no: https://www.blocked.org.uk/check y https://downforeveryoneorjustme.com/
NOTA: Este post es básicamente como podemos revisar nosotros mismos un bloqueo. Estamos hablando de bloqueos por parte de un ISP/país, no de bloqueos en el firewall en una empresa o compañía. Se aceptan sugerencias y quejas.., comentarios están abiertos al final del documento
Introducción:
Como algunos de ustedes saben, existen muchas manera de bloquear sitios Web, principalmente los bloqueos ocurren de 4 maneras:
1) DNS
2) Routing
3) Capa 4 (bloqueo de puertos TCP/UDP a ciertos destinos)
4) Capa 7 (bloqueo de por ejemplo la URL/dominio)
Ahora bien, antes de continuar quiero dejar claro mi posición en cuanto a los bloqueos en Internet: ME PARECEN MUY MALA IDEA y no trae nada bueno al país/ISP..., y en el supuesto que traíga una cosa buena, trae 10 cosas malas. Tengo algunas cosas plasmadas en este post: https://blog.acostasite.com/2014/10/la-mala-idea-de-bloquear-internet.html
Pasos para revisar un bloqueo de un sitio Web:
Ahora bien, en el supuesto que queramos saber si algún sitio se encuentra bloqueado, podemos seguir estos pasos (preferiblemente Linux y/o MAC):
1) Revisar si el bloqueo es por DNS. ¿Cómo lo hacemos?
Podemos usar dos herramientas de resolución DNS. Para este ejemplo utilizaremos dig y/o nslookup.
.- Utilizando dig
MacBook-Pro-2:tmp$ dig +short www.example.com
172.XX.YY.39
.- Utilizando nslookup
MacBook-Pro-2:tmp$ nslookup www.example.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: www.example.com
Address: 172.XX.YY.39
¿Qué hay que revisar de la salida?
Básicamente con el comando, le pedimos a dig que muestre de manera resumida, que direcciones IP resuelve www.example.com. En este sentido 172.XX.YY.39 será el IP al cual nuestra computadora se va a conectar. Lo importante aquí es identificar si 172.XX.YY.39 corresponde al IP destino que nos queremos conectar (si, ciertamente pueden resolver direcciones diferentes y eso, pero si sabes eso no necesitas leer este documento :) !! ) Muchas veces algunos ISPs cambian la resolución de un dominio y no verías el IP correcto sino otra al cual es imposible conectarse (por ejemplo, 127.0.0.1)
2) Routing
Para revisar routing principalmente utilizaremos traceroute (tracert en Windows)
La idea es en lineas generales ver si podemos alcanzar el destino desde nuestra computadora:
Utilizando traceroute:
MacBook-Pro-2:tmp$ traceroute -n 8.8.8.8 (sustituye 8.8.8.8 por el dominio o el IP obtenido en el paso previo)
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 192.168.1.1 1.724 ms 1.030 ms 1.376 ms
2 190.XX.XX.1 28.969 ms * 35.939 ms
3 172.YY.13.33 27.988 ms 27.379 ms 29.267 ms
4 * * *
5 10.XX.1.105 29.229 ms 28.628 ms 28.303 ms
6 10.XX.1.1 38.332 ms 26.855 ms 28.605 ms
7 200.XX.XX.177 61.560 ms 62.466 ms 68.661 ms
8 72.NN.NN.84 62.411 ms 62.523 ms 62.188 ms
9 108.170.253.17 62.537 ms 63.011 ms 63.182 ms
10 108.170.226.13 63.588 ms 65.335 ms 62.301 ms
11 8.8.8.8 62.329 ms 63.023 ms 62.176 ms
¿Qué hay que revisar de la salida?
En el caso de ver algún "!" seguido por una letra, es mala noticia. Por ejemplo ver esto en el traceroute significa que hay algo mal, quizás el ISP bloqueó las direcciones IP destino de alguna manera.
Errores comunes (tomados de la página del manual de traceroute):
!H, !N, or !P (host, network or protocol unreachable)
!S (source route failed)!U or !W (destination network/host unknown)
!I (source host is isolated)
!A (communication with destination network administratively prohibited)
!Z (communication with destination host administratively prohibited)
!Q (for this ToS the destination network is unreachable),
!T (for this ToS the destination host is unreachable),
!X (communication administratively prohibited),
!V (host precedence violation),
!C (precedence cutoff in effect), or
!
Extra:
Otra herramienta que recomiendo para revisar este punto es MTR (My traceroute) ; https://es.wikipedia.org/wiki/MTR_(software).., es una combinación de ping y trace. MUY buena.
3) Capa 4 (bloqueo de puertos a ciertos destinos)
Para revisar bloqueos de capa 4, principalmente la idea es revisar conectividad a nivel de puertos (TCP) desde tu computadora al destino.
La herramienta más sencilla para revisar esto es telnet, la intención al ejecutarlo es chequear que efectivamente "se conectó" nuestra computadora al destino.
Utilizando telnet:
Ejemplo 1: (conecta¡ándose al puerto http)
MacBook-Pro-2:tmp$ telnet www.example.com 80 -- 80 quiere decir el puerto destino
Trying 199.NN.NN.100...
Connected to www.example.com. --- esto es lo que hay que revisar
Escape character is '^]'.
Ejemplo 1: (conectándose al puerto https)
MacBook-Pro-2:tmp$ telnet www.example.com 443 -- 443 quiere decir el puerto destino
Trying 199.NN.NN.100...
Connected to www.example.com. --- esto es lo que hay que revisar
Escape character is '^]'.
Cuando el destino se encuentra bloqueado a nivel de 4 veríamos algo así:
MacBook-Pro-2:tmp$ telnet www.example.com 80
Trying 199.XX.XX.100...
telnet: connect to address 199.XX.NN.100: Operation timed out
telnet: Unable to connect to remote host
Depende el tipo de bloqueo, el telnet puede ser rechazado muy rápido (reject *), quizás el telnet solo dure mucho hasta que haga timeout.
* tu computadora recibe un icmp error desde el dispositivo que se encuentra bloqueando
4) Capa 7 (bloqueo de por ejemplo la URL/dominio)
Revisar capa 7 viene a ser cuando el ISP es capaz de identificar el contenido de paquetes HTTP y chequear por el texto del dominio bloqueado dentro de él, es decir: el ISP quiere bloquear www.example.com, algunos dispositivos dentro del ISP son capaces de revisar a nivel de capa de aplicación (capa 7) el fqdn www.example.com, y allí tomar la decisión: bloquear o no.
Para lo anterior, recomiendo utilizar curl o wget. Dejaré solo el ejemplo con curl:
Utilizando curl (en hacia un destino bloqueado)
MacBook-Pro-2:tmp$ curl -v https://www.example.com
* Rebuilt URL to: https://www. example.com/
* Trying 172.NN.NN.39...
* TCP_NODELAY set
* Connected to www.example.com (172.NN.NN.39) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443
* stopped the pause stream!
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443
¿Qué hay que revisar de la salida?
No hay que asustarse con la salida, aquí hay revisar que la negociación SSL/TLS no pudo completarse, esto lo podemos apreciar al conseguir que el texto *ERROR* se ve en la salida.
Nota: Cuando la salida es satisfactoria, veremos código html
Conclusión:
Existen MUCHAS manera de bloquear acceso a sitios en Internet, incluso en algunas oportunidades puede usarse una combinación de varias maneras para lograr un bloqueo.
Se que el post puede ser mucho más amplio y faltaron cosas por cubrir, sin embargo a su vez espero que él mismo sea visto como una introducción.
Existen MUCHAS manera de bloquear acceso a sitios en Internet, incluso en algunas oportunidades puede usarse una combinación de varias maneras para lograr un bloqueo.
Se que el post puede ser mucho más amplio y faltaron cosas por cubrir, sin embargo a su vez espero que él mismo sea visto como una introducción.
jueves, 4 de abril de 2019
Video: Ejemplo: Utilizando BGP Local Preference y Weight con prefijos IPv6
Η δυσκοιλιότητα είναι αποτέλεσμα διάφορων παραγόντων, η οποία φαίνεται, να έχει ενταθεί λόγω του σύγχρονου τρόπου ζωής. Αντιμετωπίστε άμεσα τη δυσκοιλιότητα με το Izicol. Ωστόσο, πολύ σημαντικός παράγοντας φαίνεται να είναι η διατροφή και η ενυδάτωση του οργανισμού.
martes, 19 de marzo de 2019
miércoles, 13 de marzo de 2019
Video: Ejemplo de BGP Route Reflector en una red IPv6
Hola,
Les comento que el otro día estuve dando un curso de IPv6 que incluía una parte de BGP; entre las consultas que recibí hubo una pregunta de enrutadores Route Reflector, por ello decidí realizar el siguiente video:
Espero sea útil para alguien.
Saludos,
Alejandro,
Les comento que el otro día estuve dando un curso de IPv6 que incluía una parte de BGP; entre las consultas que recibí hubo una pregunta de enrutadores Route Reflector, por ello decidí realizar el siguiente video:
Espero sea útil para alguien.
Saludos,
Alejandro,
viernes, 17 de agosto de 2018
Demostración: Antispoofing IPv6 en un router Cisco IOS
El siguiente video muestra como simular un ataque spoof en Internet y como prevenir el mismo en Cisco IOS
martes, 10 de julio de 2018
Crear ruta IPv6 en MAC OS y revisar tabla de vecinos IPv6
Crear ruta:
Revisar tabla de vecinos IPv6:
route add -inet6 -net 2000::/3 2001:XXX:XX:XX::1
Revisar tabla de vecinos IPv6:
ndp -an
lunes, 22 de enero de 2018
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:
- 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
Referencias
- “Internet Routing Registry - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Internet_Routing_Registry.
- “JSON - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/JSON.
- “Resource Public Key Infrastructure - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure.
- “Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/Routing_Policy_Specification_Language.
- 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.
- “Statistics — RIPE Network Coordination Centre.” n.d. Accessed January 19, 2018. https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html.
- “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.
- “Website.” n.d. Accessed January 19, 2018a. http://stats.labs.lacnic.net/RPKI/RPKItoJSON/.
Suscribirse a:
Entradas (Atom)
Una propuesta inesperada dentro de IETF – Ethernet sobre HTTPS
En el presente post quiero hablar mayormente sobre un documento con poco tiempo en IETF llamado “Ethernet sobre HTTPS”. Debo confesar que su...
-
Debido al crecimiento moderado que ha tenido el presente blog se me ocurrió añadir/integrar las estadisticas de google analytics a mi blog. ...
-
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...