martes, 28 de julio de 2020

¿Fue creada Arpanet para soportar una guerra nuclear?

Ya sea en una clase del colegio o incluso la universidad, un documental en televisión o un apunte anecdótico en alguna revista de tecnología, en algún momento de nuestras vidas hemos escuchado que Arpanet, la red predecesora de Internet, nació como un proyecto informático capaz de soportar las consecuencias de una guerra nuclear, incluso si se hace una sencilla búsqueda en google escribiendo la frase: “TCP/IP Arpanet” entre las opciones desplegadas aparecerá como resultado  “tcp/ip arpanet nuclear war”.

¿Es cierto que Arpanet tuvo un propósito militar antinuclear?
Por: Gabriel E. Levy B.(www.galevy.com) y Alejandro Acosta (Lacnic) – Artículo conjunto promovido por Andinalink y Lacnic 

Advanced Research Projects Agency Network (ARPANET), fue la primera red de datos de computadora – WAN -, que funcionó basada en un sistema de intercambio de paquetes de información conocido como “packet-switching”, y que se consolidó en este propósito a través de un protocolo denominado TCP, que en esencia permite la fragmentación de la información en múltiples paquetes, siendo estas dos tecnologías el origen de lo que hoy conocemos como “Internet”[1].

De acuerdo a los registros históricos disponibles y los relatos de sus creadores, la idea o concepto de una red de ordenadores con capacidad para comunicar usuarios ubicados en computadoras, distantes de forma remota entre ellas, fue formulado en abril de 1963 por Joseph C. R. Licklider[2], quien es considerado uno de los padres de la ciencia de la computación y quien trabajando de la mano de Bolt, Beranek y Newman (BBN)[3]una compañía especializada en investigación y desarrollo de tecnología de punta, elaboraron de manera conjunta un documento que proponía la creación de una gran sistema de interconexión de computadoras, que en su momento llamaron,“La red galáctica”[4].

Una proyecto financiado por el Departamento de Defensa de los Estados Unidos – DOT

La Agencia de Proyectos de Investigación Avanzados de Defensa, más conocida por su acrónimo DARPA, (Defense Advanced Research Projects Agency)[5], es una agencia adscrita al  Departamento de Defensa de los Estados Unidos de Norte America y es la responsable en gran medida, del desarrollo de nuevas tecnologías enfocadas en uso militar[6].

En Octubre de 1963, Darpa (para ese momento se llamaba ARPA),  convocó a Joseph C. R. Licklider[7] para presentar los resultados de su investigación, lo cual le permitió de paso convencer a los científicos de computación Ivan Sutherland y Robert «Bob» Taylor[8], acerca de la importancia y los alcances de sus investigaciones, pero más importante aún, de la necesidad de crear una gran red de computadoras[9].

Como director de Información del – Information Processing Techniques Office – IPTO – de ARPA, y convencido del trabajo liderado por Licklider, el informáticoRobert «Bob» Taylor,planteó al entonces director de ARPA Charles Herzfeld, la posibilidad de conectar entre sí las computadoras que hacían parte del Departamento de Defensa de Los Estados Unidos, buscando optimizar los recursos y el flujo de Información.

    “Robert Taylor, tuvo una brillante idea basada en las ideas propuestas por J. C. R. Licklider : ¿Por qué no conectar todos esos ordenadores entre sí? Al construir una serie de enlaces electrónicos entre diferentes máquinas, los investigadores que estuvieran haciendo un trabajo similar en diferentes lugares del país podrían compartir recursos y resultados más fácilmente” Análisis publicado por @Wicho en el portal Microsiervos[10]

Uno de los aspectos más relevantes de la apuesta de Taylor, es que no se concentró exclusivamente en la interconexión y la compartición de recursos, sino que desde el principio buscó garantizar la interoperabilidad entre los diferentes tipos de máquinas, sin importar la compatibilidad entre ellas, creando de paso una protección contra fallos, algo que solo podría lograr si la  estructura de la red estaba descentralizada, de esta forma si un ordenador fallaba, los demás podrían seguir trabajando[11]. La idea en su conjunto le encantó Herzfeld, quien asignó un presupuesto inicial de un millón de dólares (Equivalente a 8 Millones de dólares al tiempo presente) para el desarrollo de esta red descentralizada y aprueba de fallos por problemas de interoperabilidad.

