FUNDACIÓN UNIVERSITARIA SAN

MATEO
TELECOMUNICACIONES
GESTIÓN DE SEGURIDAD EN REDES
Blanca Lizeth Gómez Téllez

Taller N° 1.

1. Investigue sobre la cabecera TCP, describiendo el funcionamiento que realiza

cada campo.

El segmento TCP consta de una cabecera y un cuerpo para encapsular datos. La cabecera consta de los
siguientes campos:

a. Los campos puerto de origen y puerto de destino (16 bits cada dirección), que
identifican las aplicaciones en los terminales de origen y de destino.
b. El campo número de secuencia (32 bits), que identifica el primer byte del campo de datos. En
el TCP no se numeran segmentos, sino bytes. Por lo tanto, el número de secuencia identifica el
primer byte de los datos que envía el segmento. Al principio de la conexión se asigna un número de
secuencia inicial (ISN, del inglés Initial Sequence Number). A partir de este momento, el TCP
numera los bytes consecutivamente a partir del ISN.
c. El campo número ACK (32 bits). El TCP reconoce datos mediante la técnica
de piggybacking. Al activar un bit de la cabecera (el bit ACK), el TCP tiene en cuenta el número de
secuencia ACK que indica al otro extremo TCP el próximo byte que está dispuesto a recibir. Dicho de
otro modo, el número ACK menos uno indica el
último byte reconocido.
d. El campo longitud de la cabecera (header length) (4 bits), que indica la longitud de la
cabecera, que puede ser variable. La longitud típica es de 20 bytes, pero si el TCP utiliza el campo
de opciones puede llegar a una longitud máxima de 60 bytes. De esta manera, el TCP sabe dónde
empiezan los datos.
e. El campo reservado (reserved) (6 bits). Tal como indica su nombre, está reservado y se
inicializa con ceros.
f. El campo control (6 bits). Cada bit, denominado indicador, señala una función específica del
protocolo cuando está activo (en 1), como las siguientes:
 URG: hay datos urgentes y el campo urgent pointer indica la cantidad de datos
urgentes que se encuentran en el segmento.
 ACK: el campo número ACK indica el siguiente byte que espera recibir la conexión TCP.
Si este campo no está activo, el campo número ACK no tiene ningún significado para el
TCP.
 PSH: invoca la función push en el protocolo. Esta función dice al receptor que entregue
en la aplicación todos los datos que tenga disponibles en la memoria intermedia de
recepción sin esperar a completarlos con datos adicionales. De esta
 manera, los datos no esperan en la memoria intermedia receptora hasta completar un
segmento de dimensión máxima. No se debe confundir con el indicador URG, que indica
que la aplicación ha señalado una porción del segmento como urgente.
 RST: hace un reset de la conexión.
 SYN: resincroniza los números de secuencia.
 FIN: el transmisor ha acabado la conexión.
g. El campo ventana (16 bits) indica cuántos bits componen la ventana de transmisión del protocolo
de control de flujo por ventana deslizante. A diferencia de los protocolos del nivel de enlace, en los
cuales la ventana era constante y contaba tramas, en el TCP la ventana es variable y cuenta bytes.
Con cada segmento transmitido, un extremo TCP advierte el otro extremo de la cantidad de datos
que está dispuesto a recibir en cada momento. De este modo, el extremo que recibe un segmento
actualiza el tamaño de su ventana de transmisión.
h. El campo checksum (16 bits) se utiliza para detectar errores.
i. El campo urgent pointer (16 bits) tiene sentido cuando el bit de control URG está activo e
indica que los datos que envía el origen son urgentes. También identifica el último byte del campo
de datos que es urgente. El receptor procesa estos datos tan rápidamente como puede. La aplicación
es la que indica que estos datos son urgentes; en la recepción, el TCP indica a la aplicación que los
datos son urgentes.

Algunas aplicaciones que utilizan el urgent pointer son, por ejemplo, telnet, rlogin o ftp. En la
librería de sockets, el tráfico urgente se llama tráfico fuera de banda (out of band).

j. El campo opciones TCP permite añadir campos a la cabecera para realizar las siguientes
operaciones:
 Un timestamp para marcar el tiempo en que se transmitió el segmento y monitorar así los
retrasos que experimentan los segmentos desde el origen hasta el destino.
 Aumentar el tamaño de la ventana.
 Indicar el tamaño máximo del segmento (MSS) que el origen está preparado para recibir.
Por lo tanto, el receptor no puede transmitirle segmentos por encima de este valor.

