Final de práctica — Computación Centrada en Redes

Temas: todo el curso, con énfasis en las semanas 9 a 15 · Duración: 3 horas

Este es un examen de práctica con el formato del final. Sirve para medir cuánto tiempo les toma cada tipo de pregunta: resuélvanlo de corrido y con el reloj en marcha.

Indicaciones

• Muestren los cálculos, no solo el número. Si un inciso usa el resultado de otro, usen el que obtuvieron, aunque duden de él.
• Libro o kernel. Salvo que la pregunta diga “en el kernel del curso” o muestre una salida de él, se pide el modelo del libro y de los RFC. Las diferencias de Linux se preguntan aparte.
• Unidades. 1 Mbit/s = 10⁶ bit/s, 1 Gbit/s = 10⁹ bit/s, 1 KB = 1000 bytes y 1 MB = 10⁶ bytes.
• Go-Back-N y Selective Repeat. Es el modelo de window_sim.py, con paquetes numerados. “ACK n” confirma el paquete n, y en Go-Back-N, hasta el n inclusive. El emisor de Go-Back-N reacciona solo a su temporizador y lo reinicia cuando la ventana avanza. El receptor de Selective Repeat vuelve a confirmar lo que ya entregó.
• Reno por RTT. Como en reno_trace.py, cwnd se cuenta en MSS, y la ventana inicial es 1 salvo que se diga otra cosa. Mientras cwnd < ssthresh, cwnd = min(2 × cwnd, ssthresh); si no, cwnd suma 1. Con cwnd = ssthresh ya se está en congestion avoidance. Si el evento ocurre en un RTT, la fila de ese RTT conserva su cwnd, y el cambio se ve en la fila siguiente. Tres ACK duplicados: ssthresh = max(cwnd // 2, 2) y cwnd = ssthresh. Timeout: ssthresh = max(cwnd // 2, 2) y cwnd = 1. // es la división entera.
• RTO. RFC 6298, en el orden del curso: primero DevRTT, con el EstimatedRTT anterior; después EstimatedRTT; después el RTO. α = 1/8 y β = 1/4. La primera muestra R da EstimatedRTT = R y DevRTT = R / 2. No apliquen el mínimo de 1 s salvo que la pregunta lo pida.
• Mathis. Usen throughput ≈ 1,22 × MSS / (RTT × √p).
• Salidas. Toda salida de comandos de este examen es de una ejecución real en el entorno del curso. Los recortes por la derecha y las filas omitidas se avisan, y las cifras cambian de una corrida a otra.

Parte A — Repaso de las semanas 1 a 7

Pregunta 1 — Longest prefix match y retardo

a) Un router tiene esta forwarding table:

¿Por dónde sale un datagrama dirigido a cada una de estas direcciones: 10.216.45.7, 10.216.41.9, 10.216.39.200, 10.216.48.1, 10.216.200.1 y 10.217.0.1? ¿Cuántas direcciones de host utilizables tiene una subred /22?

b) Un host le envía un paquete de 1500 bytes a un servidor, a través de un router que hace store-and-forward. El primer enlace es de 100 Mbit/s y 200 km, y el segundo, de 1 Gbit/s y 2000 km. La velocidad de propagación es 2×10⁸ m/s, y no hay colas. Calculen el retardo de extremo a extremo, en microsegundos, y digan qué componente pesa más. Para un archivo grande, ¿qué enlace limita el throughput?

Pregunta 2 — Políticas de BGP

Siete sistemas autónomos tienen estas relaciones:

El AS 64705 origina P = 100.64.17.0/24. Todos aplican las reglas de exportación e importación de la semana 6: prefieren una ruta de cliente, luego de peer y luego de proveedor, sin mirar el largo. A igual tipo, gana el AS_PATH más corto.

a) Para cada uno de los otros seis AS, escriban el AS_PATH de la ruta que elige hacia P, y si la aprendió de un cliente, de un peer o de un proveedor.

b) ¿Qué AS eligen un AS_PATH más largo que otro que también recibieron, y cuál es el motivo económico? 64707 conoce rutas por 64702 y por 64703: ¿puede el tráfico de 64702 hacia un cliente de 64703 cruzar 64707? ¿Por qué, si físicamente hay enlaces?

c) Se cae el enlace entre 64702 y 64705. ¿Qué rutas eligen ahora 64702 y 64704? ¿Quién le paga a quién en el camino de 64702?

Parte B — Cálculos

Pregunta 3 — Utilización de una ventana

