Ir al contenido

Entradas etiquetadas como ‘estándares’

20
jul

Introducción a OSPF

En este post intentaré dar una introducción muy breve al protocolo OSPF. Iré dejando unos cuántos links para poder ampliar el tema, aunque probablemente en un futuro esté escribiendo algo más sobre OSPF.

Introducción

OSPF es un protocolo de enrutamiento dinámico estándar definido en la RFC 2328 para IPv4 y en la RFC 5340 para IPv6. Su función (por ser un protocolo de enrutamiento) es la de recolectar la información necesaria para armar las tablas de ruteo. Se lo puede clasificar como protocolo de estado de enlace y, a su vez, dentro del grupo de los IGP (Interior Gateway Protocol), dado que está pensado para ser utilizado dentro del dominio de un sistema autónomo.

Características básicas de OSPF

  • Estándar y de especificación abierta.
  • Intra sistema autónomo.
  • Converge rápidamente.
  • Soporta diseño jerárquico, lo que lo hace muy escalable.
  • Envía actualizaciones disparadas y sólo con la información que cambia.
  • Se comunica utilizando multicast.
  • Soporta autenticación.

Información utilizada por OSPF

OSPF mantiene tres tablas:

  • Tabla de enrutamiento: el objetivo de cualquier protocolo de enrutamiento, lograr una tabla que dada una red de destino indique el camino para alcanzarla.
  • Tabla de adyacencias (o de vecinos): en esta tabla se mantiene la información sobre los vecinos con los cuáles se realizan intercambios OSPF.
  • Tabla de topología (o base de datos de LSA): en esta tabla se almacenan todos los LSA recibidos de toda la red. Los LSA son paquetes OSPF que contienen información sobre rutas (red y camino para alcanzarla). De esta manera es como un router OSPF conoce la topología completa de la red. De hecho, utilizando la tabla de topología es posible dibujar toda la red con los costos de cada enlace.

Algoritmo OSPF

El algoritmo de OSPF puede resumirse en los siguientes pasos:

  1. Lo primero que se necesita es formar adyacencias con los vecinos directamente conectados. Por ello, todos los routers de la red envían paquetes de saludo por todas sus interfaces. Con esta información, un router OSPF conoce sus vecinos que será con los que se mantendrá en contacto para enviar la información de enrutamiento.
  2. Si se tratara de una red multiacceso como Ethernet entonces deberá elegirse un router designado (DR) y un router resignado de respaldo (BDR). El objetivo es disminuir el tráfico de enrutamiento intercambiado en la red haciendo que los routers se comuniquen sólo con el DR y el BDR. En un próximo post explicaré con más detalle este tema.
  3. Una vez establecidas las adyacencias, el siguiente paso es enviar la información de enrutamiento mediante paquetes LSU (un paquete que uno o más LSA) a todos los vecinos, lo que provoca una inundación (flooding) de LSU en la red.
  4. Terminado el paso anterior, todos los routers tienen la tabla de topología completa y ya es posible calcular las rutas más cortas hacia cada destino, lo que se hace ejecutando el algoritmo de Dijkstra (o algoritmo de SPF). Este es un proceso que ejecuta cada router OSPF por sí mismo y sin intervención de ningún otro router.
  5. En el paso anterior se arma la tabla de enrutamiento con lo cuál luego del mismo un router OSPF ya puede comenzar a enrutar paquetes. A partir de ahora el intercambio entre los equipos serán:
    • Paquetes de saludo: se envían de forma periódica para mantener las adyacencias y detectar la caída de un equipo vecino.
    • Actualizaciones de estado de enlace (LSU): enviadas sólo si el estado de algún enlace cambia.
12
jul

¿Qué es una RFC?

En el mundo de las redes es de todos los días toparse con RFCs, es por ello que es fundamental entender qué son y cómo utilizarlas.

RFC es una sigla en inglés (Request For Comments) que significa solicitud de comentarios y consiste en un documento que puede ser escrito por cualquier persona y que contiene una propuesta para una nueva tecnología, información acerca del uso de tecnologías y/o recursos existentes, propuestas para mejoras de tecnologías, proyectos experimentales y demás.

Las RFC conforman básicamente la documentación de protocolos y tecnologías de Internet, siendo incluso muchas de ellas estándares. Las mismas son matenidas por el IETF (Internet Engineering Task Force) y son accesibles por cualquier persona debido a que son publicadas on-line y sin restricciones. Pueden consultarse las mismas en la página de búsqueda de RFCs del IETF.

La metodología que se utiliza con las RFC es asignarle a cada una un número único que la identifique y que es el consecutivo de la última RFC publicada. Una RFC ya publicada jamás puede modificarse, no existen varias versiones de una RFC. Lo que se hace, en cambio, es escribir una nueva RFC que deje obsoleta o complemente una RFC anterior.

Para crear una nueva RFC puede utilizarse el sitio RFC Editor, desde donde se envían las nuevas propuestas que eventualmente podrán ser adoptadas como RFC y, si son de gran interés, convertirse en estándares. En el mismo sitio de RFC Editor, existe una FAQ muy útil para evacuar algunas dudas.

29
jun

Codificación de colores en conectores UTP

Algo que siempre es útil es tener a mano la codificación de colores que se utilizan para armar los conectores de un cable UTP, definida en las normas EIA/TIA T568A y T568B. Dejo ambas normas a continuación, acompañadas de un diagrama con la numeración de los pines en un conector RJ45:

T568A

