¿Puede una suma de verificación TCP producir un falso positivo? Si es así, ¿cómo se soluciona esto?

Question

Si una carga útil TCP se corrompe en tránsito, la suma de verificación recomputada no coincidirá con la suma de verificación transmitida. Genial, todo bien hasta ahora.

Si una suma de comprobación TCP se corrompe en tránsito, la suma de comprobación recompuestada no coincidirá con la suma de comprobación ahora corrompida. Genial, todo bien hasta ahora.

¿Qué sucede cuando la carga útil y la suma de comprobación se corrompen y la suma de comprobación recalculada, aunque es diferente de lo que debería ser, coincide con la suma de comprobación ahora corrompida?

Puedo ver con un buen algoritmo de suma de comprobación (y sumas de comprobación adicionales en niveles inferiores) esto podría ser muy poco probable, pero ¿TCP no tiene la intención de ser 100% confiable? ¿Cómo resuelve estos falsos positivos?

Answer 1

y adicionales sumas de comprobación en los niveles inferiores

Algunos de éstos son más estrictas que las sumas de comprobación, por ejemplo Ethernet usa un CRC en lugar de una suma de comprobación.

esto puede ser muy poco probable, pero ¿TCP no tiene la intención de ser 100% confiable? ¿Cómo resuelve estos falsos positivos?

No creo que pueda. Incluso si envió un duplicado a través de una copia impresa y una paloma mensajera, un rayo cósmico o efectos cuánticos podrían teóricamente arruinar el duplicado exactamente de la misma manera. Es muy, muy poco probable.

También puede implementar un corte de integridad arbitrariamente fuerte en la capa de aplicación (arriba de TCP), p. usando la firma criptográfica.

Answer 2

Me imagino que la probabilidad es de uno en billones de billones de billones, porque si los datos de TCP están dañados, que es la capa de transporte, también significará que las otras capas (enlace de datos y red) también estarán dañados. Creo que al menos la capa de enlace de datos tiene una suma de comprobación para la integridad, por lo que tendría que tener ambas sumas de comprobación.

Corromper de tal manera que al menos dos sumas de comprobación independientes fallen, es astronómicamente improbable, tal vez incluso imposible.

Answer 3

¿Puede una suma de comprobación TCP producir un falso positivo?

Sí. La suma de comprobación es considerablemente más pequeña que el paquete, por lo que muchos paquetes diferentes pueden coincidir con una suma de comprobación determinada.

En caso afirmativo, ¿cómo se soluciona esto?

En TCP, nada. Sin embargo, la mayoría de las corrupciones de datos se notarán en un nivel superior, p. su XML ya no está bien formado; su correo electrónico ya no es inglés, etc.

Answer 4

No, no puede ser 100% confiable: this paper menciona 1 en 16 millones a 10 billones de paquetes no detectados por el sistema de control de errores.Voy a dejar que se calculan las ocurrencias por día/semana :)

Answer 5

Supongamos

carga útil del paquete: 1.000 bytes

paquete de suma de comprobación: 2 bytes

probabilidad de paquete con doble error, uno de wchich en la suma de comprobación (asumir P muy pequeña, menos de 1/10^5):

A = 8P*(1000*8P) = 6*10^4 * P^2 

probabilidad de suma de comprobación exacta:

B = 1/2^16 = 6/10^4 

probabilidad de falso positivo:

A * B = 40 * P^2 

La probabilidad es baja (P = 1/10^6, entonces la probabilidad de un falso positivo * B = 4/10^11), pero en cualquier caso con cualquier algoritmo crc no puede ser cero. La probabilidad de que un paquete aleatorio de 1000 bytes aparezca como otro paquete aleatorio de 1000 bytes es P^8000, como si todos los bytes tuvieran errores.

Si P es alto, por ejemplo de 1/10^3 a 1, los cálculos anteriores no se aplican. En ese caso, A = 1 (todos los paquetes contienen errores dobles) y la probabilidad de falso positivo es solo A * B = 6/10^4. No es un caso muy relevante porque más del 99% de los paquetes recibidos contendrán errores en crc.

Answer 6

Algo que debe tenerse en cuenta aquí, y que la mayoría de las personas pasan por alto por completo, es el hecho de que la suma de comprobación TCP es en realidad una suma de comprobación muy pobre.

La suma de comprobación TCP es una suma complementaria de 16 bits de los datos. Esta suma detectará cualquier error de ráfaga de 15 bits o menos, y todos los errores de ráfaga de 16 bits, excepto aquellos que reemplazan un complemento de 1 con otro (es decir, 16 bits adyacentes reemplazados por 16 bits cero o vice -versa). Con datos distribuidos uniformemente, se espera detectar otros tipos de errores a una velocidad proporcional a 1 en 2^16. La suma de comprobación también tiene una limitación importante: la suma de un conjunto de valores de de 16 bits es la misma, independientemente del orden en que aparezcan los valores .

Fuente: ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf

Así que si le da la vuelta al azar cualquier número de bits en cualquier lugar en la parte de datos del paquete, las posibilidades son de 1 a 65536 que no se detecta este error, incluso si no se toca la suma de comprobación en absoluto, ya que los datos nuevos, aunque totalmente corruptos, tienen de hecho la misma suma de comprobación que la anterior. Si solo intercambia dos valores de 16 bits en la parte de datos, independientemente de cuáles e independientemente de la frecuencia, las probabilidades son incluso del 100% de que no se detecte este error, ya que el orden en que aparecen los valores de 16 bits en la parte de datos del el paquete es totalmente irrelevante para el valor de la suma de comprobación calculada.

Lo que trato de decir aquí es que no tiene que preocuparse demasiado por el caso poco probable de que los datos y la suma de comprobación se corrompan y este error no se detecte porque la suma de comprobación corrompida coincide con los datos dañados. la verdad es que todos los días millones de paquetes TCP en Internet tienen solo los datos corruptos y este error no se detecta porque la suma de comprobación no corrompida aún coincide con los datos corruptos.

Si necesita transferir datos y desea asegurarse de que los datos no se corrompan, la suma de comprobación TCP por sí sola no es suficiente para esta tarea. Incluso me atrevo a decir que una suma de comprobación CRC no es suficiente para esta tarea, ya que un CRC32 puede no detectar un error en el que se ven afectados más de 32 bits en una fila (estos errores pueden "cancelarse" entre sí). La suma de comprobación mínima que necesitaría para garantizar una transferencia de datos perfecta es el valor MD5 de los datos. Por supuesto, cualquier cosa mejor que eso (SHA-1, SHA-256, SHA-384, SHA-512, Whirlpool, etc.) funcionará aún mejor, pero MD5 es suficiente. Puede que MD5 ya no sea lo suficientemente seguro para la seguridad criptográfica (ya que se ha roto varias veces en el pasado), pero como suma de comprobación de datos, MD5 es absolutamente suficiente.