Un enlace de 200 Mbit/s con 30 ms de RTT lleva paquetes de 1250 bytes. Los ACK no ocupan tiempo de transmisión.

a) Para stop-and-wait, calculen d, la utilización y el throughput.

b) Para una ventana de 100 paquetes, calculen la utilización y el throughput. ¿Cuántos paquetes de ventana hacen falta para que el emisor no se detenga nunca? ¿Cuánto vale el BDP, en bytes?

c) Con la ventana del inciso anterior que llena el enlace, ¿cuántos bits de número de secuencia hacen falta como mínimo en Go-Back-N? ¿Y en Selective Repeat?

d) Ahora es TCP, y el receptor anuncia 65 535 bytes sin escala. ¿Cuál es el techo de throughput? ¿Cuál es la menor escala de ventana con la que se puede anunciar el BDP? Si en una captura ven esa lentitud, sin retransmisiones, ¿de qué sospechan?

Pregunta 4 — RTO

a) Una conexión mide estas muestras seguidas de SampleRTT, en milisegundos: 80, 100, 60 y 200. Hagan una tabla con EstimatedRTT, DevRTT y RTO después de cada una.

b) Justo después de la última fila, el segmento más antiguo se retransmite por timeout, vence otra vez y se retransmite de nuevo. ¿Cuánto vale el RTO después de cada vencimiento? Luego llega un ACK que cubre ese segmento. Sin timestamps, ¿se usa como SampleRTT? ¿Por qué? ¿Y con timestamps?

c) Estas dos líneas de ss -tin, recortadas, son reales y salen de los apuntes. Son del kernel del curso, en una ruta sin ajustes y en otra con rto_min 500ms:

    default: rto:244 rtt:43.462/3.019
    500ms: rto:542 rtt:41.792/0.805

Para la primera línea, ¿cuánto daría el RTO según la fórmula, sin piso? ¿Y según el RFC 6298, con el mínimo de 1 s? Expliquen cómo sale el rto que muestra cada línea. ¿Cuál de los valores usarían en un examen, y cuál esperarían ver en ss?

Pregunta 5 — Leaf-spine, ECMP y VXLAN

a) Un leaf tiene 40 puertos de 25 Gbps hacia servidores y 6 uplinks de 100 Gbps, uno a cada spine. Los spines tienen 64 puertos de 100 Gbps. Calculen la sobresuscripción, cuántos uplinks harían falta para 1:1, cuántos servidores soporta la red como máximo y cuánto le toca a cada servidor en el peor caso. ¿Cuánto queda la sobresuscripción si se cae un spine?

b) Tres flujos elefante cruzan esos 6 caminos, y el hash de cada uno cae al azar. Calculen la probabilidad de que no choquen y el promedio de caminos ocupados. ¿Qué fracción del ideal es, si cada elefante llenaría un camino por su cuenta? Después, un spine falla en silencio: ¿qué fracción de las conexiones TCP se ve afectada, si los dos sentidos se reparten de forma independiente?

c) Un cliente de un overlay manda un datagrama IP de 1400 bytes. Calculen el frame interno, el largo UDP, el IP externo y el frame externo con VXLAN. ¿Cuál es el mayor datagrama interno que cabe si el underlay tiene MTU 1500?

Pregunta 6 — BDP, buffer, Mathis, CUBIC y AIMD

Un cuello de botella de 100 Mbit/s, con 50 ms de RTT base y un buffer de 1,25 MB, lleva paquetes de 1250 bytes.

a) Calculen el BDP en bytes y en paquetes, el retardo de cola con el buffer lleno y el RTT que vería cualquier flujo que comparta ese enlace.

b) Un flujo Reno solo, en régimen, ¿con qué ventana pierde y a cuánto baja? ¿Se vacía el enlace en algún momento del ciclo? ¿Qué nombre tiene el problema de este buffer, y cuánto throughput se perdería con un buffer de la mitad?

c) Con MSS de 1448 bytes, si el camino tiene 50 ms de RTT y pierde al azar el 0,04 % de los paquetes, ¿cuánto da la fórmula de Mathis? ¿Qué p haría falta para sostener 100 Mbit/s, y a cuántos paquetes corresponde una pérdida?

d) Tras una pérdida con Wmax = 1500, calculen K de CUBIC, sin convergencia rápida, y lo que tardaría Reno en recuperar Wmax, con RTT fijo de 50 ms. ¿Por qué el RTT no aparece en K?

