Mostrando entradas con la etiqueta estudio. Mostrar todas las entradas
Mostrando entradas con la etiqueta estudio. Mostrar todas las entradas

viernes, 17 de marzo de 2023

Una mirada a los miembros IPv6 Only de LACNIC

Introducción

El siguiente trabajo busca analizar la publicación de prefijos y el estado de los mismos, por parte de los miembros de LACNIC conocidos como IPv6 Only.

Se trata de organizaciones que han recibido prefijos IPv6, con o sin sistema autónomo (ASN), y no cuentan con prefijo IPv4 asignado por LACNIC. Los resultados de este análisis nos ayudarán a mejorar nuestra comprensión de los usos y necesidades de nuestros asociados en la región.


Fuentes de información utilizadas en este análisis

 La fuente de información utilizada en este análisis  fue el whois de LACNIC, con datos  obtenidos a lo largo del mes de enero de 2023. Esta información  incluye únicamente a aquellos miembros que posean IPv6 y no poseen IPv4 por parte de LACNIC. Pueden o no tener asignado un sistema autónomo.


Procesamiento de los datos

Python3 sobre un notebook Jupyter. Nos apoyamos en los API públicos de LACNIC y de RIPE NCC


            WHOIS de LACNIC


            RIPE NCC API


            APNIC Penetración IPv6 por ASN


            Delegated Extended de LACNIC:


Resultados

  Obtuvimos 483 miembros de LACNIC que se consideran IPv6 Only, a los que dividimos en:


            IPv6 Only con ASN: 343 miembros


            IPv6 Only sin ASN: 140 miembros




Resultados sobre los 483 miembros IPv6 Only (con y sin ASN):


 De los 483 miembros analizados obtuvimos la siguiente información:


-261 Anuncian el prefijo en su totalidad o parcialmente


-208 Anuncian el prefijo recibido por LACNIC en su totalidad


-53 Anuncian el prefijo recibido por LACNIC parcialmente


-222 No anuncian el prefijo



Resultados sobre los 343 miembros IPv6 Only con ASN:


De los 483 miembros IPv6 Only 343 tienen ASN (71%)


De los 343 con ASN:


                        163 anuncian el prefijo (47,52%)


120 Anuncian el prefijo IPv6 completo (73,61 %)