T568A

T568B

T568B

Pines de conector RJ45

Pines de conector RJ45

22
jun

FTP activo vs. pasivo

El protocolo FTP es utilizado para transferencia de archivos entre dos hosts remotos, definido en la RFC 959. El mismo soporta básicamente dos modos de funcionamiento, FTP activo y FTP pasivo.

El protocolo FTP funciona de una forma que es denominada fuera de banda. Por un lado, utiliza una conexión persistente para control (envío de comandos) y otra conexión a demanda para datos (se abre sólo cuando hay una transferencia real de información). Por ello se verá que el mismo utiliza 2 puertos TCP: 21 para control y 20 para datos.

En el modo activo trabaja básicamente de la siguiente manera:

  • El cliente A inicia la conexión con un puerto TCP origen aleatorio N al puerto destino TCP 21 del servidor B.
  • El cliente comienza a escuchar peticiones en el puerto TCP N+1 y se lo indica al servidor.
  • El servidor B será luego el que, al transferir información al cliente, se conectará al puerto TCP destino N+1 del cliente A con puerto TCP origen 20.

El siguiente diagrama muestra el intercambio anterior:

Funcionamiento de FTP activo

Funcionamiento de FTP activo

El gran problema con el modo activo es que no funciona con clientes detrás de NAT, pues el servidor no puede alcanzar el puerto en el que el cliente escucha. También implica un problema de seguridad, dado que el cliente no debería recibir conexiones sino generarlas.

Lo anterior se soluciona con el modo pasivo, donde es el cliente el que inicia ambas conexiones. En este caso el protocolo es el que sigue:

  • El cliente A inicia una conexión desde un puerto TCP origen aleatorio N al puerto destino TCP 21 del servidor B.
  • El servidor le responde con un puerto donde estará escuchando sus peticiones.
  • El cliente A inicia las conexiones de datos desde otro puerto TCP origen aleatorio N+1 al puerto TCP destino especificado por el servidor.

El siguiente diagrama refleja lo explicado:

Funcionamiento de FTP pasivo

Funcionamiento de FTP pasivo

Ahora bien, el problema en este caso es segurizar el servidor, puesto que como el puerto en el que escuchará las peticiones del cliente es aleatorio es difícil diagramar el firewall para el mismo (aunque algunos programas permiten especificar el rango de puertos posibles).

15
may

Autenticación CHAP

El martes un colega nos dió una explicación de CHAP que me resultó muy fácil de entender. Para ello usó algunos gráficos que están en la explicación de autenticación CHAP en PPP en la página de Cisco. Me tomé el trabajo de traducirlo para compartirlo con ustedes. Espero que les sea útil.

Configuración

Para configurar CHAP de manera genérica es necesario:

  • Definir en el cliente el nombre de usuario y contraseña a utilizar.
  • Definir en el cliente quién es el autenticador.
  • Definir en el cliente el nombre de usuario y contraseña del autenticador.
  • Definir en el autenticador un nombre de usuario y contraseña para el cliente.

IMPORTANTE: la contraseña DEBE coincidir en ambos extremos.

Procedimiento

El primer paso se produce cuando el usuario (léase cliente) se conecta al equipo 3640-1. Tener en cuenta que el equipo 766-1 es el autenticante y el 3640-1 el autenticador.

El servidor responde con los siguientes datos:

  • 01: identificador de paquete de desafío CHAP.
  • ID: identificador del intercambio. Se usará para identificar tramas de una misma conversación.
  • Nº aleatorio: utilizado luego para computar un hash.
  • Nombre: el servidor envía su hostname. También podría utilizar otro nombre definido.

Además, el servidor almacena para sí el número aleatorio y el ID que envía.

3) Luego, el cliente:

  • Toma el ID y lo inyecta en el generador de hash MD5.
  • Toma el Nº aleatorio y lo inyecta en el generador de hash MD5.
  • Utiliza el nombre enviado por el otro equipo para buscar la contraseña y la agrega al generador de hash MD5.

4) El cliente utiliza el hash que generó en el paso anterior para armar una nueva trama y envía en ella:

  • 02: identificador de respuesta CHAP.
  • ID: el mismo que recibió de su par.
  • Hash: el generado por él en el paso anterior.
  • Nombre: manda su hostname u otro nombre definido.

5) Ahora, el servidor debe comprobar la autenticidad del cliente. Para ello realiza un nuevo cálculo:

  • ID: lo usa para indexar la búsqueda del Nº aleatorio que envió al cliente y lo inyecta al generador de hash MD5.
  • Nº aleatorio: lo inyecta al generador de hash MD5.
  • Utiliza el nombre enviado por el otro equipo para indexar la búsqueda de la contraseña.

Luego de realizar lo anterior el servidor compara si el hash que envió el cliente es igual al que obtuvo él. Entonces realiza el siguiente paso.

6) En el último paso se indica al cliente si la autenticación fue exitosa o falló.

  • 03/04: identificador de autenticación CHAP satisfactoria / identificador de autenticación CHAP fallida.
  • ID: el mismo que hasta el momento.
  • Bienvenido: un mensaje para el usuario.

Notas sobre funcionamiento

  • El ejemplo anterior muestra la autenticación unidireccional. Si fuera bidireccional el mismo procedimiento se repetiría cambiando los papeles.
  • El tráfico que viaja entre ambos va encriptado.
  • Notar que ”’la contraseña nunca viaja por el medio”’. Esto hace que CHAP sea aún más seguro.