e) Dos flujos parten de x1 = 20 y x2 = 60 en un enlace de capacidad 100. Si la suma pasa de 100 los dos multiplican por 0,5; si no, los dos suman 10. Escriban los siete pasos siguientes y el índice de Jain al inicio y al final. ¿Qué le pasa a |x1 − x2| en cada tipo de paso?

Parte C — Algoritmos a mano

Pregunta 7 — Go-Back-N y Selective Repeat

Un emisor manda los paquetes 0 a 6, con ventana 3. Cada paquete tarda 1 ms en transmitirse, cada sentido demora 5 ms y el temporizador es de 25 ms. Los números de secuencia no se acaban. Se pierden la primera copia del paquete 2 y el primer ACK 5 que envíe el receptor.

a) Dibujen el diagrama de tiempo de Go-Back-N. Marquen cada envío, cada ACK y lo que hace el receptor con cada paquete. Digan cuántas transmisiones hay, cuántas son repeticiones y qué pasa con el ACK 5 perdido. Los instantes de los temporizadores pueden variar en 1 ms.

b) Hagan lo mismo con Selective Repeat. ¿En qué instante recibe la aplicación los paquetes 3 y 4? ¿Qué hace el receptor cuando le llega de nuevo un paquete que ya entregó, y qué pasaría si no lo hiciera? Comparen con (a) las transmisiones y el tiempo total, y expliquen por qué cada protocolo gana en una cosa.

c) Ahora hay solo 6 números de secuencia (0 a 5). ¿Cuál es la ventana máxima de cada protocolo? Para Selective Repeat con ventana 4, supongan que el receptor ya entregó los paquetes 0 a 3 y que se perdieron sus ACK. Escriban qué copias viejas pueden llegar, qué números aceptaría como nuevos y cuáles se confunden. ¿Hay algún error visible para la aplicación?

Pregunta 8 — Reno

a) Con ventana inicial 1 y ssthresh = 12, hagan la tabla de cwnd y ssthresh de los RTT 1 a 21, con tres ACK duplicados en el RTT 9 y un timeout en el RTT 15, y dibujen la curva. Marquen qué fase corre en cada tramo.

b) Miren el evento del RTT 9 con el detalle del RFC 5681. ¿Cuánto vale cwnd al recibir el tercer ACK duplicado? ¿Y después de cuatro duplicados más? ¿Y al llegar el ACK que confirma datos nuevos? ¿Por qué esos valores no aparecen en su tabla?

c) Con MSS de 1460 bytes y RTT de 100 ms, ¿qué throughput da cwnd / RTT en el RTT 9? Si rwnd fuera de 10 MSS, ¿cambiaría? ¿Qué protege cada ventana?

d) Esta salida es del kernel del curso: el programa tcp_info de la semana 11, con Reno, sobre un cuello de botella de 20 Mbit/s con cola y un RTT base de unos 50 ms. Dejamos solo algunas filas.

# algoritmo: reno
#   t_ms   cwnd ssthresh   rtt_ms retrans estado
     0.0     10        -     52.2       0 open
    76.0     20        -     54.3       0 open
   127.0     40        -     55.5       0 open
   201.0     80        -     60.9       0 open
   252.0    154        -     72.5       0 open
   352.0    314        -     94.9       0 open
   377.0    266      158     97.8      16 recovery
   401.9    209      158     97.3      36 recovery
   426.9    158      158     98.7      67 recovery
   551.9    158      158     93.8     153 open
   651.9    159      158     95.3     153 open
   750.9    160      158     96.3     153 open
   851.8    161      158     96.9     153 open
   951.0    162      158     97.2     153 open
  1025.8    162      158     97.6     153 open
  1051.8    155       81     98.4     154 recovery
  1127.0     91       81     99.2     154 recovery
  1150.9     81       81     91.8     154 open
  1201.8     82       81     54.8     154 open
  1251.9     83       81     53.1     154 open
  1300.9     84       81     53.3     154 open
  1350.9     85       81     53.3     154 open
  1800.9     93       81     55.9     154 open

• Señalen tres diferencias entre esta salida y el modelo del inciso (a).
• ¿Cada cuánto suma 1 la ventana entre 551,9 y 1025,8 ms, y cada cuánto desde 1201,8 ms? ¿Por qué no es igual, si en los dos tramos es “uno por RTT”?
• Calculen cwnd / RTT en las filas de 1025,8 y de 1251,9 ms, y compárenlo con el goodput máximo del enlace, con frames de 1514 bytes que llevan 1448 de datos. ¿Cuánta cola hay en cada fila? ¿Por qué el RTT empieza a subir otra vez hacia el final?

Parte D — Seguir un paquete

