UDPデータペイロードにCRCを含める必要がありますか？

Question

私が働いていた会社の場合、ソケットレシーバーを実装する必要がありました。ソケットレシーバーは、一部の専用センサーハードウェアからローカル接続を介してUDP形式でデータを取得しました。問題のデータは整形式のUDPパケットでしたが、興味深いことに、データペイロードは常に残りのデータを使用して形成されたCRC16チェックサムで終了していました。

私は仕様に従って私の側にチェックを実装しましたが、これが必要かどうか常に疑問に思いました。結局のところ、UDPプロトコル自体に16ビットCRCは含まれていませんか？そのため、UDPパケットは失われたり、順序が乱れたりする可能性がありますが、OSのプロセスに到達する前にネットワークハードウェアによって破棄されなければ破損しないという印象を受けました。または、私が見逃している特別なユースケースはありますか？

私が防衛業界で働いていたのは価値があることだと思いますが、ご想像のとおり、このようなすべてについて非常に露骨になりたいので、それが「セキュリティOCD」の単なる例だったのかと思います。 ..

Philipp · Accepted Answer

DPプロトコルは、メッセージが順番どおりに配信されることやまったく配信されることを保証しませんが、するメッセージが確実に行われるようにします配信は完全に行われ、16ビットのチェックサムを自動的に含めることで変更されません。つまり、アプリケーション層に別の16ビットチェックサムを追加することは、通常冗長です。

...通常....

まず、IPv4（IPv6ではない）では、チェックサムはoptionalです。これは、チェックサムの生成と検証を行わないエキゾチックな構成を使用している可能性があることを意味します（ただし、その場合は、アプリケーションレイヤーでネットワークスタックをジュリーリギングするのではなく、ネットワークスタックを修正する必要があります）。

次に、16ビットのチェックサムでは、完全にランダムなメッセージが偶然に有効なチェックサムを持っている可能性が65536分の1です。このエラーのマージンがユースケースに対して大きすぎる場合（そして、防衛産業では、それがどこにあるか想像できます）、別のCRC-16チェックサムを追加すると、さらに減少します。ただし、その場合は、CRC-16ではなく、SHA-256のような適切なメッセージダイジェストを使用することを検討してください。または、ずっと進んで、実際の暗号署名を使用します。これは、ランダムな破損だけでなく、攻撃者による意図的な破損からも保護します。

3番目に、データの送信元と送信先によっては、ネットワーク経由で送信される前または後に破損する可能性があります。その場合、メッセージ内の追加のチェックサムは、2つのネットワークホスト間だけでなく、メッセージの整合性を保護する可能性があります。

Peter Green · Answer

ただし、UDPはチェックサムを提供します。

UDPチェックサムはわずか16ビットです。これは、破損したパケットがチェックサムを通過する65536分の1の確率を意味します。
uDP over IPv4ではチェックサムはオプションであるため、送信者は理論的にはチェックサムなしでパケットを送信してしまう可能性があります。
チェックサムには、IP /ポート情報とデータが含まれます。これは、破損したアドレスを持つパケットをドロップするのに役立ちますが、パケットがNATを通過する場合、チェックサムはNATによって再計算される必要があることを意味します。
チェックサムは、データがUDPパケットで移動している間のみデータを保護します。アプリケーションレベルのチェックサムは、より複雑なシステムを通過するデータをエンドツーエンドで保護できます。
UDPチェックサムは、パケットがUDP実装によって生成されたことを明確に伝えるだけです。それはあなたのセンサーから来たことを教えてくれません。一方、アプリケーションレベルのチェックサムは、有効なUDPであるが他のソースからのパケットを拒否するのに役立ちます。

したがって、UDPチェックサムを信頼しないが、UDPチェックサムを信頼せず、アプリケーションレベルで同様に弱いチェックサムを実装することの正当な理由を理解できるのは奇妙に思えます。

プロトコルを設計する人は、UDPがチェックサムを提供することを単に知らなかった、またはプロトコルが実際にチェックサムを提供しない媒体上で実行するように設計されたもののわずかな変形である可能性があります。

追伸この投稿にはセキュリティのタグが付けられているため、問題のチェックサムは不注意による変更から保護するように設計されていることに注意してください。意図的な変更またはなりすましから保護するには、意図的な衝突/プリイメージに耐性のある暗号化ハッシュ関数の使用と、ハッシュ自体が変更されていないことを確認するための何らかのメカニズム（公開鍵を使用して作成された署名など）の使用の両方が必要です。