2. Investigue sobre la cabecera IPv4, describiendo el funcionamiento que realiza

cada campo.

IPv4 es uno de los principales protocolos de comunicación de la capa de red. El encabezado del
paquete IPv4 se utiliza para garantizar que este paquete se entregue a su próxima parada en el
camino hacia su dispositivo final de destino.
Un encabezado de paquete IPv4 consta de campos que contienen información importante sobre el
paquete. Estos campos contienen números binarios que son examinados por el proceso de Capa 3.
Los valores binarios de cada campo identifican varias configuraciones del paquete IP. Los campos

más importantes del encabezado de IPv4 son los siguientes:

 Versión = Contiene un valor binario de 4 bits: 0100 establecido para IPv4.

 Servicios diferenciados o DiffServ (DS) = antes conocido como “tipo de servicio” (ToS), es un
campo de 8 bits que se utiliza para determinar la prioridad de cada paquete. Los primeros seis
 bits son el punto de código de servicios diferenciados (DSCP), y los últimos dos bits son los de notificación
de congestión explícita (ECN).
 TTL = Contiene un valor binario de 8 bits que se usa para delimitar el tiempo de vida de un paquete. Si el
campo TTL llega a cero, el router descarta el paquete y envía a la dirección IP de origen un mensaje de
tiempo superado del protocolo de mensajes de control de Internet (ICMP).
 Protocolo = Identifica el protocolo de capa superior, como TCP (6), UDP (17)
 Dirección IP de origen = origen del paquete (dirección IPv4), un valor binario 32 bits.
 Dirección IP de destino = destino del paquete (dirección IPv4), un valor binario 32 bits

Los dos campos de referencia más comunes son las direcciones IP de origen y de destino. Estos campos
identifican de dónde viene el paquete y hacia dónde va. Por lo general, estas direcciones no cambian mientras
se viaja desde el origen hasta el destino. Específicamente, el paquete IPv4 utiliza los campos de
identificación, señaladores y desplazamiento de fragmentos para llevar un control de los fragmentos. Un
router puede tener que fragmentar un paquete IPv4 cuando lo reenvía de un medio a otro con una MTU más
pequeña.

3. Investigue sobre la cabecera IPv6, describiendo el funcionamiento que realiza cada campo.

La cabecera de un paquete IPv6 es, sorprendentemente, más sencilla que la del paquete IPv4. Y
recordemos que además la funcionalidad del protocolo IPv6 es mucho mayor. La cabecera de un
paquete IPv4 es variable, por lo que necesita un campo de tamaño o longitud. Sin embargo, para
simplificar la vida de los enrutadores, IPv6 utiliza un tamaño de cabecera fijo de 40 bytes, que
componen un total de ocho campos:

El campo Versión: el campo Versión es de 4 bits de largo e identifica la versión del protocolo. Para IPv6,
Versión = 6. Nótese que este es el único campo con una función y posición que es consistente entre IPv4 e
IPv6. Todos los demás son diferentes de alguna forma. El tener este campo al comienzo del paquete permite
una rápida identificación de la versión del IP y el paso de ese paquete al protocolo de proceso apropiado:
IPv4 o IPv6.

El campo Traffic Class :el campo Traffic Class es de 8 bits de largo y su intención para los nodos de
origen, o nodos de reenvío, es identificar y distinguir entre diferentes clases o prioridades de paquetes IPv6.
(En la primera publicación de la especificación IPv6, RFC 1883, este campo se llamaba Priority, refejando su
función. Mejoras en este trabajo lo renombraron como campo Class, con una longitud de 4 bits. Trabajo
adicional en el IPNG Meeting, en el plenario de agosto 1997 de Munich, expandió este campo a 8 bits y
redujo el campo Flow Label de 24 bits a 20. El nuevo término Traffic Class, definido en RFC 2460,
identifica más el propósito de este campo). Este campo reemplaza las funciones que fueron proveídas por el
campo Type of Service de IPv4, permitiendo la diferenciación entre categorías del servicio de transferencia
de paquetes. Esta función es comúnmente referida como "Servicio de Diferenciación". En la actualidad,
algunos experimentos están siendo conducidos en esta área de la tecnología, especialmente en soporte de
transporte de señal dependiente del tiempo, como voz o video sobre IP. Estos tres requerimientos generales
para el campo Traffic Class son stated en RFC 2460:

 Para paquetes que son originados en un nodo por un protocolo de capa más alta, ese protocolo
de capa más alta especificaría el valor de los bits del campo Traffic Class. El valor por default
es cero.
 Nodos que soportan una función particular que usa bits de Traffic Class pueden cambiar los