Pregunta 9 — VLAN, túnel y NAT

Esta red corrió de verdad en el entorno del curso:

ofi --- sw ==trunk== gw1 ---------- wan ---------- gw2 --- b
                                     |
                                    srv

ofi  10.216.20.10/24, puerto de acceso de la VLAN 20 en sw, gateway 10.216.20.1
gw1  eth1.20 10.216.20.1/24, eth2 100.64.16.2/30, wg0 10.216.9.1/30
wan  eth1 100.64.16.1/30, eth2 100.64.16.5/30, eth3 100.64.16.9/30
gw2  eth1 100.64.16.6/30, eth2 10.216.30.1/24, wg0 10.216.9.2/30
b    10.216.30.10/24, gateway 10.216.30.1
srv  100.64.16.10/30, gateway 100.64.16.9

sw es un bridge de Linux con VLANs: su puerto hacia ofi es de acceso, y el que va a gw1 es un trunk con la VLAN 20. Todos los enlaces tienen MTU 1500. Entre gw1 y gw2 hay un túnel WireGuard en el puerto UDP 51820, con MTU 1420 en wg0 y una ruta a la red remota por wg0 en cada lado. gw1 tiene una regla de NAT:

ip saddr 10.216.20.0/24 oifname "eth2" masquerade

a) ofi hace ping -s 200 10.216.30.10. Sigan el pedido hasta b. Copien esta tabla y complétenla para los cinco tramos: qué encabezados tiene el frame, de afuera hacia adentro; qué direcciones IP puede leer alguien que captura ahí; el TTL que puede leer; y si cambian las MAC respecto del tramo anterior.

¿Cuánto vale el TTL del datagrama interno mientras cruza wan? ¿Puede wan saberlo?

b) Calculen el tamaño del datagrama interno, la carga UDP del paquete de WireGuard, el IP externo y el frame externo, y los frames de los tramos ofi–sw y sw–gw1. Si cambiaran a -s 212 y a -s 213, ¿cuánto mediría en cada caso la carga UDP? ¿Por qué un byte de más puede sumar 16?

c) Ahora ofi abre una conexión TCP a 100.64.16.10:8080, desde su puerto 40100. Esta es la fila de conntrack -L en gw1, un momento después:

tcp      6 119 TIME_WAIT src=10.216.20.10 dst=100.64.16.10 sport=40100 dport=8080 src=100.64.16.10 dst=100.64.16.2 sport=8080 dport=40100 [ASSURED] mark=0 use=1

¿Qué direcciones y puertos tiene el SYN en sw–gw1 y en gw1–wan? ¿Qué campos cambia gw1, además de la dirección? ¿Por qué el puerto sigue en 40100, y cuándo no seguiría igual? ¿Por qué el ping del inciso (a) no pasa por esta traducción?

d) En gw2, la lista de direcciones del peer gw1 es la de abajo. Desde gw1 se prueban dos pings hacia b, con dos orígenes distintos, y una captura en wan muestra UDP del túnel en los dos casos:

$ wg show wg0 allowed-ips        (en gw2; recortamos la clave)
10.216.20.0/24 10.216.9.1/32
$ ping -c 2 -W 1 -I 100.64.16.2 10.216.30.10
2 packets transmitted, 0 packets received, 100% packet loss
$ ping -c 2 -W 1 -I 10.216.9.1 10.216.30.10
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.311/0.321/0.332 ms

¿Quién descartó los pedidos del primer ping, y después de hacer qué? ¿Qué le garantiza eso al firewall de la red de b?

e) Durante una transferencia de ofi a b, ofi recibe esto. Omitimos la última línea del tcpdump, con el resto del segmento:

20:20:32.159109 IP (tos 0xc0, ttl 64, id 17130, offset 0, flags [none], proto ICMP (1), length 576)
    10.216.20.1 > 10.216.20.10: ICMP 10.216.30.10 unreachable - need to frag (mtu 1420), length 556
	IP (tos 0x0, ttl 64, id 62230, offset 0, flags [DF], proto TCP (6), length 1500)
$ ip route get 10.216.30.10
10.216.30.10 via 10.216.20.1 dev eth1 src 10.216.20.10 uid 0 
    cache expires 596sec mtu 1420 

¿Qué mecanismo es este? ¿Quién mandó el ICMP y por qué? ¿Cuántos bytes de datos llevará ahora un segmento lleno, con timestamps? ¿Qué pasaría con la conexión si un firewall descartara estos ICMP?

Parte E — Leer salidas reales

Pregunta 10 — Una captura de TCP

