Prüfsumme auf Anwendungsebene, da die TCP-Prüfsumme zu schwach sein kann?

Question

Dieses Papier (When the CRC and TCP checksum disagree) schlägt vor, dass, da der TCP-Prüfsummen-Algorithmus ziemlich schwach ist, ein unerkannter Fehler alle 16 Millionen bis 10 Milliarden Pakete unter Verwendung von TCP auftreten würde.

Gibt es Anwendungsentwickler, die die Daten vor solchen Fehlern schützen, indem sie Prüfsummen auf Anwendungsebene hinzufügen?

Gibt es Muster zum Schutz vor solchen Fehlern beim EJB-Remote-Methodenaufruf (Java EE 5)? Oder prüft Java bereits serialisierte Objekte automatisch (zusätzlich zum zugrunde liegenden Netzwerkprotokoll)?

Enterprise-Software läuft auf Computern nicht nur Speicher ECC, sondern auch Fehlerprüfung innerhalb der CPU in den Registern usw. (SPARC und andere). Bitfehler bei Speichersystemen (Festplatten, Kabel, ...) können durch Verwendung von Solaris ZFS verhindert werden.

Ich hatte nie Angst vor Netzwerkbitfehlern wegen TCP - bis ich diesen Artikel sah.

Es kann nicht so viel Arbeit sein, die Prüfsumme auf Anwendungsebene für einige wenige Client-Server-Remote-Schnittstellen zu implementieren. Aber was ist mit verteilter Unternehmenssoftware, die auf vielen Rechnern in einem einzigen Rechenzentrum läuft? Es kann eine wirklich große Anzahl von Remote-Schnittstellen geben.

Bricht jeder Enterprise Software Hersteller wie SAP, Oracle und andere diese Art von Problem einfach ab? Was ist mit Banken? Was ist mit Börsensoftware?

Follow-up: Vielen Dank für Ihre Antworten! Es scheint also ziemlich ungewöhnlich zu sein, unbemerkte Netzwerkdaten zu überprüfen - aber sie scheinen zu existieren.

Konnte ich dieses Problem nicht einfach lösen, indem ich die Java EE-Anwendungsserver (oder EJB-Implementierungsdeskriptoren) für die Verwendung von RMI über TLS mit dem für die Verwendung von MD5 oder SHA1 konfigurierten TLS konfigurierte und die Java SE-Clients dazu konfigurierte ? Wäre dies eine Möglichkeit, um ein zuverlässiges transparentes Prüfsummenverfahren zu erhalten (obwohl durch Overkill), so dass ich dies nicht auf Anwendungsebene implementieren müsste? Oder bin ich komplett verwirrt vom Netzwerk-Stack?

Answer 1

Ich bin überzeugt, dass jede Anwendung, die über Daten kümmert sich Integrität sollte einen sicheren Hash verwenden. Die meisten jedoch nicht. Leute ignorieren einfach das Problem.

Obwohl ich im Laufe der Jahre häufig Datenkorruption gesehen habe - sogar die, die durch Prüfsummen kommt - das denkwürdigste war tatsächlich ein Aktienhandelssystem. Ein schlechter Router korrumpierte die Daten so, dass er normalerweise die TCP-Prüfsumme überschritt. Es wurde das gleiche Bit aus- und wieder eingeschaltet.Und natürlich wird niemand für die Pakete alarmiert, die tatsächlich die TCP-Prüfsumme versagten. Die Anwendung hatte keine zusätzlichen Prüfungen auf Datenintegrität.

Die Nachrichten waren Dinge wie Aktienbestellungen und Trades. Die Folgen der Datenverfälschung sind so gravierend, wie es sich anhört.

Zum Glück verursachte die Korruption die Nachrichten ungültig genug, um das Handelssystem vollständig zum Absturz zu bringen. Die Folgen einiger entgangener Geschäfte waren bei weitem nicht so schlimm wie die möglichen Folgen der Ausführung von Scheintransaktionen.

Wir haben das Problem mit Glück identifiziert - jemand SSH Sitzung zwischen zwei der beteiligten Server mit einer seltsamen Fehlermeldung fehlgeschlagen. Offensichtlich muss SSH die Datenintegrität sicherstellen.

Nach diesem Vorfall hat das Unternehmen nichts unternommen, um das Risiko der Datenbeschädigung während des Fluges oder der Speicherung zu verringern. Derselbe Code verbleibt in der Produktion, und tatsächlich ist zusätzlicher Code in Produktion gegangen, der davon ausgeht, dass die Umgebung keine Daten korrumpiert.

Dies ist eigentlich die richtige Entscheidung für alle beteiligten Personen. Ein Entwickler, der ein Problem verhindert, das von einem anderen Teil des Systems verursacht wurde (z. B. schlechter Speicher, schlechter Festplattencontroller, schlechter Router), wird wahrscheinlich nichts gewinnen. Der zusätzliche Code birgt das Risiko, einen Fehler hinzuzufügen oder für einen Fehler verantwortlich gemacht zu werden, der nicht wirklich damit zusammenhängt. Wenn ein Problem später auftritt, ist es die Schuld eines anderen.

Für das Management ist es wie Zeit für Sicherheit. Die Wahrscheinlichkeit eines Vorfalls ist gering, aber die "verschwendete" Anstrengung ist sichtbar. Beachten Sie beispielsweise, dass hier bereits eine Ende-zu-Ende-Datenintegritätsprüfung mit einer vorzeitigen Optimierung verglichen wurde.

Soweit sich die Dinge seit der Veröffentlichung dieses Papiers geändert haben - alles, was sich geändert hat, sind größere Datenraten, mehr Komplexität für Systeme und schnellere CPUs, um einen kryptografischen Hash-Code kostengünstiger zu machen. Mehr Chancen für Korruption und weniger Kosten, um sie zu verhindern.

Das eigentliche Problem ist, ob es in Ihrer Umgebung besser ist, Probleme zu erkennen/zu verhindern oder zu ignorieren. Denken Sie daran, dass durch die Erkennung eines Problems Ihre Verantwortung übernommen werden kann. Und wenn Sie Zeit damit verbringen, Probleme zu vermeiden, die das Management nicht erkennt, können Sie so aussehen, als würden Sie Zeit verschwenden.

Answer 2

Ich habe an Handelssystemen für IBs gearbeitet, und ich kann Ihnen versichern, dass es kein zusätzliches Checksummen gibt - die meisten Apps verwenden nackte Sockets. Angesichts der aktuellen Probleme im Finanzsektor denke ich, dass schlechte TCP/IP-Prüfsummen die geringste Sorge sein sollten.

Answer 3

Nun, dieses Papier ist von 2000, so ist es von vor langer Zeit (Mann, bin ich alt), und auf einer ziemlich begrenzten Reihe von Spuren. Also nehmen Sie ihre Figuren mit einem großen Körnchen Salz. Allerdings wäre es interessant zu sehen, ob das immer noch so ist. Ich vermute jedoch, dass sich die Dinge geändert haben, obwohl einige Klassen von Fehlern noch gut existieren können, wie zum Beispiel Hardwarefehler.

nützlicher als Prüfsummen, wenn Sie wirklich benötigen die zusätzliche Anwendungsebene Sicherung wäre ein SHA-N-Hash der Daten sein, oder MD5 usw.