43 Anuncian el prefijo IPv6 parcialmente (26,38 %


180 No anuncian el prefijo Pv6  (52,48%)




Resultados sobre los 140 miembros IPv6 Only Sin ASN


De los 483 miembros IPv6 Only 140 no tienen ASN (29%)


De los 140 sin ASN obtuvimos


98 Anuncian el prefijo (70%)


82 Anuncian el prefijo completo (83,67%)


16 Anuncian el prefijo parcialmente (16,32%)


42 No anuncian el prefijo (30%)




¿Qué podemos extraer de los gráficos anteriores?

Lo primero que me llama poderosamente la atención es que los miembros IPv6 Only sin ASN poseen 23 puntos porcentuales más anuncios que aquellos miembros de LACNIC que si poseen su ASN. Es decir, estos miembros han pedido a otra organización que anuncie su prefijo.

En ambos casos la cantidad de prefijos no anunciados es muy alta; puede ser interesante averiguar si existe algún motivo detrás de esta situación. 

Es particularmente llamativo que el porcentaje de anuncio parcial es casi idéntico (11% miembros con ASN y 12% miembros sin ASN)


Intentando identificar si los ASNs poseen tráfico IPv6

Conociendo que existen 343 ASNs con prefijos IPv6 asignados y pensando que además son IPv6 Only, se puede presumir que deben tener un tráfico IPv6 “medio alto”.  Por ello, evaluamos cada AS para conocer su tráfico IPv6 para el 23 de Enero 2023.


¿Cómo averiguamos si un ASN posee tráfico IPv6?

Como es conocido por varios de ustedes, APNIC lleva muchos años midiendo el tráfico IPv6 de cada ASN. Se puede conocer más de estos estudios aquí: https://stats.labs.apnic.net/ipv6


En base a lo anterior, con los ASNs conocidos de los miembros IPv6 Only de LACNIC quisimos averiguar si efectivamente poseen tráfico IPv6 (es decir, más allá de realizar el anuncio de su prefijo). 


Lastimosamente no se pudo conseguir información de 274 ASs (79,88 %) de los 343 evaluados, Sin embargo, es importante destacar que esto no necesariamente significa que no hayan desplegado IPv6, sino que el tráfico generado es muy bajo y no aparecen en las mediciones de APNIC. 32 ASN fueron reportados con 0% de tráfico IPv6 y 1 ASN con 88% de tráfico IPv6.


¿Nuestros miembros IPv6 Only son en realidad tan IPv6 Only?

Finalmente, quisimos averiguar si efectivamente nuestros miembros (IPv6 Only con ASN) son tan IPv6 Only como nosotros los llamamos.


Para este caso en particular nos apoyamos en el API de RIPE NCC para obtener la información presentada a continuación.


De los 343 miembros con ASNs obtuvimos:


-540 prefijos totales anunciados (entre v4 y v6)


                        Anuncios v4: 220


                        Anuncios v6: 320


                        La máscara media en los anuncios v4 es: 23,56


                        La longitud de prefijo media en los anuncios IPv6 es: 38,09


-66 miembros se “volvieron” DualStack, es decir el ASN anuncia IPv4 e IPv6


-90 miembros anuncian solo IPv6


-27 miembros anuncian solo IPv4


-160 no anuncian prefijo alguno


Y los prefijos IPv4 que anuncian los miembros IPv6 Only de LACNIC,  ¿a cuál RIR pertenecen?


LACNIC ARIN RIPE NCC AFRINIC APNIC

28 166 17 9 0








Diagrama Sankey – Mirada a los miembros IPv6 Only


Conclusiones

Los resultados sugieren que, aunque existe una cantidad significativa de miembros de LACNIC que se consideran IPv6 Only, pudimos notar que más del 50% de ellos no han comenzado con el anuncio de su prefijo v6. A su vez pudimos apreciar que muchos de los que han desplegado IPv6 continúan utilizando IPv4. Esto significa que, aunque la adopción de IPv6 en la región ha crecido en los últimos años, aún hay un largo camino por recorrer para alcanzar un despliegue generalizado de IPv6. En cualquier caso, es importante continuar monitoreando la adopción del nuevo protocolo.


Finalmente ser un miembro IPv6 Only de LACNIC igualmente permite a las organizaciones participar en el ecosistema de Internet.

viernes, 25 de junio de 2021

miércoles, 23 de junio de 2021

ASNs con IPv6 vs ASNs sin IPv6

Tenemos el agrado de anunciar que hemos publicado una nueva estadística. En este post te damos todos los detalles. Si quieres ir directo al sitio web te dejamos la URL: https://stats.labs.lacnic.net/IPv6/ASNsConIPv6vsASNsSinIPv6.html

Objetivo
Conocer la evolución del despliegue de ASNs (sistemas autónomos) en nuestra región con y sin IPv6. En otras palabras: ¿Cada vez hay más ASNs publicando prefijos IPv6?

Un poco de historia
El área de I+D (Investigación y Desarrollo de LACNIC) recibió por parte del área de Cooperación una consulta sobre el número de ASNs en la región que estuviesen utilizando IPv6. Lastimosamente en ese momento no podíamos dar una respuesta inmediata.

Los datos
A pesar de que sacar el número mencionado arriba es un trabajo relativamente fácil debido que por varios años I+D ha venido recabando esos datos de APNIC [1] se decidió realizar dicho trabajo de manera automatizada y disponible para toda la comunidad.

¿A que se considera un ASN con IPv6?
A efectos de las estadísticas mostradas se considera un ASN con IPv6 aquellos que reporten más de un 1 por ciento (>1%) en su adopción (valor tomado por APNIC)

Un ejemplo de la gráfica





¿Que muestra la gráfica?
La gráfica es una serie de tiempo que comienza a finales del año 2014 hasta el día de hoy. Cada uno de los valores en el eje Y representa el % de Sistemas Autónomos para los países de cobertura de LACNIC con y sin IPv6. El eje X representa el instante en el tiempo. Importante destacar: Línea Azul= ASNs sin IPv6. Línea roja= ASNs con IPv6

Leyendo la gráfica
Los buenos estadistas son muy buenos leyendo e interpretando información de una gráfica. Entre muchas cosas podemos obtener:
  • Existe un marcado crecimiento de ASNs con IPv6 en la región lo que a su vez incide en ASNs que no tengan aún IPv6
  • Desde el año 2019 ha aumentado la velocidad de adopción de IPv6
  • Actualmente ASNs con IPv6 se encuentran ligeramente sobre 30%
  • El crecimiento interanual luego del 2019 supera el 50% !!

Sobre la automatización
Los datos se actualizarán todos los días sábados a las 3:59 pm UTC -3

Recuerda el link de la nueva estadística quedó en: https://stats.labs.lacnic.net/IPv6/ASNsConIPv6vsASNsSinIPv6.html

¿Los datos se encuentran en opendata?
Si, desde hace muchos años en LACNIC venimos haciendo un esfuerzo por publicar nuestra información en opendata (CVS y/o JSON). Para este nuevo estudio se encuentra en: https://stats.labs.lacnic.net/IPv6/opendata/ASsConIPv6vsASNsSinIPv6-opendata.json

Referencias
[1] http://data1.labs.apnic.net/ipv6-measurement/AS/asns.nice.loadable.json

martes, 23 de junio de 2020

Panorámica sobre secuestro de redes. Un mal que nos agobia

Introducción
  El objetivo del presente post es exponer de una manera sencilla la realidad en
cuanto al secuestro de redes. Se verán  estadísticas de lo que sucede en las
regiones de todos los RIRs, sin embargo siempre se brindará más detalle de lo
que acontece en la región de LAC.


Terminología
Secuestro de red o Hijack
  Es el apoderamiento ilegítimo de una red IP manipulando las tablas BGP


Evento
Para este documento, “evento” corresponde a cualquier actividad en torno al
secuestro de redes (pe, secuestrar / ser secuestrado)


Secuestrador
  El actor que realiza el secuestro de una red.


Secuestrado
  Es la organización dueña de los recursos que son víctima del secuestro.


Los datos 
  El origen de los datos corresponde a la cuenta de twitter @bgpstream ubicada
en: https://twitter.com/bgpstream la cual es mantenida por bgpmon (ahora parte
de Cisco). Se aprecia que incluso es un CSV donde podemos extraer mucha
información valiosa. 