En una red a (10.216.1.10) — m — s (10.216.2.10), con 25 ms de retardo en cada sentido y 20 Mbit/s hacia s, a envía 300 000 bytes. m descartó un solo segmento. Son capturas de tshark en a y en s, con números relativos, y cada una tiene su propio cero de tiempo. Recortamos por la derecha.

$ tshark -r tcp-a.pcap          (solo algunas filas)
    1   0.000000  10.216.1.10 → 10.216.2.10  TCP 74 40572 → 5001 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=3655678576 TSecr=0 WS=128
    2   0.051844  10.216.2.10 → 10.216.1.10  TCP 74 5001 → 40572 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2435210489 TSecr=3655678576 WS=128
    3   0.051864  10.216.1.10 → 10.216.2.10  TCP 66 40572 → 5001 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3655678628 TSecr=2435210489
    4   0.051900  10.216.1.10 → 10.216.2.10  TCP 1514 40572 → 5001 [ACK] Seq=1 Ack=1 Win=64256 Len=1448 TSval=3655678628 TSecr=2435210489
    5   0.051904  10.216.1.10 → 10.216.2.10  TCP 1514 40572 → 5001 [PSH, ACK] Seq=1449 Ack=1 Win=64256 Len=1448 TSval=3655678628 TSecr=2435210489
   38   0.113753  10.216.1.10 → 10.216.2.10  TCP 1514 40572 → 5001 [ACK] Seq=40545 Ack=1 Win=64256
   91   0.175716  10.216.2.10 → 10.216.1.10  TCP 66 5001 → 40572 [ACK] Seq=1 Ack=40545 Win=105600 Len=0
   94   0.176861  10.216.2.10 → 10.216.1.10  TCP 78 [TCP Dup ACK 91#1] 5001 → 40572 [ACK] Seq=1 Ack=40545 Win=108416 Len=0 TSval=2435210614 TSecr=3655678690 SLE=41993 SRE=43441
   96   0.192646  10.216.1.10 → 10.216.2.10  TCP 1514 [TCP Retransmission] 40572 → 5001 [ACK] Seq=40545 Ack=1 Win=64256
   97   0.222875  10.216.2.10 → 10.216.1.10  TCP 78 [TCP Dup ACK 91#2] 5001 → 40572 [ACK] Seq=1 Ack=40545 Win=111360 Len=0 TSval=2435210660 TSecr=3655678690 SLE=41993 SRE=44889
   99   0.222893  10.216.2.10 → 10.216.1.10  TCP 78 [TCP Dup ACK 91#3] 5001 → 40572 [ACK] Seq=1 Ack=40545 Win=114304 Len=0 TSval=2435210661 TSecr=3655678690 SLE=41993 SRE=46337
  150   0.244665  10.216.2.10 → 10.216.1.10  TCP 66 5001 → 40572 [ACK] Seq=1 Ack=97017 Win=182528 Len=0
  398   0.535874  10.216.2.10 → 10.216.1.10  TCP 66 5001 → 40572 [ACK] Seq=1 Ack=300002 Win=494336 Len=0

$ tshark -r tcp-a.pcap -c 6 -o tcp.relative_sequence_numbers:FALSE          (las dos primeras filas)
    1   0.000000  10.216.1.10 → 10.216.2.10  TCP 74 40572 → 5001 [SYN] Seq=2517474555 Win=64240
    2   0.051844  10.216.2.10 → 10.216.1.10  TCP 74 5001 → 40572 [SYN, ACK] Seq=1822047033

$ tshark -r tcp-s.pcap          (solo algunas filas)
   54   0.123481  10.216.1.10 → 10.216.2.10  TCP 1514 40572 → 5001 [PSH, ACK] Seq=39097 Ack=1 Win=64256 Len=1448
   56   0.124470  10.216.1.10 → 10.216.2.10  TCP 1514 [TCP Previous segment not captured] 40572 → 5001 [PSH, ACK]
  131   0.192479  10.216.1.10 → 10.216.2.10  TCP 1514 [TCP Fast Retransmission] 40572 → 5001 [ACK] Seq=40545 Ack=1
  132   0.192485  10.216.2.10 → 10.216.1.10  TCP 66 5001 → 40572 [ACK] Seq=1 Ack=97017 Win=182528 Len=0

$ nstat -az TcpRetransSegs TcpExtTCPTimeouts TcpExtTCPLossProbes TcpExtTCPSackRecovery TcpExtTCPRenoRecovery        (en a)
TcpRetransSegs                  1                  0.0
TcpExtTCPRenoRecovery           0                  0.0
TcpExtTCPSackRecovery           1                  0.0
TcpExtTCPTimeouts               0                  0.0
TcpExtTCPLossProbes             0                  0.0

En a, los segmentos con datos son 209, y suman 301 448 bytes. El receptor dice recibidos 300000 bytes en 0.43 s (5.6 Mbit/s).

a) ¿Qué MSS anuncia cada lado, y por qué los datos van de 1448 bytes? Desglosen los 1514 bytes del frame. La opción WS=128 del SYN, ¿qué dice sobre el Win=64256 del paquete 3, y qué valor lleva ese campo en el encabezado?

b) ¿Cuál es el número de secuencia real del primer byte de datos? ¿Y el del segmento del paquete 38? ¿Por qué Ack=300002 al final, si se enviaron 300 000 bytes?

c) ¿Qué segmento descartó m? Indiquen su Seq y sus bytes, y digan cómo se confirma con las capturas de los dos lados. Lean el paquete 94: ¿qué dice su bloque SACK? ¿Qué agrega cada duplicado siguiente? ¿Cuánto confirma de golpe el ACK de los paquetes 132 y 150, y qué estaba haciendo s con esos bytes?