De acuerdo con una entrada correspondiente al mes de marzo de 1964, en la cronología de Internet que mantiene Larry Roberts, “El trabajo conjunto de los investigadores del MIT, junto con el aporte de de Licklider, Kleinrock y Roberts, permitió que el proyecto de Arpanet tomara fuerza”[12].

Como parte de esta indagación, en un cruce de correos sostenidos entre Alejandro Acosta coautor de este artículo y Vint Cenf, científico computacional de Stanford que hizo parte del proyecto de Arpanet, existe una referencia a Larry Roberts en donde asegura que:

    “Tenía claro que ARPANET estaba destinado al apoyo de recursos, es decir, una red diseñada para compartir “.

Cazando el Mito

The RAND Corporation, a principios de la década de los 60 y en el contexto de plena guerra fría[13], comenzó a trabajar  en el diseño de un tipo de red segura de comunicaciones capaz de sobrevivir a un ataque con armas nucleares, con fines militares. Al frente de esta Investigación se encontraba Paul Baran[14] quien propuso en un documento presentado en 1962 y publicado en 1964,  “El uso de una red descentralizada con múltiples caminos entre dos puntos; en donde la división de mensajes completos en fragmentos seguiría caminos alternativos y la red estaría capacitada para responder ante sus propios fallos”[15].

Para 1964 el profesor Leonard Kleinrock, profesor de la Universidad de UCLA en California[16], escribió un libro denominado Communication Nets[17], en el cual propuso la teoría de conmutación de paquetes en la interconexión de redes, las cuales en 1968 fueron comparadas con las investigaciones que venían desarrollando en el mismo sentido Paul Baran y Donald Davies,

    “quienes llegaron independientemente a conclusiones similares a las de Kleinrock[18]” y que en conjunto sirvieron como inspiración para el desarrollo de la arquitectura descentralizada de Arpanet, aunque si bien existe mucha literatura, es imposible determinar con total certeza cuál fue el nivel de influencia de la investigación de Baran sobre el diseño final del modelo propuesto por el MIT.

Un año después, a las 10.30 de la noche del día 29 de octubre de 1969, el mismo profesor  Leonard Kleinrock desde su computadora SDS Sigma 7, envió el mensaje LOGIN al equipo SDS 940 del instituto de investigación de Stanford. El mensaje quedó recortado a un extraño “lo”, ya que hubo un fallo de transmisión, pero una hora después la máquina de Stanford recibió la palabra “Login” completa, produciéndose de esta forma  la primera conexión entre computadores dando formalmente origen práctico a la red: ARPANET,  que en menos de dos años ya tenía más de 70 computadoras conectadas[19]. Por su parte el protocolo TCP apareció unos años después, pero no sería perfeccionado sino hasta principio de los años 80 [20]

La influencia de Baran en el proyecto

Si bien los diseños originales de Paul Baran tenía un claro propósito Militar para garantizar la supervivencia del sistema de interconexión ante un ataque nuclear y aunque el proyecto de Arpanet fue financiado por el Departamento de Defensa de los Estados Unidos a través de DARPA, la imposibilidad para determinar a ciencia cierta el nivel de influencia que tuvo los estudios de Baran sobre el diseño final y al no haber existido una solicitud puntual a los investigadores sobre el diseño de una red que tuviera estas características, (de acuerdo a sus propias afirmaciones),  NO es posible asegurar que el diseño descentralizado de ARPANET tuvo un propósito relacionado con la supervivencia Nuclear, siendo este un MITO ampliamente difundido a lo largo de la historia.

