RFC 2979
From Wikipedia, the free encyclopedia
RFC 2979 es un documento técnico titulado Comportamiento y Requisitos para Cortafuegos de Internet (en inglés: Behavior of and Requirements for Internet Firewalls, publicado en octubre de 2000 por el Internet Architecture Board.[1] El documento, de categoría «Informativo» y escrito por Ned Freed, define las características de comportamiento y los requisitos de interoperabilidad para los cortafuegos en redes TCP/IP.[2][3]
Aborda problemas de conectividad causados por cortafuegos que bloquean tráfico conforme a los estándares, estableciendo el «Requisito de Transparencia» como criterio de diseño.[4][5] El documento ha sido incorporado en las guías de implementación de fabricantes de hardware de red[6][7] y citado en especificaciones posteriores del IETF.[8]
Requisito de transparencia
El texto establece que la introducción de un cortafuegos no debe ocasionar fallos involuntarios en el uso legítimo y conforme a los estándares de las aplicaciones de red.[4][5]
El documento estipula que:
- Los protocolos estándar no deben requerir modificaciones para atravesar un cortafuegos.[9]
- Si se producen fallos en tráfico legítimo, la responsabilidad de corregirlos recae en la implementación del cortafuegos.[10]
- El requisito aplica al funcionamiento técnico y no impide el bloqueo deliberado de tráfico basado en políticas administrativas de seguridad.[10]
Especificaciones técnicas
El RFC detalla requisitos técnicos específicos para garantizar la interoperabilidad:[4]
- Path MTU Discovery (PMTUD): Los cortafuegos deben permitir el paso de mensajes ICMP tipo 3 código 4 (Fragmentation Needed). El bloqueo de estos mensajes impide la negociación del tamaño máximo de paquete (MTU), causando interrupciones en conexiones de datos.[11]
- Extensiones de Protocolo (SMTP/HTTP): Si un cortafuegos actúa como intermediario (Application Layer Gateway) e inspecciona protocolos como SMTP, debe soportar las extensiones negociadas (ESMTP) o filtrar los comandos de negociación para evitar que cliente y servidor acuerden capacidades que el cortafuegos no puede procesar.[12]
- Banderas TCP: El documento indica que no se debe asumir que los campos reservados en las cabeceras de protocolo (como banderas TCP no utilizadas en el momento del diseño) deben ser cero, permitiendo así la evolución futura de los protocolos.[13]