d) ¿Cuánto pasó entre el envío original y la retransmisión, y entre el primer ACK duplicado y la retransmisión? ¿Cuál es el RTT? Según la regla de los libros, ¿qué esperaba el emisor para hacer fast retransmit, y en qué paquete se habría cumplido? ¿Qué mecanismo del kernel del curso explica lo que se ve?

e) a y s etiquetan distinto la misma retransmisión. ¿Qué significa eso? ¿Fue un timeout? ¿Qué fuente lo dice con seguridad? La pérdida fue de 1 en 209 segmentos, y aun así la velocidad quedó en 5,6 Mbit/s en un enlace de 20: ¿qué parte de eso se debe a la pérdida, y qué más hay en una transferencia tan corta?

Pregunta 11 — Una captura de TLS

Con la misma topología, sin el límite de velocidad, a pide https://pagos.illapa.test/saldo?cuenta=7 a openssl s_server en s. Se captura en m, sin ninguna clave. Las columnas son paquete, tiempo, origen, largo del frame e interpretación de tshark. Recortamos por la derecha y omitimos desde el paquete 16.

1	0.000000000	10.216.1.10	74	56542 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM
2	0.051517000	10.216.2.10	74	443 → 56542 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM
3	0.051545000	10.216.1.10	66	56542 → 443 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4	0.053107000	10.216.1.10	1514	
5	0.053114000	10.216.1.10	122	Client Hello (SNI=pagos.illapa.test)
6	0.104060000	10.216.2.10	66	443 → 56542 [ACK] Seq=1 Ack=1449 Win=68096 Len=0
7	0.104067000	10.216.2.10	66	443 → 56542 [ACK] Seq=1 Ack=1505 Win=68096 Len=0
8	0.105074000	10.216.2.10	1514	Server Hello, Change Cipher Spec, Application Data
9	0.105079000	10.216.2.10	970	Application Data, Application Data, Application Data
10	0.105098000	10.216.1.10	66	56542 → 443 [ACK] Seq=1505 Ack=1449 Win=67200 Len=0
11	0.105104000	10.216.1.10	66	56542 → 443 [ACK] Seq=1505 Ack=2353 Win=70144 Len=0
12	0.105776000	10.216.1.10	146	Change Cipher Spec, Application Data
13	0.105882000	10.216.1.10	183	Application Data
14	0.158282000	10.216.2.10	321	Application Data
15	0.158288000	10.216.2.10	321	Application Data

La misma captura, abierta con el archivo SSLKEYLOGFILE de curl, solo en las filas que cambian:

8	0.105074000	10.216.2.10	1514	Server Hello, Change Cipher Spec, Encrypted Extensions
9	0.105079000	10.216.2.10	970	Certificate, Certificate Verify, Finished
12	0.105776000	10.216.1.10	146	Change Cipher Spec, Finished
13	0.105882000	10.216.1.10	183	GET /saldo?cuenta=7 HTTP/1.1 
14	0.158282000	10.216.2.10	321	New Session Ticket
15	0.158288000	10.216.2.10	321	New Session Ticket

Y estos son los tiempos acumulados de curl -w, en segundos, en dos conexiones más:

TLS 1.3: tcp=0.052284 tls=0.105725 primer_byte=0.157319
TLS 1.2: tcp=0.052292 tls=0.158290 primer_byte=0.213062

