Должны ли данные полезной нагрузки UDP включать CRC?

Для компании, в которой я работал, мне пришлось реализовать сокет-приемник, который в основном принимал данные в виде UDP по локальному соединению от некоторого специализированного сенсорного оборудования. Данные данные представляли собой правильно сформированный пакет UDP, но, что интересно, полезная нагрузка данных всегда заканчивалась контрольной суммой CRC16, сформированной с использованием остальных данных.

Я реализовал проверку на своем конце, согласно спецификации, но я всегда задавался вопросом, было ли это необходимо. В конце концов, сам протокол UDP не несет 16-битный CRC? Поэтому, хотя UDP-пакеты могут быть потеряны или вышли из строя, у меня сложилось впечатление, что они не могут быть повреждены без их удаления сетевым оборудованием до того, как они достигнут процессов ОС. Или я пропускаю какой-то особый вариант использования?

Стоит добавить, что я работал в оборонной промышленности, которая, как я уверен, вы можете себе представить, любит быть сверхъестественной во всем, как это, поэтому мне интересно, был ли это случай «безопасности OCD». ..

Протокол UDP не гарантирует, что сообщения доставляются в порядке или доставлены вообще, но он гарантирует, что те сообщения, которые действительно доставлены, являются полными и неизменными, автоматически включая 16-битную контрольную сумму. Это означает, что добавление еще одной 16-битной контрольной суммы на прикладном уровне обычно является излишним.

...обычно....

Во-первых, для IPv4 (не для IPv6) контрольная сумма является необязательной . Это означает, что вы можете использовать экзотическую конфигурацию, которая не выполняет генерацию и проверку контрольных сумм (но в этом случае вы должны скорее исправить свой сетевой стек, чем настраивать его на уровне приложения).

Во-вторых, с 16-битной контрольной суммой есть вероятность того, что абсолютно случайное сообщение с допустимой контрольной суммой будет иметь 65536 вероятностей. Когда этот предел погрешности слишком велик для вашего варианта использования (а в оборонной промышленности я мог бы представить несколько, где он есть), добавление еще одной контрольной суммы CRC-16 еще больше уменьшит ее. Но в этом случае вы можете рассмотреть возможность использования правильного дайджеста сообщений, такого как SHA-256 вместо CRC-16. Или пройти весь путь и использовать настоящую криптографическую подпись. Это защищает не только от случайной коррупции, но и от преднамеренной коррупции со стороны злоумышленника.

В-третьих, в зависимости от того, откуда поступают данные и куда они направляются, они могут быть повреждены до или после отправки по сети. В этом случае дополнительная контрольная сумма внутри сообщения может защитить целостность сообщения дальше, чем просто между двумя сетевыми узлами.

Однако UDP предоставляет контрольную сумму.

1. Контрольная сумма UDP составляет всего 16 бит. Это означает 1 из 65536 вероятности того, что поврежденный пакет пройдет контрольную сумму.
2. в UDP через IPv4 контрольная сумма является необязательной, поэтому теоретически отправитель может в конечном итоге отправить пакет без контрольной суммы.
3. Контрольная сумма охватывает информацию об IP / порте, а также данные. Хотя это полезно при отбрасывании пакетов с поврежденными адресами, это означает, что, если пакет проходит через NAT, контрольная сумма должна быть пересчитана NAT.
4. Контрольная сумма защищает данные только во время их перемещения в пакете UDP. Контрольная сумма уровня приложения может защитить данные от начала до конца, когда они проходят через более сложную систему.
5. Контрольная сумма UDP очищает только то, что пакет был сгенерирован реализацией UDP. Это не говорит вам, что это произошло от вашего датчика. С другой стороны, контрольная сумма уровня приложения может помочь отклонить пакеты, которые являются действительными UDP, но получены из какого-то другого источника.

Таким образом, я вижу законные причины не доверять контрольной сумме UDP, но в равной степени не доверять контрольной сумме UDP, а затем реализовать аналогичную слабую контрольную сумму на уровне приложения, кажется странным.

Существует вероятность того, что человек, разрабатывающий протокол, просто не знал, что UDP предоставил контрольные суммы, или что протокол на самом деле является небольшим вариантом протокола, разработанного для работы на носителе, который не предоставляет контрольные суммы.

PS, так как этот пост помечен системой безопасности, имейте в виду, что рассматриваемые контрольные суммы предназначены для защиты от непреднамеренных изменений. Защита от преднамеренного изменения или подмены требует как использования криптографических хеш-функций, устойчивых к преднамеренным коллизиям / прообразам, так и использования некоторого механизма (например, подписи, сделанного с использованием открытого ключа) для проверки того, что сами хеши не были изменены.