Pruebas con fragmentación de fragmentos de paquetes

Fecha: durante la cuarentena de marzo del 2020

Escenario

Este laboratorio lo tengo pendiente desde hace mucho, muchas veces tuve problemas de MTU trabajando con

túneles GRE sobre IPSec, L2TP sobre IPSec, o simplemente IPSec o tráfico DF sobre MTU mas chicas en los ISP.

En esta oportunidad lo voy a simular con equipos Miktorik que es lo unico que tengo en casa, la cuarentena me

encontró con mis equipos Cisco en el trabajo y no los pude traer a casa, igual podemos estudiar el concepto.

Cuando “tunelamos tráfico” le agregamos nuevas cabeceras IP y de protocolos tuneling (GRE, ESP) y tal vez trailers

de control, lo cual agrega mucha mas carga administrativa para un mismo payload.

En este gráfico podemos ver la diferencia de payloads para un mismo tamaño de trama, y como aumenta la carga cuando

agregamos cabeceras. Por ejemplo arriba es la trama que lleva un “ping” tal como hicimos las pruebas, la siguiente es una

trama que lleva un paquete IP con tráficoTCP, podemos ver que el payload disminuye.

La tercera es una trama que lleva un paquete encapsulado en un tunel GRE, y la inferior es una trama que lleva un paquete

IP encapsulado en un tunel GRE over IPSec.

La idea de este documento es generar tráfico con tamaños de MTU para que se puedan fragmentar y estudiar que sucede,

también poder llegar a generar “fragmentos de fragmentos” a partir de MTUs mas chicas durante el recorrido del paquete

y verlos en una captura de Wireshark y hacer algunas cuentas para ver que ocurre.

1.- Pruebas de MTU máxima:

Para esto generamos tráfico con el flag Don’ Fragment (DF) en 1, por lo tanto recibiremos un mensaje ICMP con la

necesidad y la imposibilidad de fragmentar, por lo tanto el trafico se descarta.

C:\>ping 192.168.1.10 -l 1400 -f

Haciendo ping a 192.168.1.10 con 1400 bytes de datos:

Es necesario fragmentar el paquete pero se especificó DF.

Frame 1: 1442 bytes on wire (11536 bits), 1442 bytes captured (11536 bits) on interface 0 (trama/paquete enviado)

Ethernet II, Src: e8:6a:64:dc:e2:f5, Dst: d4:ca:6d:a4:2e:26

Internet Protocol Version 4, Src: 192.168.2.10, Dst: 192.168.1.10

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 1428

Identification: 0x77d6 (30678)

Flags: 0x4000, Don't fragment

0... .... .... .... = Reserved bit: Not set

.1.. .... .... .... = Don't fragment: Set (este es el bit que indica que no está permitida la fragmentación)

..0. .... .... .... = More fragments: Not set

...0 0000 0000 0000 = Fragment offset: 0

Time to live: 128

Protocol: ICMP (1)

Header checksum: 0x0000 [validation disabled]

[Header checksum status: Unverified]

Source: 192.168.2.10

Destination: 192.168.1.10

Internet Control Message Protocol

Type: 8 (Echo (ping) request) (esta es la solicitud de eco)

Code: 0

Checksum: 0x540c [correct]

[Checksum Status: Good]

Identifier (BE): 1 (0x0001)

Identifier (LE): 256 (0x0100)

Sequence number (BE): 16260 (0x3f84)

Sequence number (LE): 33855 (0x843f)

[No response seen]

Data (1400 bytes)

Frame 2: 590 bytes on wire (4720 bits), 590 bytes captured (4720 bits) on interface 0 (error ICMP recibido)

Ethernet II, Src: d4:ca:6d:a4:2e:26, Dst: e8:6a:64:dc:e2:f5

Internet Protocol Version 4, Src: 192.168.2.1, Dst: 192.168.2.10

Internet Control Message Protocol

Type: 3 (Destination unreachable) (no se puede alcanzar justamente por no fragmentar)

Code: 4 (Fragmentation needed) (este es el motivo)

Checksum: 0x6154 [correct]

[Checksum Status: Good]

Unused: 0000

MTU of next hop: 1300 (aqui nos indica cual es la MTU, este valor es utilizado por Path MTU Discovery)

Internet Protocol Version 4, Src: 192.168.2.10, Dst: 192.168.1.10

Internet Control Message Protocol

Type: 8 (Echo (ping) request)

Code: 0

Checksum: 0x540c [unverified] [in ICMP error packet]

[Checksum Status: Unverified]

Identifier (BE): 1 (0x0001)