Un ejemplo de la información contenida en un tweet es:


BGP,HJ,hijacked prefix AS58065 196.196.120.0/24, PACKETEXCHANGE,
SE,-,By AS57858 AS57858, EU, http://bgpstream.com/event/240117


Veamos en detalle la información de los datos del ejemplo:
HJ = La info contentiva de este tweet que corresponde a un Hijack, un
secuestro de red  (estos son los tipos de tweets que precisamos)
AS58065 = AS Origen del prefijo de la red
SE = Código del país correspondiente al prefijo de la red
196.196.120.0/24 = Prefijo de red secuestrado
AS57858 = AS del secuestrador
http://bgpstream.com/event/240117 URL para obtener más detalles del
evento. Es importante destacar que luego de entrar al link, @bgpstream
define estos eventos como: “Possible BGP hijack”.  En este sentido se
presume que en algunas oportunidades existirán falsos positivos.


Para la geolocalización de los recursos de Sistemas Autónomos (AS) se utilizó el
API de RIPE NCC ubicado en:
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-
documentation/how-to-query-the-ripe-database/14-3-restful-api-queries


Universo del estudio
Todos los tweets desde el 1 de Enero de 2016 al 31 de Mayo de 2020 de la
cuenta twitter @bgpstream siendo un total de 45.000 (todos los eventos)


Muestra utilizada para el estudio 


La muestra para el estudio se obtuvo mediante la selección de  los tweets que
contenían en el texto siglas HJ (indicando Hijack). Resultaron un total de 6573
tweets que constituyen la muestra del estudio.


Procedimiento para el procesamiento de los datos
TweeterScraper fue la herramienta utilizada para extraer los tweets de la cuenta
@bgpstream y luego con scripts propios se procedió a filtrar solo aquellos
correspondientes a secuestro de prefijos (Hijacks).


 Las herramientas utilizadas fueron:


  • TweetScraper
  • Python3
  • Adicionalmente se utilizó el API de RIPE NCC para geolocalización de varios