No obstante lo anterior, es importante hacer salvedad en varios aspectos claves, por una parte el mito tiene origen en hechos históricos demostrables que justifican coherentemente el supuesto que lo subyace. El primero de ellos es que la financiación militar del proyecto estuvo a cargo del Departamento de Defensa de los Estados Unidos mediante DARPA, que se dió en el contexto de la guerra fría en un momento en que el espionaje era una de las mayores preocupaciones del gobierno, por lo que la confidencialidad del mismo y el secreto que lo enmarca, sin duda jugaron un rol preponderante para que las verdaderas intenciones posiblemente fueran clasificadas. Finalmente las investigaciones de Paul Baran de una u otra forma pudieron influir en el resultado final del proyecto, lo cual podría ocasionar que sin quererlo, los investigadores del MIT (Instituto Tecnológico de Massachuset) terminaran trabajando para esta causa sin tener mucha conciencia al respecto.

En Conclusión, si bien queda claro que en estricto sentido y rigor histórico, Arpanet y por derecho propio Internet, no nacieron como redes diseñadas para sobrevivir a un ataque Nuclear, ya que su diseño de fragmentado en paquetes, respondió fue a la suma de una serie de casualidades, la búsqueda de estabilidad y la optimización de recursos, el hecho que Paul Baran como uno de los fundadores de la génesis de la red, estuviera trabajando desde RAND Corporation en una red segura de comunicaciones capaz de sobrevivir a un ataque con armas nucleares con claros fines militares y que todo el desarrollo de la red hubiera surgido en el contexto de la guerr fría, pero sobre todo,  que el proyecto Arpanet hubiera sido financiado con recursos militares provenientes de la agencia DARPA, evidencia que el “MITO”, no es absurdo desde una perspectiva contextual  y representa una parte importante de la problemática del momento histórico y es muy probable que si estos desarrollos no se hubieran dado en el contexto de la Guerra Fría y la amenaza nuclear que la subyace, difícilmente hubieran encontrado la financiación que el proyecto requería.
Enlaces y fuentes que soportan el presente artículo:

 

[1] Nota publicada por la Universidad Politécnica de Cataluña sobre el Origen de Arpanet e Internet

[2] Artículo de la Enciclopedia Británica sobre Joseph Licklider

[3] Artículo de Wikipedia sobre Bolt, Beranek y Newman BBN

[4] Artículo del Periódico La Nación de Argentina sobre los 50 años de Arpanet

[5] Artículo enciclopédico sobre DARPA en Wikipedia

[6] Artículo de Xataca sobre el origen de Internet y Arpanet

[7] Biografía no oficial de Joseph Licklider publicada como parte de una investigación de la Universidad de Murcia

[8] Biografía de Robert Bob Taylor en Wikipedia

[9] Biografía no oficial de Joseph Licklider publicada como parte de una investigación de la Universidad de Murcia

[10] Análisis del portal especializado MicroSiervos sobre el origen de Internet

[11] Artículo de Xataca sobre el origen de Internet y Arpanet

[12] Enlace el documento publicado por Larry Roberts

[13] Artículo de Muy Historia sobre el origen y contexto de la Guerra Fria

[14] Artículo enciclopédico sobre Paul Baran en Wikipedia

[15] Artículo de Wikipedia sobre el origen de Internet

[16] Enlace al Website de la Universidad UCLA en California

[17] Communication Nets: Stochastic Message Flow and Delay, Leonard Kleinrock, ISBN 0486151115, 9780486151113, 224 páginas

[18] Análisis del portal especializado MicroSiervos sobre el origen de Internet

[19] Artículo de Xataca sobre el origen de Internet y Arpanet

[20] Artículo: Retato del Protocolo IP – Portal especializado ionos.es
Descargo de Responsabilidades: Este artículo corresponde a una revisión y análisis contextual en el contexto de la transformación digital en la sociedad de la información, y está debidamente soportado en fuentes académicas y/o periodísticas confiables y verificadas.  Este NO es un artículo de opinión y por tanto la información que contienen no necesariamente representan la postura de Andinalink, LACNIC o la de sus autores o las entidades con las que se encuentren formalmente vinculados, respecto de los temas, personas, entidades u organizaciones mencionadas en el texto.

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.





jueves, 16 de julio de 2020

Internet táctil e IPv6