Identifier (LE): 256 (0x0100)

Sequence number (BE): 16260 (0x3f84)

Sequence number (LE): 33855 (0x843f)

Data (520 bytes)

C:\>ping 192.168.1.10 -l 1300 –f (el payload es de 1300, mas las cabeceras y CRC nos pasamos en 46 bytes)

Haciendo ping a 192.168.1.10 con 1300 bytes de datos:

Es necesario fragmentar el paquete pero se especificó DF.

---resumido---

2.- Pruebas de fragmentación múltiple (fragmento de fragmento):

Podemos ver gráficamente el proceso de reenvío de las tramas aquí

Podemos ver gráficamente el proceso de fragmentación y offset de los payloads de las tramas aquí

2.1.- Generamos tráfico fragmentable:

C:\>ping 192.168.1.10 -l 1400

Haciendo ping a 192.168.1.10 con 1400 bytes de datos:

Respuesta desde 192.168.1.10: bytes=1400 tiempo=2ms TTL=126

Respuesta desde 192.168.1.10: bytes=1400 tiempo=3ms TTL=126

Respuesta desde 192.168.1.10: bytes=1400 tiempo=2ms TTL=126

2.2.- Vista desde el emisor del ping:

2.3.- Vista desde el receptor del ping:

3. Análisis de la fragmentación:

3.1.- Análisis del envío:

Frame 1: 1442 bytes on wire (11536 bits), 1442 bytes captured (11536 bits) on interface 0 (trama/paquete enviado)

Ethernet II, Src: e8:6a:64:dc:e2:f5, Dst: d4:ca:6d:a4:2e:26

Internet Protocol Version 4, Src: 192.168.2.10, Dst: 192.168.1.10

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 1428

Identification: 0xda47 (55879) (todos los fragmentos del mismo paquete tienen este mismo ID)

Flags: 0x0000

0... .... .... .... = Reserved bit: Not set

.0.. .... .... .... = Don't fragment: Not set

..0. .... .... .... = More fragments: Not set

...0 0000 0000 0000 = Fragment offset: 0

Time to live: 128

Protocol: ICMP (1)

Header checksum: 0x0000 [validation disabled]

[Header checksum status: Unverified]

Source: 192.168.2.10

Destination: 192.168.1.10

Internet Control Message Protocol (cabecera ICMP)

Type: 8 (Echo (ping) request)

Code: 0

Checksum: 0x5332 [correct]

[Checksum Status: Good]

Identifier (BE): 1 (0x0001)

Identifier (LE): 256 (0x0100)

Sequence number (BE): 16478 (0x405e)

Sequence number (LE): 24128 (0x5e40)

[Response frame: 3]

Data (1400 bytes)

Frame 2: 1314 bytes on wire (10512 bits), 1314 bytes captured (10512 bits) on interface 0 (fragmento recibido)

Ethernet II, Src: d4:ca:6d:a4:2e:26, Dst: e8:6a:64:dc:e2:f5

Internet Protocol Version 4, Src: 192.168.1.10, Dst: 192.168.2.10

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 1300

Identification: 0x016c (364) (ver que el ID es diferente al paquete anterior porque es la respuesta)

Flags: 0x2000, More fragments

0... .... .... .... = Reserved bit: Not set

.0.. .... .... .... = Don’t fragment: Not set

..1. .... .... .... = More fragments: Set (este flag indica que hay mas fragmentos)

...0 0000 0000 0000 = Fragment offset: 0 (con esto vemos que el payload comienza aquí)

Time to live: 126

Protocol: ICMP (1)

Header checksum: 0x9218 [validation disabled]

[Header checksum status: Unverified]

Source: 192.168.1.10

Destination: 192.168.2.10

Reassembled IPv4 in frame: 3

Data (1280 bytes) (no hay cabecera ICMP)

Frame 3: 162 bytes on wire (1296 bits), 162 bytes captured (1296 bits) on interface 0 (fragmento con cabecera recibido)

Ethernet II, Src: d4:ca:6d:a4:2e:26, Dst: e8:6ª:64:dc:e2:f5

Internet Protocol Version 4, Src: 192.168.1.10, Dst: 192.168.2.10

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 148

Identification: 0x016c (364) (todos los fragmentos del mismo paquete tienen este mismo ID)

Flags: 0x00a0

0... .... .... .... = Reserved bit: Not set

.0.. .... .... .... = Don't fragment: Not set

..0. .... .... .... = More fragments: Not set

...0 0000 1010 0000 = Fragment offset: 160

Time to live: 126

Protocol: ICMP (1)

Header checksum: 0xb5f8 [validation disabled]

