Resumen

  • tcpConnState era de lectura y escritura en RFC 2012. La única escritura permitida desde una estación de gestión, deleteTCB(12), borraba el bloque de control correspondiente y terminaba de inmediato la conexión en el nodo administrado.
  • La fila y los contadores observaban estados, aperturas, fallos, reinicios y segmentos, pero no formaban un recibo causal que uniera persona, permiso, motivo, ejecución, aplicación, par remoto y duración del impacto.
  • RFC 4022 conservó la acción, añadió tipos de dirección, separó listeners y conexiones, informó procesos, hizo opcional la escritura para conformidad y advirtió del riesgo de denegación de servicio.

Lo que confirmó el agente era sólo el principio

RFC 2012 convirtió en objetos SMIv2 una superficie TCP que ya venía de MIB-II. Había parámetros del motor, un indicador de conexiones actuales y contadores de aperturas activas y pasivas, intentos fallidos, cierres desde estados establecidos, segmentos, retransmisiones, errores y RST emitidos. La tabla de conexiones identificaba cada fila con dirección y puerto locales más dirección y puerto remotos.

En esa misma fila, tcpConnState cruzaba de la observación al control. Su acceso era read-write. Un gestor no podía escribir cualquiera de los estados ordinarios; sólo deleteTCB(12). La consecuencia normativa era borrar el TCB de la conexión correspondiente y terminarla de inmediato en el host. Enviar un RST al par era opcional y el propio texto recordaba que esos segmentos no se entregan de forma fiable.

Así, el éxito del SET demuestra como máximo que la solicitud llegó a una etapa concreta y fue aceptada. No demuestra que el par recibió aviso, que una aplicación pudo terminar limpiamente, que un reintento prosperó ni cuánto duró una interrupción.

El bloque borrado contenía la continuidad

RFC 793 concebía el TCB como la memoria de la conexión: sockets de ambos extremos, seguridad y precedencia, punteros a buffers, cola de retransmisión, segmento actual y variables de secuencia. CLOSED era ficticio porque, sin TCB, ya no había conexión.

Por eso deleteTCB no era un cambio de etiqueta. Eliminaba el estado operativo local. La MIB sabía qué cuádrupla se seleccionaba, pero no almacenaba un ID de acción, un ticket, un motivo, un operador, el dueño de la aplicación o un recibo duradero. La fila, además, era transitoria.

La decisión de hacerla escribible aparece ya en RFC 1213, de 1991, cuyo registro de cambios explica que servía para borrar el TCB. RFC 2012, publicado en 1996, trasladó esos objetos a SNMPv2. Aunque su introducción situaba autenticación, autorización, control de acceso y privacidad en el marco administrativo, su sección de seguridad no analizaba el riesgo concreto.

Tres números no reconstruyen una acción

Una caída de tcpCurrEstab, un incremento de tcpEstabResets y otro de tcpOutRsts podrían acompañar una terminación. Ninguno identifica deleteTCB como causa. El primer objeto es una foto del total actual; el segundo reúne transiciones específicas a CLOSED; el tercero cuenta segmentos con RST, no su entrega ni el motivo de emisión.

El expediente causal necesita conservar la fila observada, el instante, la petición autenticada, el rol vigente, el contexto y permiso de escritura sobre esa instancia, la intención documentada, la respuesta del agente, la desaparición del estado local, la reacción de las aplicaciones, la observación del par, los reintentos y el efecto de servicio. Confundir un movimiento compatible con una causa probada deja un hueco que ya no puede cerrarse cuando la fila desaparece.

El sucesor hizo visible una identidad más rica

RFC 4022 sustituyó la tabla antigua porque sólo manejaba IPv4 y mezclaba conexiones con listeners. En la tabla nueva, cada extremo combina InetAddressType, dirección y puerto. RFC 4001 proporciona incluso variantes con índice de zona para direcciones cuyo ámbito no basta para distinguir una interfaz. Los listeners pasaron a una tabla separada que diferencia escucha comodín, por familia o en una dirección concreta.

Además, tcpConnectionProcess y tcpListenerProcess pueden señalar el proceso del sistema operativo. Esa correlación es valiosa, pero no convierte un PID en una persona, una aprobación ni un resultado de negocio. El valor puede ser cero, reutilizarse o tener sentido sólo dentro del host.

El interruptor permaneció: tcpConnectionState conserva deleteTCB(12) y la terminación local inmediata. Sin embargo, la conformidad de RFC 4022 permite acceso mínimo de sólo lectura y declara que escritura y deleteTCB no son obligatorios. Soportar el módulo no prueba soportar el actuador.

La nueva sección de seguridad sí expone la gravedad: el acceso no autorizado podría terminar una conexión arbitraria y causar denegación de servicio; la lectura de conexiones, listeners y procesos también puede revelar información sensible.

Autenticar no es atribuir hasta el resultado

RFC 3414 permite asociar el mensaje a un usuario, proteger integridad y actualidad, y cifrarlo. RFC 3415 separa vistas de lectura, escritura y notificación según modelo, nombre y nivel de seguridad, contexto e instancia. Son piezas necesarias para no entregar a un lector un poder de terminación.

Pero el usuario autenticado es aquel en cuyo nombre se originó el mensaje, no necesariamente el humano exacto. Los modelos tampoco generan por sí solos un ticket, una razón, la confirmación de la aplicación, la recepción del par, el impacto al cliente o la duración.

La enseñanza histórica no exige renunciar a un control de emergencia. Exige que observar, autorizar, ejecutar y verificar sean recibos diferentes. El estándar define una palanca; sólo la operación puede demostrar qué movió.

Fuentes

Límites de la evidencia

Las fuentes prueban textos, linaje, objetos, conformidad y semántica de seguridad. No prueban una implementación concreta, uso real de la escritura, incidentes, frecuencia de despliegue, incumplimiento de SLA ni requisitos operativos actuales.