valores de los bits en paquetes que ellos originan, reenvían o reciban. Sin un nodo no soporta esa
función particular, no debe cambiar ninguno de los bits de Traffic Class.
Los protocolos de capa más alta no deben asumir que los valores de los bits de Traffic Class en un paquete
recibido son los mismos valores que fueron originalmente transmitidos. En otras palabras, un nodo
intermediario puede ser permitido a cambiar (y haber cambiado) los bits de Traffic Class en tránsito.

El campo Flow Label: el campo Flow Label es de 20 bits de longitud, y puede ser usado por un host para
solicitar manejo especial para ciertos paquetes, como aquellos con una calidad de servicio de no default o de
tiempo real. En esta primera versión de la especificación IPv6, RFC 1883, este campo era de 24 bits de
longitud, pero cuatro de estos bits han sido ahora colocados en el campo Traffic Class, como se discutió en la
sección anterior [40]. RFC 1809, "Usando el Campo Flow Label en IPv6", describe algunas de las
investigaciones más tempranas en la materia, como el campo Class, Flow Label es sujeto de investigación
actualmente y puede cambiar según la experiencia de la industria madura.

El campo Payload Field: el campo Payload Field es un entero no asignado de 16 bits que mide la
longitud, dada en octetos, de la carga (ejemplo, el balance del paquete IPv6 que sigue al encabezado base de
IPv6). Los encabezados de extensión opcional son considerados parte de la carga, junto con cualquier
protocolo de capa más alta, como TCP, FTP y así. El campo Payload Length es similar al campo Total
Length de IPv4, excepto que las dos medidas operan en diferentes campos. Payload Length (IPv6) mide los
datos después del encabezado, mientras Total Length (IPv4) mide los datos y el encabezado. Las cargas más
grandes de 65,535 son permitidas y son llamadas cargas Jumbo. Para indicar una carga jumbo, el valor de
Payload Length está fijado en cero y la longitud de la carga actual es especificada en una opción que es
cargada en la extensión del encabezado Hop-by-Hop.

El campo Next Header tiene 8 bits de longitud e identifica el encabezado inmediatamente siguiente del
encabezado de IPv6. Este campo usa los mismos valores que el campo Protocol de IPv4.

Un paquete IPv6, que consiste en un paquete de encabezado IPv6 más su carga, puede consistir de cero,
uno o más encabezado de extensión. Muchos de los encabezados de extensión también emplean un campo
Next Header.

El campo Hop Limit: el campo Hop Limit tiene 8 bits de longitud, y va decreciendo en 1 por cada nodo que
reenvía el paquete. Cuando Hop Limit se iguala a cero, el paquete es descartado y un mensaje de error es
retornado. Este campo es similar al campo Time-to-Live (TTL) encontrado en IPv4, con una excepción clave.
El campo Hop Limit (IPv6) mide el máximo de saltos (hops) que pueden ocurrir mientras el paquete es enviado
por varios nodos. El campo TTL (IPv4) puede ser medido en saltos o segundos. Nótese que con Hop Limit
usada en IPv6, la base del tiempo no está disponible más.

El campo Source Address: el campo Source Address es un campo de 128 bits que identifica el
originador del paquete. El formato de este campo es más ampliamente definido en RFC 2373 [41].

El campo Destination Address: el campo Destination Address es un campo de 128 bits que identifica el
destinatario que tiene la intención de recibir el paquete. Una importante distinción es que el destinatario que
tiene la intención de recibir el paquete, puede no ser el destinatario final, como el Header Routing puede ser
empleado para especificar la ruta que el paquete toma desde su fuente, a través de destinatario(s)
intermedio(s), y así hasta su destinatario fin

4. ¿Describa las diferencias entre la cabecera IPv4 y IPv6, cuales campos de IPv4 no
funcionan en IPv6, por qué?
 5. Autoconfiguración y reconfiguración sin servidores ("enchufar y funcionar", "plug and play"):
