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.
Es necesario fragmentar el paquete pero se especificó DF.
Es necesario fragmentar el paquete pero se especificó DF.
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.
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=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.
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
Respuesta desde 192.168.2.10: bytes=1400 tiempo=3ms TTL=126
Respuesta desde 192.168.2.10: bytes=1400 tiempo=3ms TTL=126
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