Analizando los timers en una comunicación de red
Fecha: 13 de febrero
del 2023
Escenario
Analizamos todos los posibles timers utilizados para
establecer una comunicación web entre una PC (por simplicidad está cableada y
no por WiFi)
y un web server en internet, previa consulta DNS.
También por motivos de simplicidad, resumimos
internet a un par de routers asumiendo que sólo intercambian información BGP y
con conexiones
ethernet entre sí. Ambos servidores están solitos
como standalone en lugar de clusters (ahi se nos van varios timers más).
Incluimos un segmento OSPF en la red de la PC,
que además de ser mi protocolo favorito, es para agregar un temporizador más.
Se detallan los temporizadores más relevantes a
nivel networking, a nivel web server o el del sistema operativo de la PC los
valores por default
quedan a criterio de cada SO y de las
aplicaciónes utilizadas. Problema de los sysadmins.
1.- Spanning Tree Protocol
Timers
Lo nombramos primero porque sin spanning-tree
prácticamente no hay comunicación posible. Una vez que converge STP empiezan a
funcionar
el resto de los protocolos de conectividad y
tráfico de usuario.
Uno de los timers mas visibles es el de la transición de
un puerto a forwarding (forward delay), pasando por Listening y
Learning, ambos de 15”.
Entre switches tenemos los siguientes mecanismos que involucran tiempo:
hello — The hello time is the time between each bridge protocol data unit (BPDU) that is sent on a port.
This time is equal to 2 seconds (sec) by default, but you can tune the time to be between 1 and 10 seconds.
forward delay — The forward delay is the time spent in the listening and learning state. This time is equal to 15 seconds by default, but you can
tune the time to be between 4 and 30 seconds.
max age — The max age timer controls the maximum length of time that passes before a bridge port saves its configuration BPDU information.
This time is 20 seconds by default, but you can tune the time to be between 6 and 40 seconds.
Fuente: https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/19120-122.html
2.- MAC address timer:
Es el tiempo de permanencia de una dirección MAC de origen en la tabla de
MAC antes de ser purgada.
En caso de recibir tráfico desde eseorigen el temporizador se reinicia y la
dirección permanece asociada al puerto desde donde se aprendió.
En caso de ser purgada y en el switch existe una trama con dicha MAC
destino el switch generará flooding intentando alcanzar dicha dirección.
Aging time for MAC addresses in the MAC address table.
Default 300 seconds
Valid times are 0 or from 10 to 1,000,000 seconds. A setting of 0 (zero) disables the aging time.
Fuente: www.oreilly.com
3.- ARP Timer:
Es el tiempo de permanencia de una dirección MAC asociada a una IP en la
tabla/caché ARP antes de ser purgada.
En caso de recibir tráfico desde ese origen el temporizador se reinicia y
las direcciones permanecen asociadas en la table/caché ARP.
En caso de ser purgadas y en el dispositivo existe un paquete IP con una IP
destino que debe asociarse a una MAC para enviarse en
layer 2, se generará un ARP request y se aprenderá de la respuesta,
quedando esta en la tabla/caché.
The lifetime of an ARP entry will remain in the ARP table
Default is 14400 seconds (4 hours)
Fuente: www.oreilly.com
4.- OSPF Timers:
OSPF utiliza dos temporizadores. El temporizador hello controla la
frecuencia con la que el router envía mensajes de rutina a sus vecinos
simplemente indicando que todavía está activo.
Si los vecinos no escuchan ningún mensaje de hello durante un
período de tiempo definido como dead time, asumen que ya no existe como
vecino y lo quitan de la tabla de vecindad (neighbor table).
The default values are 10 seconds for the hello time, and 40 seconds for the dead time.
The usual rule of thumb with OSPF is to keep the dead time value four times the hello interval. However, this is not a strict rule.
5.- BGP Timers:
Los sistemas de BGP intercambian
mensajes de keepalive para determinar si un vínculo o un host falló o ya
no está disponible.
Junto con el temporizador de espera (holdtime),
el temporizador keepalive indica si un router es accesible para su par
de BGP.
Keepalive: Frequency (in seconds) with which the router sends keepalive messages to its peer.
The default is 60 seconds.The range is from 0 to 65535.
Holdtime: Interval (in seconds) after not receiving a keepalive message that the software declares a peer dead.
The default is 180 seconds. The range is from 0 to 65535.
Min-holdtime: Interval (in seconds) specifying the minimum acceptable holdtime from a BGP neighbor.
The minimum acceptable holdtime must be less than, or equal to, the interval specified in the holdtime argument.
The range is from 0 to 65535.
6.- Firewall Timers:
Los firewalls en su naturaleza de statefull
utilizan varios temporizadores para controlar los estados de las sesiones de
tráfico y tablas varias.
Los temporizadores de sesión se pueden configurar
para las sesiones TCP, UDP e ICMP.
Los temporizadores de sesión definen el tiempo
que se mantendrá una sesión en el firewall estando inactiva.
Cuando se agota el tiempo de espera de sesión del
protocolo, se cierra la sesión.
Los valores de sesión predeterminados se pueden
modificar dependiendo de las necesidades de la red.
Hay que tener en cuenta que de establecer un
valor muy bajo podría dar lugar a que se produzca frecuentemente el agotamiento
de los tiempos
de espera y cierre de sesiones con el reinicio
correspondiente, y del mismo modo, establecer un valor muy alto podría generar
vulnerabilidades.
timeout conn hh:mm:ss —The idle time after which a connection closes, between 0:5:0 and 1193:0:0. The default is 1 hour (1:0:0).
timeout half-closed hh:mm:ss —The idle time until a TCP half-closed connection closes. A connection is considered half-closed if
both the FIN and FIN-ACK have been seen. If only the FIN has been seen, the regular conn timeout applies. The minimum is 30 seconds.
The default is 10 minutes.
timeout udp hh:mm:ss —The idle time until a UDP connection closes. This duration must be at least 1 minute. The default is 2 minutes.
timeout icmp hh:mm:ss —The idle time for ICMP, between 0:0:2 and 1193:0:0. The default is 2 seconds (0:0:2).
timeout xlate hh:mm:ss —The idle time until a translation slot is freed. This duration must be at least 1 minute. The default is 3 hours.
timeout pat-xlate hh:mm:ss —The idle time until a PAT translation slot is freed, between 0:0:30 and 0:5:0. The default is 30 seconds.
You may want to increase the timeout if upstream routers reject new connections using a freed PAT port because the previous connection
might still be open on the upstream device.
timeout tcp-proxy-reassembly hh:mm:ss —The idle timeout after which buffered packets waiting for reassembly are dropped,
between 0:0:10 and 1193:0:0. The default is 1 minute (0:1:0).
timeout floating-conn hh:mm:ss —When multiple routes exist to a network with different metrics, the ASA uses the one with the
best metric at the time of connection creation. If a better route becomes available, then this timeout lets connections be closed so
a connection can be reestablished to use the better route. The default is 0 (the connection never times out). To make it possible
4to use better routes, set the timeout to a value between 0:0:30 and 1193:0:0.
timeout conn-holddown hh:mm:ss —How long the system should maintain a connection when the route used by the connection
no longer exists or is inactive. If the route does not become active within this holddown period, the connection is freed.
The purpose of the connection holddown timer is to reduce the effect of route flapping, where routes might come up and go down quickly.
You can reduce the holddown timer to make route convergence happen more quickly.
The default is 15 seconds, the range is 00:00:00 to 00:00:15.
timeout igp stale-route hh:mm:ss —How long to keep a stale route before removing it from the router information base.
These routes are for interior gateway protocols such as OSPF. The default is 70 seconds (00:01:10), the range is 00:00:10 to 00:01:40.
Fuente: Cisco ASA
handbook
7.- Timers TCP:
TCP utiliza varios temporizadores para garantizar que no se produzcan
retrasos excesivos durante las comunicaciones.
La implementación de TCP utiliza cuatro temporizadores:
Temporizador de retransmisión: para retransmitir segmentos perdidos, TCP utiliza el tiempo de espera de
retransmisión (RTO).
Cuando TCP envía un segmento, el temporizador se inicia y se detiene cuando
se recibe el reconocimiento. Si el temporizador
expira, se produce un tiempo de espera y el segmento se retransmite.
Temporizador persistente: Cuando el TCP recibe un reconocimiento con un tamaño de ventana de cero,
inicia un temporizador de persistencia.
Cuando el temporizador de persistencia se apaga, el TCP emisor envía un
segmento especial llamado sonda. La sonda hace que el TCP receptor
vuelva a enviar la confirmación que se perdió.
Temporizador de mantenimiento de actividad: es un temporizador de mantenimiento de actividad
para evitar una conexión inactiva prolongada.
Si un cliente abre una conexión TCP a un servidor que transfiere algunos
datos y queda en silencio, el cliente se bloqueará en espera.
En este caso, la conexión permanece abierta para siempre. Por lo tanto, se
utiliza un temporizador de actividad. Cada vez que el servidor recibe
noticias de un cliente, restablece este temporizador. El tiempo de espera
suele ser de 2 horas. Si el servidor no recibe noticias del cliente después
de 2 horas, envía un segmento de sondeo. Si no hay respuesta después de 10
sondeos, cada uno de los cuales tiene una diferencia de 75 s,
se supone que el cliente está inactivo y finaliza la conexión.
Temporizador de tiempo de espera: este temporizador se utiliza durante la finalización de la conexión tcp . El temporizador comienza después
de enviar el último Ack para 2nd FIN y cerrar la conexión.
Fuente: https://barcelonageeks.com/temporizadores-tcp-1/
8.- Timers UDP:
El protocol UDP, al no ser orientado a conexión, no puede mantener sesiones
tal como TCP, por lo que debe manejarse con temporizadores
para abrir ventanas de tiempo de retorno que, fuera de estas, el tráfico se
descarta.
9.- Timer DHCP:
El DHCP lease es un temporizador que mantiene asociada una dirección
IP a una dirección MAC del lado del servidor.
Del lado del cliente es el encargado de generar peticiones renew o rebind
a medida que transcurre la cuenta a 0.
Una vez que en el server el tiempo de binding llega a su fin, la IP
se libera y queda como IP disponible en el pool.
Fuente: https://lazyadmin.nl/home-network/dhcp-lease-time/
10.- Timer HTTP:
Aquí ya no estamos hablando directamente de networking, pero existe cierta influencia
en la manera de transmitir datos entre cliente
y servidor, por lo que en el contexto general vamos a incluirlo.
La conexión persistente HTTP, también llamada keep-alive de HTTP o
reutilización de conexión HTTP, es un concepto que permite
que una sola conexión TCP se envíe y reciba múltiples solicitudes
HTTP/respuestas, en lugar de abrir una nueva conexión para cada
par de solicitud/respuesta.
Una conexión permanece activa durante 60 segundos de forma predeterminada.
Es decir, si una conexión está inactiva en el grupo
de conexiones durante más de 60 segundos, la conexión se cierra.
11.- Timer DNS:
Va de la mano con los timers UDP ya que generalmente se utiliza este
protocolo y un firewall inspeccionará y analaizará los tiempos de
solicitud-respuesta, pero también existen otros timers.
Cuando se habla de TTL en el contexto del almacenamiento en caché de DNS,
la idea es que las respuestas en caché aumentan la eficiencia.
La información del registro DNS se puede almacenar en caché localmente
dentro del resolver de un dispositivo o en una base del servidor DNS.
La información almacenada en caché evita más pasos a seguir y brinda
respuestas más rápidamente a las consultas de DNS.
Una vez que caduca el TTL en un registro almacenado en caché, una
resolución de DNS recursiva debe comenzar el proceso de búsqueda
Nuevamente y habrá que resolver una consulta DNS a través de un servidor de
nombres autorizado.
Fuente: https://bluecatnetworks.com/blog/for-dns-server-caching-what-is-the-ideal-ttl/
12.- Timer AAA:
Este timer es un concepto muy amplio que quedará resumido en el tiempo de
espera de seguridad en una aplicación web antes de cerrarse
por inactividad. La nombramos como AAA por
authentication/authorization/accounting, y que si la quisiéramos complicar aún
más deberíamos
nombrar los temporizadores existentes en radius, LDAP o AD, etc…
Dentro del AAA también podemos mencionar el tiempo de bloqueo por intentos
de logins fallidos en una aplicación, y los tiempos de utilización,
Por ejemplo en una conexión hot spot de
duración x.
(2023) The
time is gone, the song is over
Rosario, Argentina