recursos:
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-
database-documentation/how-to-query-the-ripe-database/14-3-restful-api-queries


Resultados obtenidos 


Cantidad  de secuestros por año (1 de Enero 2016 hasta 31 de Mayo 2020)


En la tabla y gráfica siguientes se aprecian la cantidad de secuestros conseguidos
desde el 2016 a la fecha. 
Si se realiza la matemática para un cálculo diario se puede apreciar que son
números alarmantes.


Año
Total Secuestros
IPv4
IPv6
2016
2065
1825
240
2017
1880
1595
285
2018
1879
1693
186
2019
577
539
38
2020
172
148
24

6573
5800
773




¿Cómo es el comportamiento por mes? 


Se quiso determinar si este comportamiento estaba más o menos acentuado
según el mes del año.  
Colocando la lupa al gráfico anterior quisimos averiguar cual mes del año es el que
más eventos posee. Para conseguir este valor se tomó la data desde el año 2016 al
2019 (6383 registros), no se procesó el año 2020 debido a ser el año en curso. Se
agruparon los eventos por mes y se hizo un desglose adicional según IPv4 e IPv6.
A continuación se muestran las gráficas con los resultados.


Se puede distinguir para los totales que el mes con más actividad es Noviembre
y el mes con menos movimiento es Marzo. Sin embargo, es interesante destacar que
IPv6 aparece como segundo mayor cantidad de secuestros durante el mes de Marzo.


¿Alguna hora del día donde exista mayor cantidad de secuestros?
Adicionalmente tuvimos la curiosidad de conocer si quizás existían algunas horas del
día más propensas a observar secuestros de red. Para este estudio se utilizaron
todos los registros disponibles y se tomó únicamente el entero de la hora del
reporte (indicadas en UTC -4). Por ejemplo, un reporte donde el horario indica
14:23 se procesó únicamente el número 14. 


Las horas de más pico son las 11 y 16 (UTC -4) y las horas menos ocupadas fueron
desde las 21 hasta la 01 (UTC -4). Una vez más se puede aprovechar el desglose
adicional de IPv4 e IPv6.


Cantidad de secuestro de rutas diferenciada por RIR
En la tabla inferior se muestra por día de la semana cuál es el RIR que más secuestros
recibe (según Sistema Autónomo del secuestrado)



RIPE
APNIC
LACNIC
ARIN
AFRINIC
Friday 
393
307
115
328
24
Monday 
411
284
81
280
16
Saturday 
264
130
46
140
16
Sunday 
140
90
31
77
3
Thursday 
517
280
127
372
21
Tuesday 
411
183
66
282
27
Wednesday 
375
240
131
284
53


Particularmente los prefijos correspondientes a LACNIC tienen su día de mayor
movimiento los Miércoles con 131 registros.


¿Desde cuál RIR se generan más secuestros de rutas?
La siguiente tabla muestra según el día de la semana cual es el RIR que realiza más
secuestros (según Sistema Autónomo del secuestrador)



RIPE
APNIC
LACNIC
ARIN
AFRINIC
Friday 
416
213
150
341
24
Monday 
362
194
168
326
14
Saturday 
220
123
49
167
24
Sunday 
121
87
36
86
6
Thursday 
462
183
200
349
108
Tuesday 
388
181
117
257
12
Wednesday 
333
159
152
387
32


Y específicamente LACNIC comparte el mismo día Jueves como su mayor
movimiento en este rubro.


¿Cuál es el día de la semana con menos secuestros por RIR?
Sin sorpresa podemos darnos cuenta que el día de menos actividad en cuanto a los
secuestros de red son los días de Domingo.


AFRINIC
Sunday
LACNIC
Sunday
APNIC
Sunday
ARIN
Sunday
RIPE
Sunday


¿Cuáles prefijos son los más secuestrados? 
Para esta sección creamos la siguiente tabla de frecuencias. 
Mostramos únicamente los bloques secuestrados 4 o más veces.


Prefijo
Nro de veces
150.150.150.0/24
4
192.5.59.0/24
4
2a04:c007::/32
4
78.24.184.0/21
4
79.143.84.0/24
4
87.236.213.0/24
4
91.209.131.0/24
4
91.220.21.0/24
4
121.52.203.0/24
5
185.76.17.0/24
5
5.5.5.0/24
5
103.15.168.0/24
7
185.58.128.0/24
7
187.16.216.0/21
7
2.2.2.0/24
7
2001:bf7:170::/44
8
80.249.208.0/21
18


