Summary

  • RFC 2979 separó la denegación de seguridad deliberada del fallo involuntario de un protocolo conforme; este último correspondía al cortafuegos y al software asociado.
  • Sus ejemplos de descubrimiento de MTU y extensiones SMTP mostraron cómo un intermediario podía interrumpir una conversación bajo una regla aparentemente sencilla.

Política de acceso y avería del protocolo no son equivalentes

Alrededor de 2000, el ideal de extremo a extremo chocaba con una frontera práctica: cada vez más organizaciones conectaban sistemas internos valiosos a redes que no controlaban por completo. Los cortafuegos aportaban un punto de inspección, pero su comportamiento estaba a menudo poco especificado y variaba entre implementaciones.

RFC 2775 ya describía la «transparencia» como un conjunto de propiedades: funciones de extremo a extremo, rendimiento y transparencia de direcciones. RFC 2979 acotó el debate a un contrato operativo. Incorporar un cortafuegos, túnel o mecanismo de negociación de acceso no debía provocar fallos involuntarios en usos legítimos y conformes que funcionarían sin él. Si ocurrían, la corrección correspondía al cortafuegos o a su software asociado; no debía exigirse cambiar el protocolo existente ni su implementación.

La regla no exigía aceptar todos los paquetes. El sitio podía bloquear el tráfico que considerase ilegítimo incluso si seguía un estándar. También podía exigir autenticación o autorización adicional mediante mecanismos como SOCKS, siempre que existieran configuraciones en las que esos mecanismos no fueran obligatorios. Lo decisivo era distinguir un rechazo deliberado conforme a política de una rotura accidental causada por un intermediario que no entendía el intercambio.

Un error ICMP podía dejar un flujo válido en un agujero negro

El caso de Path MTU Discovery lo hizo tangible. En IPv4, un emisor podía marcar un paquete como «Don't Fragment». Si un enlace posterior no podía transportarlo, un router devolvía un ICMP «Destination Unreachable / Fragmentation Needed» para que el emisor redujera el tamaño. Si el cortafuegos dejaba salir el paquete pero descartaba la respuesta correspondiente, el emisor podía repetir tráfico demasiado grande: un agujero negro, no una decisión de seguridad útil.

RFC 2979 no pedía permitir todo ICMP. Diferenciaba el error asociado a tráfico legítimo saliente de mensajes Echo, Redirect u otros errores sin relación, que el sitio podía bloquear. El contexto importaba: la misma familia de protocolos contiene mensajes necesarios para intercambios válidos y otros que una política puede rechazar.

La respuesta a EHLO podía convertir el filtrado en un problema de tres partes

En SMTP, un cliente solicita extensiones con EHLO; el servidor anuncia capacidades; el cliente puede seleccionar una. Un proxy que añadía EHLO a sus comandos permitidos pero no filtraba la respuesta del servidor podía dejar que ambos extremos acordaran una extensión que el propio proxy no comprendía. Cada extremo seguía una lógica razonable, pero el intermediario había permitido una conversación que no podía transportar correctamente.

La lección no era que cada cortafuegos tuviera que implementar toda extensión nueva. RFC 2979 recomendaba facilitar el tránsito si eso no perjudicaba la aplicación. También desaconsejaba envolver un protocolo nuevo dentro de HTTP solo porque el puerto 80 probablemente estuviera abierto; un subconjunto seguro, un mecanismo de tránsito apropiado o un puerto registrado aparte podían ser opciones más transparentes.

Lo que el RFC establece y lo que no demuestra

RFC 2979 es un memorando Informativo, no un Estándar de Internet. El historial indica que el IESG lo aprobó en agosto de 2000 y que se publicó en octubre. El registro acredita un principio de diseño y varios ejemplos, no la adopción por productos, tasas de conformidad, una reducción de los rodeos ni mejoras medidas de seguridad.

Su aporte histórico fue asignar responsabilidades: la política puede rechazar un flujo, pero la incompatibilidad accidental no debe convertirse silenciosamente en una obligación para los desarrolladores de aplicaciones. Un operador puede usar esa distinción para clasificar una avería: ¿se denegó deliberadamente el acceso o un filtro, proxy o analizador rompió un intercambio conforme? Ese diagnóstico es una inferencia, no una medida de la conducta real de los operadores.

RFC 3093, publicado en abril de 2001 con fecha del día 1, es un artefacto vecino y distinto: su «Firewall Enhancement Protocol» proponía encapsular IP/TCP en HTTP. No prueba que RFC 2979 fracasara ni que el túnel se desplegara. El filtrado tampoco debe confundirse con NAT: RFC 2979 separa expresamente esas funciones, aunque un aparato real pueda combinarlas.

Fuentes: RFC 2979; RFC 2775; RFC 3093; historial del borrador; RFC 1191; RFC 1869.