Resumen

  • RFC 1141 ofreció una operación rápida para corregir la suma de comprobación almacenada en una cabecera IP cuando cambiaba un campo, como el TTL.
  • RFC 1624 mostró un caso límite: la fórmula producía 0xFFFF y el cálculo completo producía 0x0000. La diferencia dependía de los dos ceros del complemento a uno.

En una prueba de producto, un cálculo que parecía impecable entregó una cabecera con la suma equivocada. El error cabía en dieciséis bits y en una broma de matemáticos: el complemento a uno tiene dos formas de escribir cero. El atajo había elegido una; la operación completa exigía la otra. Ahí terminó la tranquilidad de una fórmula publicada cuatro años antes.

El RFC 1071 de septiembre de 1988 expuso la mecánica de la suma de comprobación de Internet. Se agrupan los bytes en palabras de 16 bits, se suman con aritmética de complemento a uno y se coloca el complemento del total en el campo correspondiente. Al verificar, puede sumarse la cabecera con ese campo incluido: todos los bits a uno indican un resultado válido. El documento dedicó mucha atención al rendimiento, desde el orden de bytes hasta la suma en paralelo y la combinación del cálculo con copias de memoria.

Había un ahorro todavía más directo. Un router que reduce el tiempo de vida de un paquete cambia un campo de la cabecera. Los demás continúan iguales. El RFC 1071 explicó que podía actualizarse la suma a partir de la diferencia, sin pasar otra vez por toda la cabecera. El RFC 1141 de enero de 1990 trasladó la idea a una fórmula aplicada al valor que realmente se guarda en el paquete. En su ejemplo habitual, restar una unidad al TTL llevaba a añadir 0x100 al campo de suma de comprobación cuando el TTL ocupaba el byte alto de la palabra.

El ahorro tenía una pequeña deuda matemática. En complemento a uno, 0x0000 representa el cero positivo y 0xFFFF el negativo. Los dos valen cero para ciertas operaciones, pero el paquete transporta bits concretos. El RFC 1624 de mayo de 1994 señaló que la transformación usada por RFC 1141 presuponía una propiedad distributiva que fallaba al llegar a cero. El cálculo abreviado podía dejar en la cabecera una versión del cero distinta de la que daba el recálculo.

El documento ofreció una cuenta que cualquiera podía repetir. Un campo de 16 bits pasa de 0x5555 a 0x3285; la suma de las demás palabras es 0xCD7A. La suma de comprobación anterior vale 0xDD2F. Rehacer la operación para la nueva cabecera da 0x0000. Aplicar el atajo de RFC 1141 da 0xFFFF. La ecuación corregida de RFC 1624, HC' = ~(~HC + ~m + m'), devuelve 0x0000. La diferencia no era un asunto de presentación: el campo de checksum de aquella cabecera no podía tomar 0xFFFF tras un cálculo completo con al menos un campo no nulo.

El siguiente paso del paquete complicaba la historia de forma interesante. Una máquina que verifica sumando toda la cabecera, incluido el checksum, obtiene todos los bits a uno con cualquiera de los dos valores en este ejemplo. Acepta ambos. Otra que vuelve a calcular el campo y compara los bits exactos con el campo recibido puede rechazar 0xFFFF. El mismo resultado del atajo encontraba destinos diferentes según la rutina de verificación.

RFC 1624 dejó constancia de cómo apareció el problema: pruebas sobre un producto que implementaba el algoritmo de RFC 1141 descubrieron la condición; una simulación confirmó el arreglo. No hizo falta convertir el caso en una catástrofe imaginaria. La prueba, los números y la ecuación bastaban. También describió una forma de restar con préstamo para reducir el pequeño coste adicional de la corrección.

Actualizar un checksum sin sumar todo de nuevo seguía siendo una buena idea. Había que hacerlo con una cuenta que preservase los bits correctos en los bordes. El cero gemelo recordó a los implementadores que una igualdad elegante en la pizarra no siempre entrega el mismo paquete en el cable.