Resumen

  • RFC 894 fijó 0800 hexadecimal como EtherType de IPv4 y ordenó completar con ceros el campo de datos cuando no alcanzara los 46 octetos mínimos de Ethernet. El relleno circulaba por el enlace, pero no formaba parte del paquete IP ni de Total Length.
  • El receptor necesitaba obedecer dos medidas: reservar memoria para la carga de enlace recibida y limitar el análisis de IP a Total Length. RFC 6274 expresó después esa relación y exigió descartar el caso en que el enlace entregara menos bytes que los declarados por IP.
  • Los bytes excluidos de IP seguían siendo observables. CERT/CC documentó controladores que reutilizaban contenido antiguo como relleno; los dos errata verificados de RFC 894 muestran una separación paralela entre el texto publicado y su interpretación corregida.

La fuga empezó después del final de IP

La nota de vulnerabilidad CERT/CC VU#412115 describió un fallo con una geometría extraña. El datagrama podía ser válido. Su cabecera podía indicar correctamente el final. Sin embargo, el controlador necesitaba alargar la trama hasta el mínimo de Ethernet y no limpiaba la zona añadida. Copiaba fragmentos que habían quedado en memoria.

Un vecino capaz de observar la trama recibía así información que la aplicación nunca había enviado: según el sistema, memoria del kernel, memoria estática del controlador o un búfer del adaptador. La vulnerabilidad no convertía esos bytes en una carga IP legítima. Precisamente mostraba que la ausencia de significado IP no equivale a ausencia física.

CERT publicó estados diferentes para productos y fabricantes. No se puede concluir que todos los controladores fueran vulnerables. Sí se puede afirmar que el mecanismo existió y que incumplir el relleno nulo produjo divulgación remota en implementaciones notificadas.

Veinte octetos podían necesitar una trama con cuarenta y seis

La regla original estaba en RFC 894, de abril de 1984. El EtherType de una trama con IPv4 debía ser 0800 hexadecimal. En su campo de datos aparecía primero la cabecera IP y, sin separación, los datos IP.

Ethernet exigía al menos 46 octetos en ese campo. Si el datagrama era más corto, el emisor añadía octetos de valor cero. La norma decía expresamente que ese relleno no pertenecía al paquete IP y no se incluía en Total Length.

Una cabecera IPv4 mínima ocupa veinte octetos. Si no contiene datos, quedan veintiséis octetos físicos hasta el mínimo de Ethernet. Añadirlos a Total Length falsificaría el objeto: una capa inferior estaría inventando carga para una capa superior. Omitirlos rompería la condición del enlace. El relleno resolvía la necesidad física sin transferir propiedad semántica.

El RFC 791 ya había definido el límite interno. Total Length cuenta el datagrama completo, cabecera IP y datos. IHL cuenta la cabecera en palabras de 32 bits y localiza el comienzo de los datos. Por tanto, la cabecera debe caber en Total Length y el datagrama debe caber en lo que entrega el enlace.

Un campo seleccionaba el formato y otro marcaba el final

La misma posición de dos octetos podía ser un campo de longitud en IEEE 802.3 o un EtherType en Ethernet. RFC 1122 fijó la separación práctica: hasta 1500 era longitud 802.3; los EtherType válidos estaban por encima de 1500.

0800 hexadecimal equivale a 2048 decimal. No significa que la carga mida 2048 octetos. Significa que el receptor debe abrir la gramática IPv4. Dentro de esa gramática, Total Length decide dónde termina el datagrama.

Confundir las dos autoridades produce errores opuestos. Tratar 2048 como longitud hace imposible el formato real. Tratar el final del búfer Ethernet como final de IP incorpora el relleno a una capa que lo había excluido.

RFC 1122 exigía enviar y recibir el formato de RFC 894 en un cable Ethernet de 10 Mb/s. Recomendaba recibir el formato IEEE 802 de RFC 1042 y permitía enviarlo. Si un host podía transmitir ambos, una opción de configuración debía escoger y usar RFC 894 por defecto.

