niveau d'application checksumming comme tcp checksumming pourrait être trop faible?

Question

Ce document ( Lorsque la somme de contrôle CRC et TCP sont en désaccord ) suggère que puisque l'algorithme TCP checksumming est plutôt faible, il y aurait une erreur se produit non détecté tous les 16 millions à 10 milliards de paquets en utilisant TCP.

Y a-t-il des développeurs d'applications là-bas qui protègent les données contre ce genre d'erreurs en ajoutant les checksum niveau de l'application?

Y a-t-il des modèles disponibles pour se protéger contre ces erreurs tout en faisant appel de méthode distante EJB (Java EE 5)? Ou bien des objets Java sérialisés déjà checksum automatiquement (en plus du protocole de réseau sous-jacent)?

logiciels d'entreprise a été en cours d'exécution sur les ordinateurs qui font non seulement la mémoire ECC, mais aussi faire la vérification des erreurs dans le CPU dans les registres, etc. (SPARC et d'autres). Les erreurs de bit à des systèmes de stockage (disques durs, câbles, ...) peuvent être évités en utilisant Solaris ZFS.

Je n'ai jamais peur d'erreurs de bit réseau en raison de TCP -. Jusqu'à ce que j'ai vu que l'article

Il pourrait ne pas être que beaucoup de travail à mettre en œuvre au niveau des applications checksumming pour certains très peu de serveur client interfaces distantes. Mais qu'en est-logiciels distribués d'entreprise qui fonctionne sur de nombreuses machines dans un seul centre de données. Il peut y avoir un certain nombre vraiment énorme d'interfaces distantes.

Est tous les fournisseurs de logiciels d'entreprise comme SAP, Oracle et d'autres simplement ignorer ce genre de problème? Qu'en est-il des banques? Qu'en est-il des logiciels de bourse?

Suivi: Merci pour toutes vos réponses! Il semble donc qu'il est assez rare de vérifier contre la corruption de données réseau non détectée -. Mais ils ne semblent exister

Ne pourrais-je résoudre ce problème simplement en configurant les Java EE Serveurs d'applications (ou descripteurs de déploiement EJB) pour utiliser RMI sur TLS avec le TLS configuré pour utiliser MD5 ou SHA1 et en configurant les clients Java SE à faire la même chose? Serait-ce un moyen d'obtenir checksumming transparent fiable (bien que par Overkill) de sorte que je ne voudrais pas avoir à mettre en œuvre ce au niveau de l'application? Ou suis-je réseau pile complètement confus sage?

Answer 1

Je suis convaincu que toutes les applications qui se soucie de l'intégrité des données doit utiliser un hachage sécurisé. La plupart, cependant, ne le font pas. Les gens ignorent tout simplement le problème.

Bien que j'ai souvent vu la corruption de données au fil des années - même celle qui obtient par checksum - le plus mémorable en fait impliqué un système de négociation d'actions. Un mauvais routeur corrompait des données telles qu'il a généralement passé la somme de contrôle TCP. Il feuilletait le même bit et hors tension. Et bien sûr, personne n'est averti pour les paquets qui en fait échoué la somme de contrôle TCP. L'application avait pas de contrôles supplémentaires pour l'intégrité des données.

Les messages étaient des choses comme des ordres d'achat d'actions et des métiers. Les conséquences de corrompre les données sont aussi graves que cela puisse paraître.

Heureusement, la corruption a causé les messages soient suffisamment valides pour entraîner le système commercial complètement écraser. Les conséquences de certaines affaires perdues étaient loin d'être aussi grave que les conséquences potentielles de l'exécution des transactions fictives.

Nous avons identifié le problème avec de la chance - la session SSH de quelqu'un entre deux des serveurs concernés a échoué avec un message d'erreur étrange. Il est évident que SSH doit assurer l'intégrité des données.

Après cet incident, l'entreprise n'a rien fait pour atténuer le risque de corruption des données en vol ou en stockage. Le même code reste en production, et en fait un code supplémentaire est entré dans la production qui suppose l'environnement autour des données sera jamais corrompus.

est en fait la bonne décision pour toutes les personnes concernées. Un développeur qui empêche un problème qui a été causée par une autre partie du système (par exemple mauvaise mémoire, le contrôleur mauvais disque dur, mauvais routeur) ne risque pas de gagner quoi que ce soit. Le code supplémentaire crée le risque d'ajouter un bogue ou d'être blâmé pour un bug qui ne sont pas en fait lié. Si un problème survient plus tard, ce sera la faute de quelqu'un d'autre.

Pour la gestion, il est comme le temps passé sur la sécurité. Les chances d'un incident sont faibles, mais l'effort « gaspillé » est visible. Par exemple, notez comment la vérification de l'intégrité des données de bout en bout a été comparé à l'optimisation prématurée déjà ici.

Dans la mesure où les choses ont changé depuis la que le papier a été écrit - tout ce qui a changé est que nous avons des taux plus élevés de données, plus de complexité des systèmes et des processeurs plus rapides pour faire un hachage cryptographique moins coûteux. Plus de possibilités de corruption, et à moindre coût pour l'empêcher.

La vraie question est de savoir s'il vaut mieux dans votre environnement pour détecter / prévenir les problèmes ou de les ignorer. Rappelez-vous que par la détection d'un problème, il peut devenir votre responsabilité. Et si vous passez du temps de prévenir les problèmes que la gestion ne reconnaît pas un problème, il peut vous faire ressembler à vous perdez votre temps.

Answer 2

J'ai travaillé sur les systèmes de négociation pour IBs, et je peux vous assurer qu'il n'y a pas checksumming supplémentaire en cours - la plupart des applications utilisent des prises nues. Compte tenu des problèmes actuels du secteur financier, je pense que les mauvais checksums TCP / IP doit être le moindre de vos soucis.

Answer 3

Eh bien, ce papier est de 2000, il est donc d'une il y a longtemps (homme, suis-je vieux), et sur un ensemble assez limité de traces. Alors, prenez leurs chiffres avec un énorme grain de sel. Cela dit, il serait intéressant de voir si cela est encore le cas. Cependant, je soupçonne que les choses ont changé, bien que certaines classes d'erreurs peuvent encore exister bien, comme les défauts matériels.

Plus utile que si vous avez vraiment checksums besoin l'assurance extra-niveau d'application serait un hachage SHA-N des données, ou MD5, etc.