Nivel de aplicación como la suma de comprobación de la suma de comprobación de tcp podría ser demasiado débil?

Question

Este Papel (Cuando la CDN y de la suma de comprobación de TCP en desacuerdo) sugiere que, dado que la suma de comprobación de TCP algoritmo es bastante débil, habría de producirse un error no detectado cada 16 millones a 10 mil millones de paquetes utilizando TCP.

Hay desarrolladores de aplicaciones por ahí que proteger los datos contra este tipo de errores mediante la adición de las sumas de comprobación en el nivel de aplicación?

Hay modelos disponibles para proteger contra este tipo de errores mientras se hace EJB invocación de método remoto (Java EE 5)?O Java ya suma de comprobación de los objetos serializados automáticamente (además del protocolo de red subyacente)?

El software de la empresa ha estado funcionando en equipos haciendo no sólo de memoria ECC, sino también hacer de comprobación de error dentro de la CPU en los registros etc (SPARC y otros).Errores de bits en sistemas de almacenamiento (discos duros, cables, ...) se pueden prevenir mediante el uso de Solaris ZFS.

Yo no tenía miedo de la red de bits de errores, debido a TCP - hasta que vi que el artículo.

No puede ser que mucho trabajo para implementar el nivel de aplicación de la suma de comprobación para algunos, muy pocos de servidor de cliente de interfaces remotas.Pero, ¿qué acerca de la empresa distribuida de software que se ejecuta en muchas máquinas en un único centro de datos.No puede ser que un gran número de interfaces remotas.

Cada Empresa proveedor de Software como SAP, Oracle y otros simplemente ignorar este tipo de problema?¿Qué acerca de los bancos?¿Qué acerca de la bolsa de valores de software?

Seguimiento: Muchas gracias por todas tus respuestas!Por lo que parece que es bastante raro para comprobar contra desapercibido datos de la red de corrupción - pero ellos no parecen existir.

No puedo resolver este problema simplemente mediante la configuración de los Servidores de Aplicaciones Java EE (o EJB descriptores de despliegue) para el uso de RMI a través de TLS con el TLS configurado para utilizar MD5 o SHA1 y por la configuración de Java SE a los clientes a hacer lo mismo?Sería una manera de conseguir fiable transparente de la suma de comprobación (aunque por overkill) así que yo no tendría que implementar en el nivel de aplicación?O estoy completamente confundido de red de la pila de sabio?

Answer 1

Estoy convencido de que todas las aplicaciones que se preocupa por la integridad de datos debe utilizar un control seguro. La mayoría, sin embargo, no lo hacen. La gente simplemente ignorar el problema.

A pesar de que he visto con frecuencia la corrupción de datos a través de los años - incluso lo que se pone por las sumas de comprobación - el más memorable de hecho involucró a un sistema de comercio de acciones. Un mal enrutador estaba corrompiendo los datos de tal manera que por lo general tiene más allá de la suma de comprobación TCP. Fue volteando el mismo bit de vez en cuando. Y, por supuesto, nadie se alerta a los paquetes que, de hecho, no pasaron la suma de comprobación TCP. La aplicación no tenía comprobaciones adicionales de integridad de datos.

Los mensajes eran cosas como las órdenes comunes y oficios. Las consecuencias de la corrupción de los datos son tan graves como suena.

Por suerte, la corrupción hizo que los mensajes sean lo suficientemente válido para dar como resultado el sistema de comercio totalmente estrellarse. Las consecuencias de alguna pérdida de negocios no eran tan graves como las posibles consecuencias de la ejecución de transacciones fraudulentas.

Hemos identificado el problema con suerte - sesión SSH de alguien entre dos de los servidores implicados fallado con un mensaje de error extraño. Obviamente SSH debe garantizar la integridad de los datos.

Después de este incidente, la compañía no hizo nada para mitigar el riesgo de corrupción de datos durante el vuelo o en el almacenamiento. El mismo código permanece en la producción, y de hecho código adicional ha entrado en producción que asume el ambiente que lo rodea se datos nunca corruptos.

En realidad, esto es la decisión correcta para todas las personas involucradas. Un desarrollador que evita un problema que fue causado por alguna otra parte del sistema (por ejemplo, mala memoria, mala controlador de disco duro, mal router) no es probable que ganar nada. El código adicional crea el riesgo de que la adición de un fallo, o ser culpado por un error que no está realmente relacionado. Si se produce un problema más adelante, será culpa de otra persona.

Para la gestión, es como pasar el tiempo en la seguridad. Las probabilidades de que un incidente son bajos, pero el esfuerzo "desperdiciado" es visible. Por ejemplo, note como la comprobación de la integridad de datos de extremo a extremo se ha comparado con la optimización prematura ya está aquí.

Por lo que las cosas cambian, ya que el documento ha sido escrito - todo lo que ha cambiado es que tenemos mayores velocidades de datos, una mayor complejidad a los sistemas, y una CPU más rápida para hacer un hash criptográfico menos costoso. Más oportunidades para la corrupción, y menos costos a su prevención.

La verdadera cuestión es si es mejor en su entorno para detectar / prevenir los problemas o hacer caso omiso de ellos. Recuerde que al detectar un problema, porque será su responsabilidad. Y si usted pasa tiempo la prevención de problemas que la administración no reconoce es un problema, puede hacer que parezca que está perdiendo el tiempo.

Answer 2

He trabajado en sistemas de comercio para el SII, y les puedo asegurar que no hay una suma de comprobación adicional pasando - la mayoría de las aplicaciones utilizan tomas desnudos. Teniendo en cuenta los problemas actuales en el sector financiero, creo que las malas sumas de comprobación TCP / IP debe ser el menor de sus preocupaciones.

Answer 3

Bueno, que el papel es a partir de 2000, por lo que es desde hace un tiempo largo (hombre, soy de edad), y en un conjunto muy limitado de huellas. Así que toma sus figuras con un enorme grano de sal. Dicho esto, sería interesante ver si esto es todavía el caso. Sin embargo, sospecho que las cosas han cambiado, aunque algunas clases de errores pueden existir aún así, como fallos de hardware.

Más útil que las sumas de comprobación si realmente necesidad la seguridad a nivel de aplicación adicional sería un hash SHA-N de los datos, o MD5, etc.