[Header checksum status: Unverified]

Source: 192.168.1.10

Destination: 192.168.2.10

[2 IPv4 Fragments (1408 bytes): #2(1280), #3(128)]

Internet Control Message Protocol (cabecera ICMP)

Type: 0 (Echo (ping) reply)

Code: 0

Checksum: 0x5b32 [correct]

[Checksum Status: Good]

Identifier (BE): 1 (0x0001)

Identifier (LE): 256 (0x0100)

Sequence number (BE): 16478 (0x405e)

Sequence number (LE): 24128 (0x5e40)

[Request frame: 1]

[Response time: 2.582 ms]

Data (1400 bytes)

3.2.- Análisis de la recepción:

En la recepcion del ping (PC del lado izquierdo) vemos que los paquetes llegan en un orden no esperado, primero parte

del fragmento realizado en el router 2, luego el fragmento de ese fragmento, y el paquete original con la cabecera ICMP.

Podemos ver gráficamente el proceso de reenvío de las tramas aquí , el proceso se llama LIFO (Last In First Out.

<- click para ver en detalle

Estimo que si las pruebas se hubiesen realizado con equipos Cisco el orden de la recepción tal vez fuera distinto, pero esto

es una buena oportunidad para analizar algo que se sale de lo esperado.

Para entender cómo los fragmentos pertenecen a un determinado paquete:

En las capturas, podremos ver dentro de la cabecera IP un campo llamado Identification seguido de un valor en hexadecimal,

este campo se replicará en los fragmentos del paquete original. Mediante el valor de ID + el offset los dispositivos reconocen

y reensamblan los fragmentos en un único paquete similar al original.

Para entender los valores offset:

Si enviamos 1300 bytes en el primer fargmento, el segundo tendrá un offset de 1300 y 160 de payload, el tercer fragmento

tendrá un offset de 160 (1300+160), pero Wireshark nos mostrará estos valores divido 8.

También tenemos un detalle aquí.

For Wireshark, multiplies the number in the Fragment Offset field by 8 to show us the actual offset in bytes,

rather than the number of 8-byte blocks. Fuente: wireshark.org

Frame 1: 1210 bytes on wire (9680 bits), 1210 bytes captured (9680 bits) on interface 0 (fragmento recibido)

Ethernet II, Src: 00:0c:42:36:17:5f, Dst: 00:1b:38:7e:f1:71

Internet Protocol Version 4, Src: 192.168.2.10, Dst: 192.168.1.10

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 1196

Identification: 0xda47 (55879) (todos los fragmentos del mismo paquete tienen este mismo ID)

Flags: 0x2000, More fragments

0... .... .... .... = Reserved bit: Not set

.0.. .... .... .... = Don't fragment: Not set

..1. .... .... .... = More fragments: Set (este flag indica que hay mas fragmentos)

...0 0000 0000 0000 = Fragment offset: 0 (con esto vemos que el payload comienza aquí)

Time to live: 126 (nos indica que el paquete pasó por dos routers)

Protocol: ICMP (1) (nos indica que es el payload es ICMP, pero no cual tipo de mensaje ICMP)

Header checksum: 0xb9a4 [validation disabled]

[Header checksum status: Unverified]

Source: 192.168.2.10

Destination: 192.168.1.10

Reassembled IPv4 in frame: 3

Data (1176 bytes) (no hay cabecera ICMP)

Frame 2: 138 bytes on wire (1104 bits), 138 bytes captured (1104 bits) on interface 0 (fragmento recibido)

Ethernet II, Src: 00:0c:42:36:17:5f, Dst: 00:1b:38:7e:f1:71

Internet Protocol Version 4, Src: 192.168.2.10, Dst: 192.168.1.10

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 124

Identification: 0xda47 (55879) (todos los fragmentos del mismo paquete tienen este mismo ID)

Flags: 0x2093, More fragments

0... .... .... .... = Reserved bit: Not set

.0.. .... .... .... = Don't fragment: Not set

..1. .... .... .... = More fragments: Set (este flag indica que hay mas fragmentos)

...0 0000 1001 0011 = Fragment offset: 147 (1001 0011 en decimal es 147 y 147 x 8 es 1176 que es el payload anterior)

Time to live: 126

Protocol: ICMP (1) (nos indica que es el payload es ICMP, pero no cual tipo de mensaje ICMP)

Header checksum: 0xbd41 [validation disabled]

[Header checksum status: Unverified]

Source: 192.168.2.10

Destination: 192.168.1.10

Reassembled IPv4 in frame: 3

Data (104 bytes) (no hay cabecera ICMP)

Frame 3: 162 bytes on wire (1296 bits), 162 bytes captured (1296 bits) on interface 0 (fragmento recibido con cabecera ICMP)

Ethernet II, Src: 00:0c:42:36:17:5f, Dst: 00:1b:38:7e:f1:71

Internet Protocol Version 4, Src: 192.168.2.10, Dst: 192.168.1.10

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 148

Identification: 0xda47 (55879) (todos los fragmentos del mismo paquete tienen este mismo ID)

Flags: 0x00a0

0... .... .... .... = Reserved bit: Not set

.0.. .... .... .... = Don't fragment: Not set

..0. .... .... .... = More fragments: Not set (no hay mas fragmentos)

...0 0000 1010 0000 = Fragment offset: 160 (1010 0000 es 160 y 160 x 8 es 1280 que es 1176 + 104 (los fragmentos anteriores))

Time to live: 126

Protocol: ICMP (1) (nos indica que es el payload es ICMP)

Header checksum: 0xdd1c [validation disabled]

[Header checksum status: Unverified]

Source: 192.168.2.10

Destination: 192.168.1.10

[3 IPv4 Fragments (1408 bytes): #1(1176), #2(104), #3(128)] (aquí esta el detalle del reensamblado)

Internet Control Message Protocol (cabecera ICMP)

Type: 8 (Echo (ping) request) (aqui si se indica cual tipo de mensaje ICMP ya que esta es la cabecera)

Code: 0

Checksum: 0x5332 [correct]

[Checksum Status: Good]

Identifier (BE): 1 (0x0001)

Identifier (LE): 256 (0x0100)

Sequence number (BE): 16478 (0x405e)

Sequence number (LE): 24128 (0x5e40)

[Response frame: 4]

Data (1400 bytes) (estos son los datos totales reensamblados, este paquete tien 120 bytes de payload)

Frame 4: 1442 bytes on wire (11536 bits), 1442 bytes captured (11536 bits) on interface 0 (respuesta de eco a la solicitud anterior)

Ethernet II, Src: 00:1b:38:7e:f1:71, Dst: 00:0c:42:36:17:5f

Internet Protocol Version 4, Src: 192.168.1.10, Dst: 192.168.2.10

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 1428

Identification: 0x016c (364)

Flags: 0x0000

0... .... .... .... = Reserved bit: Not set

.0.. .... .... .... = Don't fragment: Not set

..0. .... .... .... = More fragments: Not set

...0 0000 0000 0000 = Fragment offset: 0

Time to live: 128

Protocol: ICMP (1)

Header checksum: 0xaf98 [validation disabled]

[Header checksum status: Unverified]

Source: 192.168.1.10

Destination: 192.168.2.10

Internet Control Message Protocol (cabecera ICMP)

Type: 0 (Echo (ping) reply)

Code: 0

Checksum: 0x5b32 [correct]

[Checksum Status: Good]

Identifier (BE): 1 (0x0001)

Identifier (LE): 256 (0x0100)

Sequence number (BE): 16478 (0x405e)

Sequence number (LE): 24128 (0x5e40)

[Request frame: 3]

[Response time: 0.420 ms]

Data (1400 bytes) (es el mismo payload de la solicitud de eco)

4.- Detalle dejado para el final:

Para no alargar demasiado el tema central, esto lo dejé para lo último como un extra.

Cuando hice la verificación inicial (siempre pruebo todo antes de comenzar a documentar para no tener que repetir pruebas culpa

de imprevistos o descuidos) ocurrió algo que no esperaba: Router 1 reesambla los fragmentos generados por Router 2 y los reenvia

a la PC con el tamaño original, y por otro lado, la PC 192.168.1.10 respondía fragmentando debido al Path MTU Discovery.

4.1.- Prueba inicial de fragmentación:

C:\>ping 192.168.2.10 -l 1400

Haciendo ping a 192.168.2.10 con 1400 bytes de datos:

Respuesta desde 192.168.2.10: bytes=1400 tiempo=3ms TTL=126

4.2.- Captura de la prueba:

Para el primer detalle tuve que desactivarle el connection tracking a Router 1 para que deje de hacerlo:

[admin@MikroTik] /ip firewall connection tracking> set enabled=no

[admin@MikroTik] /ip firewall connection tracking>

Para el segundo, desactivar Path MTU Discovery y forzar la MTU a 1500:

Ahora si, recibimos tramas fragmentadas en 1300 y las respondemos sin fragmentar, podemos comenzar con las pruebas.

(2020) Assembling the puzzle

Rosario, Argentina