a) Sin claves, ¿qué aprende quien está en m sobre esta conexión? ¿Qué no puede saber? Respondan con el nombre del servidor, /saldo?cuenta=7, el certificado, las direcciones y los tamaños. ¿Cuántos bytes mide el ClientHello en TCP, y cómo lo confirma el paquete 7?

b) ¿Por qué el ServerHello va legible y lo demás no? ¿Por qué lo que sigue se declara Application Data, si es parte del handshake? ¿Qué mensaje prueba que el servidor tiene la clave privada del certificado, y qué firma exactamente? ¿Para qué sirve el Change Cipher Spec, en TLS 1.3?

c) Con los tiempos de curl, ¿cuántos RTT cuesta cada versión hasta tener TLS listo, sin contar TCP? ¿Y hasta el primer byte, contando todo? ¿Cuál sería la cuenta con QUIC en una conexión nueva, y por qué? ¿Qué cambió entre TLS 1.2 y TLS 1.3 para ahorrar ese RTT?

d) Alguien guardó esta captura sin claves, y un año después roba la clave privada del certificado del servidor. ¿Puede leer /saldo?cuenta=7? ¿Qué propiedad lo impide y qué mecanismo la da? ¿Qué sí puede hacer con esa clave, desde ese día? Si el cliente hubiera mandado un POST como early data en una conexión reanudada, ¿qué riesgo distinto habría?

Pregunta 12 — Una salida de dig

En un Internet de laboratorio con su propia raíz y el TLD .test, se corre todo esto desde un cliente cuyo resolver es 10.216.3.53. Se omiten líneas que no hacen falta.

$ dig +trace pagos.illapa.test
.			86400	IN	NS	a.raiz.test.
;; Received 41 bytes from 10.216.3.53#53(10.216.3.53) in 50 ms

test.			86400	IN	NS	ns1.nic.test.
;; Received 73 bytes from 10.216.3.10#53(a.raiz.test) in 51 ms

illapa.test.		7200	IN	NS	ns1.illapa.test.
;; Received 69 bytes from 10.216.3.20#53(ns1.nic.test) in 49 ms

pagos.illapa.test.	600	IN	A	10.216.2.10
;; Received 51 bytes from 10.216.3.30#53(ns1.illapa.test) in 49 ms

$ dig @10.216.3.20 +norecurse pagos.illapa.test
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41081
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
illapa.test.		7200	IN	NS	ns1.illapa.test.

;; ADDITIONAL SECTION:
ns1.illapa.test.	7200	IN	A	10.216.3.30

$ dig @10.216.3.30 +norecurse pagos.illapa.test
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27297
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

$ dig tienda.illapa.test +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21412
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:
tienda.illapa.test.	300	IN	CNAME	pagos.illapa.test.
pagos.illapa.test.	600	IN	A	10.216.2.10

$ sleep 7; dig tienda.illapa.test +noall +answer
tienda.illapa.test.	293	IN	CNAME	pagos.illapa.test.
pagos.illapa.test.	593	IN	A	10.216.2.10

$ dig cobros.illapa.test
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19868
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; AUTHORITY SECTION:
illapa.test.		120	IN	SOA	ns1.illapa.test. admin.illapa.test. 2026110201 3600 600 86400 120

$ dig pagos.illapa.test MX +noall +comments +authority
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39640
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

$ dig @10.216.3.30 informe.illapa.test TXT +ignore +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15024
;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

$ dig informe.illapa.test TXT
;; Truncated, retrying in TCP mode.
;; SERVER: 10.216.3.53#53(10.216.3.53) (TCP)
;; MSG SIZE  rcvd: 1776

a) Sigan el +trace: ¿quién responde cada bloque y qué tipo de servidor es? ¿Qué tipo de consulta le hace un cliente común a su resolver, y qué tipo le hace el resolver a esos servidores? ¿Qué significan ANSWER: 0 con NOERROR en la segunda consulta, y aa en la tercera? ¿Por qué las respuestas del resolver no llevan aa?

b) ¿Qué es el registro de la sección ADDITIONAL, y por qué es indispensable aquí? ¿Qué vería el cliente, y con qué status, si faltara? ¿Haría falta si el servidor se llamara ns1.otra.test?

c) ¿Por qué tienda da dos registros? ¿Quién restó los 7 segundos? ¿Cuánto tiempo más puede seguir un resolver entregando esa dirección si el owner la cambia justo después de esta consulta, y por qué no hay que hablar de “propagación”?