con esta característica, Internet se simplifica, en el sentido de que es más fácil conectar
automáticamente cualquier dispositivo a la red [35]. No hay motivos para pedir a los usuarios que
configuren nunca más los dispositivos, especialmente, considerando que los nuevos dispositivos no
serán "sencillos" ordenadores con teclado y pantalla, sino electrodomésticos, dispositivos de todo
tipo, sensores, entre otros; los cuales no tienen este tipo de interfaces para poder ser configurados. En
IPv4 esto no se puede realizar, salvo que en la red se haya instalado un servidor (para el protocolo
DHCP), lo que implica un coste superior para el propio servidor y su mantenimiento.
6. Mecanismos de movilidad más eficientes y robustos: IPv6 ha sido diseñado bajo la perspectiva
de un nuevo mundo "nómada". Usuarios y dispositivos tienen a movilizarse más que nunca. La
conectividad es importante, incluso cuando las personas se desplazan, de tal forma que se puedan
utilizar servicios mejorados, especialmente en entornos sin cables. IPv4 también permite movilidad,
pero es muy ineficiente comparada con la movilidad en IPv6.
7. Seguridad extremo a extremo con autenticación y encriptación embebidas en la capa IP:
IPsec es el protocolo de seguridad, el mismo que en el caso de IPv4. La principal diferencia es que
IPv4 no obliga al soporte de IPsec, lo que implica que no siempre está disponible. Además, en
IPv4, debido al uso de NAT, a menudo no es posible utilizar IPsec extremo a extremo, salvo que se
posean los conocimientos necesarios para configurar un túnel o VPN (Red Privada Virtual, Virtual
Private Network), entre las dos estaciones que desean establecer dicha comunicación y se
atraviesen los NAT. Este aspecto se describe en profundidad posteriormente en este mismo
capítulo.
8. Cabecera con un formato mejorado e identificación de flujos: los diseñadores del protocolo
IPv6 sacaron provecho de los conocimientos adquiridos con la experiencia por el uso de IPv4
durante los últimos años, de forma que pudiera mejorarse la forma en que los datos se codifican
para formar la cabecera del protocolo IPv6 y, consecuentemente, mejorar la operación de la red. Al
mismo tiempo que la cabecera ha sido simplificada, se han agregado nuevas funcionalidades, siendo
una de ellas la identificación de flujos, lo cual permitirá, en un futuro próximo, una mejor operación
de los mecanismos de calidad de servicio (QoS) en Internet.
9. Soporte mejorado de multidifusión: IPv6 incluye soporte mejorado de multidifusión
(multicast), dado que se trata de una característica embebida en el protocolo, la cual es
fundamental para el uso de redes de banda ancha para la distribución de contenidos.
10. Extensibilidad: soporte mejorado para opciones / extensiones. Por último, pero no menos
importante, IPv6 ha sido diseñado teniendo en cuenta las posibilidades para su crecimiento. No se
desea repetir errores y llegar a la situación de descubrir, en unos pocos años, que, del mismo modo
que se diseñó IPv4, de tal forma que ha llegado a ser un impedimento para la extensión de Internet,
pueda ocurrir con IPv6. La forma en que IPv6 trabaja, permite incorporar nuevas características o
piezas del protocolo (las que se denominan cabeceras de extensión), sin necesidad de actualizar
todos los dispositivos de la red. Solo aquellos dispositivos que precisen usar determinadas
extensiones tienen que ser actualizados, del mismo modo que, en la actualidad, todos los sistemas
operativos y aplicaciones son frecuentemente actualizados, de una forma automática, transparente
para el usuario.

5. Investigue sobre la cabecera UDP, describiendo el funcionamiento y actividades

que realiza cada campo dentro de la cabecera.

Como es típico en todos los protocolos, los paquetes UDP consisten en una cabecera (header) y los datos
reales del usuario. La cabecera UDP contiene toda la información necesaria para la transmisión de datos
utilizando el protocolo de transporte y hace que un paquete UDP se pueda identificar como tal. La cabecera
UDP consta de 4 campos y está dividida en 2 bloques de 32 bits con la siguiente estructura:
 Bits 0–15 Bits 16–31

Cero Puerto de origen Puerto de destino

32 Longitud del mensaje Suma de verificación

Los primeros 16 bits de la cabecera identifican el puerto de origen desde el que se ha enviado un
datagrama concreto. El receptor necesita esta información para poder responder al paquete. Ya que UDP
funciona sin conexión y básicamente no requiere ninguna comunicación entre el emisor y el receptor, el
campo de puerto de origen es opcional. En caso de no ser utilizado, el puerto de origen debe ser puesto a
cero.

En el siguiente campo se especifica el puerto de destino, es decir, se indica el servicio solicitado. Esta
información es obligatoria, al contrario que el puerto de origen, porque si no, no sería posible asignar
correctamente el datagrama.

El campo longitud define la longitud del datagrama. Se compone de la longitud de la