Introducción
Un concepto (si, ¡otro más !) que seguro aumentará los próximos años será “Internet táctil”, así como suena ¿bonito?, ¡yo lo veo super!, incluso suena como un sueño, todo eso que vimos en películas y en comics los últimos 35 años parece que finalmente será una realidad.
¿Cuales sueños?, unos super lentes, con unos super guantes, manejar un robot a distancia, hacer lo que yo le diga, con una maravillosa visión y virtualmente unos superpoderes, salvar una vida, ufff muy cool, ¿no?. No estamos tan lejos de todo esto

Para apreciar el futuro es importante recordar el pasado
Para los que nacimos antes de los años 80 muy seguramente nos recordaremos un poco de la evolución de los monitores monocromáticos (MDA), CGA, EGA, VGA, SVGA, etc. Cada cambio ya era MUY importante, poder ver colores en la pantalla, poder pintar decentemente algo. Luego esos colores “estáticos” vinieron apoyados con algo de movimiento, luego video e incluso audio, los conceptos de multimedia ya estaban con nosotros (multi medios). El Internet táctil representa algo así como un super-mega-multimedia !

Comencemos: ¿Qué es el Internet Tactil?
No voy a inventar la rueda indicando el término, aquí les dejo un copy/paste tomado de [1]:
“Aunque esta denominación parece nueva no lo es. El término 'internet táctil' fue acuñado a principios de 2014 por el propio profesor Fettweis. La Unión Internacional de Telecomunicaciones (UIT) ya lo definió en un informe en Agosto de 2014. Básicamente, según su definición, va a combinar múltiples tecnologías, tanto a nivel de redes como de aplicaciones. El internet táctil va a permitir la interacción háptica con la retroalimentación visual.”
Si buscamos otros conceptos aquí y allá es básicamente utilizar nuestros sentidos a través de la red, es decir: tacto, olfato, ver, gusto y escuchar. Bueno, es cierto, varios de estos ya lo hacemos hoy en día.

Entonces: ¿por qué el nuevo concepto?
El nuevo concepto viene por varios temas novedosos, principalmente: la palabra háptica que se encuentra en nuestra definición antes indicada. Háptica en el concepto de Internet Táctil se refiere precisamente al sentido del tacto, Por otro lado, según Wikipedia [2]
“.... el significado de la palabra háptica, refiriéndose por exclusión a todo el conjunto de sensaciones no visuales y no auditivas que experimenta un individuo.

¿Para qué servirá el Internet táctil?
Aquí es donde no hay límites, solo me vienen las palabras de Buzz Lightyear en las famosas películas de Toy Story: “Hasta el infinito y más allá”
¿Por dónde comienzo?, tengo una idea, comienza tú mismo, piensa en algo que hayas querido hacer: ¿lanzarte en paracaídas?, ¿nadar con tiburones? ¿ser un bombero durante un incendio? ¿jugar tenis contra Roger Federer? ¿anotar un gol en un mundial de Fútbol?
Otra: ¿qué quieres aprender que pienses que necesite presencia física?, ¿cocinar? ¿una clase de piano o guitarra? ¿clases de natación?.., lo que sea.
Esto es precisamente donde Internet táctil toma relevancia; Internet Tactil busca acercar lo que no se puede hacer remoto, conceptos como hologramas ya son posibles transmitirlos, manipular objetos remotos, robótica, realidad virtual, realidad aumentada, lógicamente IoT,. Vivir con nuestros sentidos lo que no está cerca.
En estos momentos de pandemia podríamos tener a la profesora vía holograma en la sala de tu casa enseñando matemáticas a tu niño. ¿Suena genial, no?
Que opinas de esto: acercar un gurú médico para una operación (ciertamente ya se han hecho varias) muy delicada a un paciente, si hoy es posible, mañana será habitual. Ya incluso imagino un médico recibiendo clases a distancia con holograma, robots, guantes, VR, etc de cómo va a operar remotamente, lo mejor, todo va a salir bien!.
¿Prácticas de diferentes actividades?, virtualmente todo se podrá practicar: música, deportes, cocina, piloto, conductor, odontología y un larguísimo etcétera. Un ejemplo: hoy en día existen “robots limitados” donde se realizan prácticas quirúrgicas. Muy pronto tendremos pacientes humanoides que responderán a lo que el practicante realice y responderán ante un dolor, una acción, un movimiento.
Vamos bien, ¿no?. Antes de continuar, al día de hoy (Julio 2020) Internet Táctil está muy ligado a redes celulares 5G sin embargo mi presentimiento es que no será siempre así, eventualmente saldrán redes 6G, 7G, algún super Wifi, etc, etc.