d) ¿Qué dicen NXDOMAIN y el NOERROR con ANSWER: 0 de la consulta MX? ¿En qué se diferencian? ¿Cuánto dura en cache la negativa? ¿Por qué la consulta por informe termina en TCP, y cuál de los flags lo provoca? Si quisieran que nadie en la red local leyera estas consultas, ¿les sirve DNSSEC? ¿Qué usarían?

Parte F — Preguntas cortas

Respondan cada una en tres o cuatro líneas.

Pregunta 13

¿Por qué QUIC usa UDP, si no aprovecha casi nada de UDP y tiene que construir confiabilidad, streams y control de congestión por su cuenta? Den dos razones. ¿Por qué no se mejoró TCP?

Pregunta 14

Una ruta llega con AS_PATH 64666 64603 y rpki validation-state: valid, y el ROA autoriza a 64603 a originar ese prefijo. ¿Eso prueba que el camino es legítimo? Digan dos cosas que RPKI no protege.

Pregunta 15

¿Por qué ECMP reparte por flujo y no por paquete, si por paquete se aprovecharían mejor los enlaces? Usen esta medición de los apuntes, la primera de tres corridas, hecha con dos uplinks de 100 Mbit/s y 2 ms de diferencia entre los caminos, sin pérdidas programadas. ¿Qué costo tiene repartir por flujo?

  por flujo:
        92 Mbit/s       0 retransmisiones      1513 fuera de orden en h3
  por paquete:
        22 Mbit/s    1393 retransmisiones      4600 fuera de orden en h3

Pregunta 16

El kernel del curso no trae BBR, así que esta pregunta es solo conceptual. ¿Qué dos cantidades estima BBR, y por qué no puede medirlas a la vez? ¿Por qué una pérdida aleatoria del 1 % le afecta menos que a Reno? ¿Qué riesgo tiene al convivir con CUBIC?

Pregunta 17

Un firewall con estado protege una DMZ y una red interna. Estos tres intentos de conexión vienen de los apuntes, y nc espera hasta tres segundos:

    ext -> web:443 (aceptado por fw, sin servidor): no conecta, 0.04 s
    ext -> web:22  (sin regla, drop en forward) : no conecta, 3.04 s
    ext -> ofi:8080 (red interna, reject)       : no conecta, 1.06 s

¿Qué le llega al cliente en cada caso, y quién lo envía? ¿Por qué es una decisión de diseño elegir entre drop y reject? Si el enlace de entrada a este sitio está saturado por un DoS de volumen, ¿ayudan el firewall o las SYN cookies del servidor? ¿Dónde hay que filtrar?

Después del examen: lo que ya pueden hacer

Al corregir su intento, marquen cada resultado de aprendizaje del programa que ya dominan. Si una pregunta les costó, vuelvan a las semanas indicadas antes del final.

• Puedo explicar la arquitectura de Internet, sus capas y sus principios de diseño, y estimar retardo, pérdida y throughput de un camino. Semanas 1 y 2 · preguntas 1 b, 3 y 6.
• Puedo escribir programas cliente-servidor en C con sockets y analizar su tráfico con Wireshark y tcpdump. Semanas 2, 10 y 13 · preguntas 10 y 11. Este final no pide escribir código de sockets: eso se practica en P0 y en la pregunta 12 del parcial de práctica.
• Puedo diseñar el direccionamiento de una red, configurar switching, VLANs, forwarding y NAT, y explicar el recorrido de un paquete salto por salto. Semanas 3 y 4 · preguntas 1 a y 9.
• Puedo explicar los algoritmos de routing y configurar OSPF y BGP con políticas entre sistemas autónomos. Semanas 5 a 7 · preguntas 2 y 14. Dijkstra y el vector de distancias están en las preguntas 5 y 6 del parcial de práctica.
• Puedo implementar un protocolo de transporte confiable con ventana deslizante y control de congestión, y evaluar su desempeño con mediciones. Semanas 9 a 11 · preguntas 3, 4, 6, 7, 8, 10 y 16.
• Puedo explicar cómo funcionan DNS, HTTP, TLS 1.3 y QUIC, y diagnosticar fallas de aplicaciones con capturas de tráfico. Semanas 12 y 13 · preguntas 11, 12 y 13.
• Puedo describir las redes de data center y SDN, identificar ataques comunes y aplicar defensas como firewalls, VPNs y RPKI. Semanas 7, 14 y 15 · preguntas 5, 9, 14, 15 y 17. Wi-Fi y 5G no tienen pregunta en este final: repasen la Sesión B de la semana 14 y sus ejercicios.