LLC y SNAP ocupaban sitio sin reescribir IP

RFC 1042 introducía ocho octetos conjuntos de LLC y SNAP. SNAP conservaba en sus dieciséis bits finales el EtherType: 2048 para IP y 2054 para ARP. Cuando IEEE 802 necesitaba un tamaño mínimo, también se añadían ceros fuera de Total Length.

El texto hablaba de un mínimo de 28 octetos para IP en esa encapsulación: veinte de cabecera IPv4 y ocho de LLC/SNAP, sin incluir la cabecera MAC. Esa cuenta no es el mínimo de 46 octetos del campo de datos Ethernet. Una incluye un encabezado de enlace concreto; la otra expresa el suelo físico de otro encuadre.

RFC 1122 dio MTU 1500 para Ethernet y 1492 para 802.3. Los ocho octetos exteriores reducían el espacio disponible en el segundo formato. No reducían IHL ni autorizaban a contar el relleno como datos IP.

El RFC 895 muestra que la regla no dependía de 1500. Para el Ethernet experimental de 3 Mb/s, con direcciones de ocho bits, el máximo IP era 1536 y el tipo era distinto. Aun así, el relleno necesario para el mínimo seguía fuera de Total Length. Cambiaba el vehículo, no el título de propiedad del datagrama.

Una errata no es una actualización del cable

La publicación de RFC 894 conserva un error: llama “mínimo” a 1500 octetos y de inmediato deduce un máximo de datagrama de 1500. El párrafo anterior había establecido el mínimo verdadero de 46.

El erratum 570, verificado como técnico, cambia la palabra por “máximo”. El erratum 5141, notificado en 2017 y verificado en 2024, registra la misma corrección. No hubo un nuevo MTU en 2024; hubo una nueva verificación documental.

La política del RFC Editor explica por qué el fallo sigue visible. Los RFC publicados no cambian y los errata verificados no se incorporan a los formatos TXT, PDF o XML. El texto original conserva la prueba de lo publicado; el registro conserva la prueba de cómo debe leerse.

Editar silenciosamente una copia local simplifica la consulta pero destruye esa relación. Ignorar el erratum conserva el original pero produce una interpretación absurda. La solución es mantener ambos registros y citar la transformación.

El trailer era otra operación

El RFC 893 también colocaba material al final de una trama, pero por un motivo y con una sintaxis distintos. Su trailer encapsulation movía cabeceras variables detrás de los datos para favorecer la alineación de memoria en receptores compatibles.

El relleno de RFC 894 no movía nada. La cabecera IP seguía delante y los datos detrás. Los ceros aparecían una vez terminado el datagrama. Un receptor no debía reconstruir un paquete reordenado; sólo debía dejar de interpretar al alcanzar Total Length.

Un pad tampoco es FCS, opción IP ni datos de aplicación. Estar cerca del final físico no convierte funciones diferentes en la misma cosa.

La memoria exterior se dimensionaba con la regla exterior

En RFC 6274, la evaluación de seguridad de IPv4 reconoció que el módulo IP podía recibir una carga de enlace mayor que Total Length. El relleno legítimo era una causa habitual; una manipulación maliciosa podía ser otra.

La recomendación era reservar el búfer según el tamaño que informa el enlace. De ese modo la recepción del contenedor no desborda el espacio elegido a partir de un objeto interior más pequeño. Después, el análisis IP continúa limitado por Total Length.

En sentido contrario no hay margen: LinkLayer.PayloadSize >= Total Length. Si llegaron menos bytes de los que afirma IP, se descarta y registra. La cabecera también debe cumplir IHL × 4 <= Total Length.

Esas dos desigualdades describen una jerarquía, no una única verdad. El enlace responde de la capacidad y de los bytes que entregó. IP responde de la extensión del datagrama. La seguridad depende de no pedir a una medida que suplante a la otra.

Fuentes