¿Y en que apoya IPv6 al Internet táctil?
Con todo lo anterior no me cabe la menor duda que la mejor manera de conectar cada cosa será con IPv6. Sin embargo, la mejor manera de responder esta pregunta es pensar: ¿Qué requiere Internet Táctil?. Aquí lo presentamos:
  1. Algo que viene de la mano con Internet táctil es el tiempo de respuesta de los objetos (RTT/Delay de los enlaces en muy pocos milisegundos); imaginemos utilizar un robot a distancia, queremos que sea tan rápido como si estuviese al lado de uno. Si hablamos con un holograma, queremos que sea fluido. IPv6 cada día demuestra que los RTT son mejores a los de IPv4.
  2. Una red muy confiable, al día de hoy sabemos que la pérdida de paquetes en IPv6 es inferior a IPv4 (0.25% vs 0,33%). [3]
  3. Redes resilientes, para ello, IPv6 al no tener que traducir de direcciones (NAT) existe mayor posibilidad de éxito en las conexiones. [7]
  4. Mucho ancho de banda (claro, depende de lo que se desea hacer).
¿Es todo esto suficiente?
La respuesta es mayormente un NO. Podemos tener ancho de banda al orden de Gigas o Teras, no tener pérdida de paquetes, IPv6 en los dispositivos pero aún así la barrera del tiempo de respuesta estará allí, cada milisegundo cuenta. Nos referimos a la interacción humana. Aunque parezca mentira la velocidad de la luz pareciera ser lenta en este contexto, aprox 300.000 km/seg (¿por cierto, sabías que la luz pierde el 31% de su velocidad sobre fibra óptica?) [4]
La velocidad de respuesta es sumamente importante -al menos para gran cantidad de implementaciones-; imaginemos que tenemos unos lentes (tipo Virtual Reality) que nos muestra un paisaje, si movemos la cabeza a la derecha ese paisaje que vemos en los lentes debe cambiar al mismo tiempo (máximo 1 ms), sino, nos sentiremos un poco mal, es llamado Cybersickness [6].

Conclusiones
El uso que se le da a Internet seguirá incrementándose, nuevas ideas saldrán todo el tiempo, las posibilidades de lo que se podrá hacer sobre la red son infinitas.
El tiempo de respuesta parece ser la limitante más complicada a solucionar.
En pocos años tendremos una red más confiable, nos convertirá en personas más productivas. Confío que estas tecnologías apoyaran a los ciudadanos y por ello a sus respectivos países a ser más competitivos y estos beneficios se trasladarán a la población en general. El uso correcto de dichas innovaciones mejorará notablemente la calidad de vida en 1 o 2 generaciones. Hay que aprovecharlo!.

Referencias:
[1] https://innovadores.larazon.es/es/el-internet-tactil-que-viene/
[2] https://es.wikipedia.org/wiki/H%C3%A1ptica
[3] https://www.hindawi.com/journals/mpe/2017/3056475/
[4] https://www.wired.com/2013/03/internet-at-the-speed-of-light/
[5] https://www.youtube.com/watch?v=NOG4zft9rxY&list=PLvZsgabGn2vR4TDEGeUIVJ36RgSV05UGW
[6] https://www.scitecheuropa.eu/virtual-reality-motion-sickness/89447/
[7] https://www.distributednetworks.com/internet-proxy-server/module2/nat-limitations.php

Hirola Infotech Solutions is one of the Best Digital Marketing company in Bangalore,Ranked among the Top digital marketing agencies in Bangalore Digital Marketing, Web Development, Software and mobile app development Company In Bangalore, India Best Best Digital Marketing company in Bangalore,Top digital marketing agencies in Bangalore, ppc, seo Hirola InfoTech Solutions, your number one source for our passion for helping small and medium size businesses has grown us into a full service strategic marketing company ,we are end to end provider of Digital marketing Web development & Applicatio

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:



BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por  Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta  la prim...