Resumen

  • RFC 3385 mostró que «suma de comprobación de 32 bits» era una descripción incompleta: el polinomio generador, la longitud protegida, la distribución de errores y el sesgo de los datos cambiaban la no detección.
  • CRC32C fue considerado una buena base para iSCSI bajo un modelo declarado de corrupción accidental, no una garantía criptográfica ni una probabilidad universal.

Una ráfaga compacta de bits alterados atraviesa una suma aditiva y se detiene ante un CRC. Ambos resultados caben en cuatro bytes. La anchura visible informa cuánta redundancia viaja, pero no qué patrones sabe distinguir cada código. RFC 3385 convirtió esa diferencia oculta en una decisión analizable.

El memorando apareció en septiembre de 2002 como Informational. Estimaba probabilidades de error no detectado para ayudar a escoger un mecanismo de iSCSI. No era por sí solo el protocolo completo, una certificación de producto ni un informe de adopción. Sus cifras eran resultados condicionados por un modelo, no frecuencias garantizadas para cualquier red.

iSCSI trasladaba comandos SCSI y datos de almacenamiento sobre IP. Una corrupción silenciosa podía abandonar la red convertida en contenido aparentemente válido para un dispositivo o sistema de archivos. El volumen agravaba el riesgo: el texto pensaba en petabytes y pedía buen comportamiento al menos hasta bloques de 8 KiB.

RFC 3347 ya había señalado que el checksum TCP no cerraba la historia. Algunos errores podían escapar. Además, un proxy o gateway terminaba el flujo TCP, reconstruía cabeceras iSCSI y volvía a calcular el checksum. Datos, comandos y estado SCSI necesitaban por ello una frontera de digest propia.

RFC 3385 distinguió errores en ráfaga de canales ruidosos y cambios independientes de un bit en canales de poco ruido. Una memoria, un enlace interno o un defecto de software también podían producir daño agrupado. No bastaba contar bits erróneos: importaban su distribución, duración y la longitud del bloque.

Un CRC añade redundancia calculada con un polinomio generador. Un receptor acepta una palabra dañada solo si el patrón de error también encaja en la estructura del código. La distancia mínima y la distribución de pesos delimitan lo invisible. «32 bits» describe cantidad, no esa geometría.

Los códigos acortados hicieron visible la diferencia. Polinomios del mismo grado podían rendir de modo distinto en longitudes prácticas. La literatura citada mostraba diferencias de varios órdenes de magnitud entre polinomios de 32 bits bajo una condición concreta de ráfaga. Una clasificación por anchura habría declarado equivalentes justo a los códigos que el análisis separaba.

El CRC de IEEE 802 y CRC32C medían 32 bits, pero CRC32C usaba el generador 0x11EDC6F41. Ese valor no era decoración. Cambiaba qué polinomios de error eran divisibles y, con ello, la distancia y el riesgo de no detección en cada rango.

Las estimaciones dependían de supuestos sobre tasa de ráfagas, tasa de errores independientes, distribución temporal y bloque de 8 KiB. Una ráfaga de duración fija ocupa más bits cuando aumenta la velocidad. Cambiar canal, carga, bloque o distribución cambia la afirmación. Un número diminuto no puede desprenderse de sus condiciones.

La comparación con Fletcher y Adler reforzaba el punto. Para los errores independientes analizados, el CRC era estimado unas 12.000 veces mejor que Fletcher y 22.000 veces mejor que Adler. Algunos patrones cortos se anulaban en sumas aditivas. Los datos reales, sesgados y con puntos calientes, podían empeorar aún más esos checksums.

La tabla final reunió Fletcher32, Adler32, CRC IEEE-802 y CRC32C. Todos tenían 32 bits, pero distancias y probabilidades modeladas diferentes. Los autores juzgaron CRC32C una buena base por su protección, menor sensibilidad al sesgo y capacidad sobre bloques largos.

También midieron coste. La síntesis citada daba a CRC32C más celdas que CCITT-CRC32, pero el circuito completo seguía por debajo del uno por ciento de un chip representativo de un millón de celdas. La decisión no decía «gratis»; colocaba coste e integridad en la misma escala.

Para interoperar tampoco bastaba el nombre del polinomio. Orden de bits, inicialización, complemento, relleno y mapeo del resto debían coincidir. El memorando mostró implementaciones serie y paralela; el software podía usar tablas. Dos equipos podían anunciar CRC32C y calcular valores distintos si el procedimiento divergía.

La linealidad permitía actualizar el CRC incrementalmente cuando un nodo cambiaba una cabecera, sin releer todo el bloque. El destino final aún podía verificar el conjunto e incluir alteraciones accidentales de saltos intermedios. Era una propiedad de rendimiento y cobertura, no autenticación del nodo.

RFC 7143 consolidó después el contrato iSCSI. HeaderDigest y DataDigest tienen None por defecto, pero iniciadores y destinos deben implementar CRC32C y None. Una vez negociado, el digest se usa en los PDU de la fase completa. La especificación lo llama no criptográfico.

Soportar CRC32C, ofrecerlo, seleccionarlo, cubrir un PDU, superar la verificación y mantener integridad más allá de iSCSI son hechos separados. Una etiqueta de compatibilidad no demuestra que todas las sesiones estén protegidas.

La frontera de seguridad era tajante. Un atacante capaz de alterar datos puede recalcular el código. El CRC detecta cambios accidentales; no autentica origen ni autorización. Una comprobación correcta es evidencia contra ciertos fallos, no contra un adversario activo.

RFC 3309 y luego RFC 4960 y RFC 9260 también usaron CRC32C en SCTP. Esa cronología prueba reutilización, no igualdad del modelo. Longitud, campos cubiertos, capas inferiores y recuperación modifican el significado de la evidencia.

RFC 1071 documentó el checksum Internet. RFC 1141 y RFC 1624 trataron su actualización incremental, y el segundo corrigió una dificultad del primero. RFC 2151 describió Fletcher para UDP; RFC 1950, Adler-32 para zlib. «Checksum» nombra una familia de propósitos, no una garantía intercambiable.

El texto terminó recordando que un CRC superior no estabiliza por sí solo el riesgo cuando los enlaces aceleran. Una ráfaga temporal abarca más bits. Mejor codificación y menor tasa de error en capas inferiores permanecen dentro de la superficie de control.

La especificación inicial mínima de Lu Heng explica el reparto: el protocolo fija polinomio, representación y cobertura compartida; cada implementación optimiza hardware o software después. La libertad comienza cuando «verificado» ya significa lo mismo para todos.

Su marco de capas de realidad separa campo presente, algoritmo implementado, digest negociado, PDU cubierto, valor válido, corrupción accidental excluida bajo un modelo e integridad frente a adversarios. «Tiene checksum de 32 bits» comprime siete hechos y casi no prueba ninguno.

La contribución histórica de RFC 3385 no fue solo recomendar CRC32C. Enseñó a convertir un lema de integridad en una afirmación limitada. Los bits eran la carcasa; polinomio, bloque, carga, trayecto y amenaza decidían su significado honesto.

Fuentes