En la tabla anterior es muy llamativo el valor de la moda, corresponde al prefijo
80.249.208.0/21, curiosamente supera en más del doble la frecuencia inmediata
anterior. En otro orden de ideas, en lo personal esperábamos observar los prefijo
1.1.1.0/24 o 1.0.0.0/24 sin embargo los mismos no aparecen. 
Por otro lado es llamativo que el prefijo 2.2.2.0/24 que no posee ROA si se
encuentra en la lista, ¿se deberá a la magia de RPKI?


¿Cuál máscara de red se utiliza más frecuentemente para secuestrar prefijos?
Luego de obtener los prefijos con mayor frecuencia de secuestro se nos ocurrió
identificar qué máscara/longitud de prefijo eran los más utilizados. Para obtener este
valor utilizamos toda la muestra. Aquí la respuesta tanto para v4 como para v6.


En el mundo IPv4


En el mundo IPv6


  Lo anterior indiscutiblemente me recordó un antiguo post llamado: “BGP: Filtrar
por tamaño de la red en BGP, he ahí el dilema” que se puede conseguir en
https://blog.acostasite.com/2017/03/bgp-filtrar-por-tamano-de-la-red-en-bgp.htmlEn ese documento se realiza una recomendación
para aprender cierto tamaño de prefijos en caso de no poder recibir la tabla
completa BGP.


TOP 10 de países más afectados por secuestro de prefijos
La siguiente tabla muestra el código de país y la cantidad de veces que fue afectado
por eventos.


Posición
Country
Times
1
US
859
2
BR
702
3
IN
350
4
CN
319
5
GB
277
6
DE
264
7
RU
208
8
NL
199
9
IR
177
10
HK
172


Se puede observar que en la región de LACNIC, Brasil es el país que sufre la
mayor cantidad de secuestros de prefijos (y segundo en el mundo). Por otro lado,
no se aprecia en la tabla pero para la región de LAC le seguirían Argentina con 80,
Colombia con 59 y Chile con 58, secuestros de red respectivamente.


¿Y cuales son los países que realizan más secuestros de red?


La siguiente tabla muestra el código de país desde el cual se han realizado más
secuestros de rutas y la cantidad de eventos detectados.


Ranking
Eventos
CC
1
1034
US
2
703
BR
3
307
RU
4
226
IN
5
181
DE
6
172
HK
7
172
GB
8
153
PL
9
148
IR
10
146
CH


Una vez más observamos a nuestros amigos de Brasil en segundo lugar. Ahora bien,
si seguimos en la lista, en nuestra región tenemos a Argentina en el puesto 17 con 85,
Colombia en el 28 con 42 y Venezuela en el 38 con 25 secuestros.


¿Alguna curiosidad?


Revisando ASs que hayan realizado secuestros conseguimos el AS2147483647 el
cual es reservado, el mismo realizó un total de 36 secuestros entre el año 2016 y el
2018, siendo el último evento el día 2 de Junio del 2018. 


¿Algunas sumas no te cuadran?
  • Nuestras disculpas, en algunas pocas oportunidades no ha sido posible obtener
el RIR y/o país de algún prefijo y/o AS.


Conclusiones
  • Se puede apreciar que el secuestro de redes es una realidad y ninguna región
se escapa de ellos.
  • Existe una disminución marcada de secuestros por año, gran parte debido a la
mejora de las buenas prácticas buscando redes más resilientes, implementación y
uso de RPKI e IRR. Lastimosamente  igualmente creemos que será sempiterno.
  • La región de LACNIC no escapa de esta problemática y por ello se hace
necesario un arduo trabajo de concientización en torno a este tema
  • A pesar de que la fuente de datos pueda tener algún margen de error pensamos
que como información referencial es suficientemente convincente.


Futuros pasos
  • Identificar la duración de un secuestro
  • Obtener más fuentes de información
  • Conocer el margen de error de los datos mostrados (recordemos que los datos
publicados por @bgpstream son “possible hijacks” )


Referencias:



Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...