cabecera (8 bytes) y el tamaño de los datos de usuario (máximo teórico: 65.535 bytes). Cuando se
utiliza Ipv4, el límite real para los datos de usuario es de 65 507 bytes, tras deducir las cabeceras IP y UDP.
En Ipv6 se aceptan paquetes (llamados jumbogramas) que superan ese límite. Según la RFC 2675 , el valor
del campo de longitud se pone a cero en esos casos.

La cabecera UDP se completa con la checksum o suma de comprobación, que se utiliza para detectar
errores durante la transmisión. De esta manera, se puede detectar si los datos han sufrido alguna alteración en
el camino. No obstante, los paquetes detectados se descartan y no se cursa una nueva solicitud. Para generar
la suma, se utilizan partes

 de la cabecera UDP,
 de los datos del usuario
 y de la conocida como pseudocabecera (que contiene información sobre la cabecera IP).

La suma de comprobación es opcional en IPv4, pero la mayoría de las aplicaciones la utilizan por defecto.
Si no se realiza la suma, se le da a este campo el valor cero. Si se utiliza UDP con IPv6, la suma de
comprobación es obligatoria.

6. Investigue sobre la cabecera ICMP la descripción de los campos de la cabecera y

los mensajes de respuesta.

Para intercambiar datos de estado o mensajes de error, los nodos recurren al Internet Control Message
Protocol (ICMP) en las redes TCP/IP. Concretamente, los servidores de aplicaciones y las puertas de acceso
como los routers, utilizan esta implementación del protocolo IP para devolver mensajes sobre problemas con
datagramas al remitente del paquete. Aspectos como la creación, la funcionalidad y la organización dentro de
la amplia gama de protocolos de Internet se especificaron en 1981 en la RFC 792. En el caso de la sexta
versión del Internet Protocol (IP),
la implementación específicaICMPv6 fue definida en la RFC 4443.
Por definición, ICMP es un protocolo autónomo aun cuando los diferentes mensajes están incluidos en
paquetes IP tradicionales. Para tal fin, el protocolo de Internet trata a la implementación opcional como
un protocolo de capas superiores. Los diversos servicios de red que se suelen utilizar hoy en día, como
traceroute o ping, se basan en el protocolo ICMP.

Los mensajes ICMP se transmiten como datagramas IP normales, con el campo de cabecera "protocolo" con
un valor 1, y comienzan con un campo de 8 bits que define el tipo de mensaje de que se trata. A continuación
viene un campo código, de o bits, que a veces ofrece una descripción del error concreto que se ha producido y
después un campo suma de control, de 16 bits, que incluye una suma de verificación de errores de
transmisión. Tras estos campos viene el cuerpo del mensaje, determinado por el contenido del campo "tipo".
Contienen además los 8 primeros bytes del datagrama que ocasionó el
error. Los principales tipos de mensaje ICMP son los siguientes:

Mensajes informativos

Entre estos mensajes hay algunos de suma importancia, como los mensajes de petición de ECO (tipo 8) y los
de respuesta de Eco (tipo 0). Las peticiones y respuestas de eco se usan en redes para comprobar si existe una
comunicación entre dos host a nivel de capa de red, por lo que nos pueden servir para identificar fallos en este
nivel, ya que verifican si las capas física (cableado), de enlace de datos (tarjeta de red) y red (configuración
IP) se encuentran en buen estado y configuración.

Mensajes de error

En el caso de obtener un mensaje ICMP de destino inalcanzable, con campo "tipo" de valor 3, el error
concreto que se ha producido vendrá dado por el valor del campo "código", pudiendo presentar los siguientes
valores que se muestran en la parte derecha.

Este tipo de mensajes se generan cuando el tiempo de vida del datagrama a llegado a cero mientras se
encontraba en tránsito hacia el host destino (código=0), o porque, habiendo llegado al destino, el tiempo de
reensamblado de los diferentes fragmentos expira antes de que lleguen todos los necesarios (código=1).

Los mensajes ICMP de tipo= 12 (problemas de parámetros) se originan por ejemplo cuando existe
información inconsistente en alguno de los campos del datagrama, que hace que sea imposible procesar el
mismo correctamente, cuando se envían datagramas de tamaño incorrecto o cuando falta algún campo
obligatorio.

Por su parte, los mensajes de tipo=5 (mensajes de redirección) se suelen enviar cuando, existiendo dos o más
routers diferentes en la misma red, el paquete se envía al router equivocado. En este caso, el router receptor
devuelve el datagrama al host origen junto con un mensaje ICMP de redirección, lo que hará que éste
actualice su tabla de enrutamiento y envíe el paquete al siguiente router.