¿Deberían las cargas útiles de datos UDP incluir un CRC?

Para una empresa para la que solía trabajar, tuve que implementar un receptor de socket que tomaba principalmente datos en forma UDP a través de una conexión local desde algún hardware de sensor especializado. Los datos en cuestión eran un paquete UDP bien formado, pero curiosamente, la carga útil de datos siempre terminaba con una suma de verificación CRC16 formada con el resto de los datos.

Implementé el control de mi lado, según las especificaciones, pero siempre me pregunté si esto era necesario. Después de todo, ¿el protocolo UDP no tiene un CRC de 16 bits? Por lo tanto, aunque los paquetes UDP pueden perderse o estar fuera de servicio, tenía la impresión de que no pueden corromperse sin ser descartados por el hardware de la red antes de que lleguen a los procesos del sistema operativo. ¿O hay algún caso de uso especial que me falta?

Vale la pena agregar que estaba trabajando en la industria de la defensa, que como estoy seguro se puede imaginar, le gusta ser súper explícito sobre todo esto, así que me pregunto si fue solo un caso de "OCD de seguridad". ..

El protocolo UDP no garantiza que los mensajes se entregan en orden o entregados en absoluto, pero sí garantiza que los mensajes que no llegan a su destino están completos y sin cambios de forma automática mediante la inclusión de una suma de comprobación de 16 bits. Eso significa que agregar otra suma de verificación de 16 bits en la capa de aplicación suele ser redundante.

...generalmente....

Primero, con IPv4 (no IPv6), la suma de verificación es opcional . Eso significa que puede estar usando una configuración exótica que no genera ni valida la suma de verificación (pero en ese caso, debería arreglar su pila de red en lugar de manipularla con jurado en la capa de aplicación).

En segundo lugar, con una suma de verificación de 16 bits, existe una posibilidad entre 65536 de que un mensaje completamente aleatorio tenga una suma de verificación válida. Cuando este margen de error es demasiado grande para su caso de uso (y en la industria de la defensa podría imaginar varios donde está), agregar otra suma de verificación CRC-16 lo reduciría aún más. Pero en ese caso, podría considerar usar un resumen de mensaje adecuado como SHA-256 en lugar de CRC-16. O vaya hasta el final y use una firma criptográfica real. Esto protege no solo contra la corrupción aleatoria sino también contra la corrupción intencional de un atacante.

En tercer lugar, dependiendo de dónde provienen los datos y hacia dónde van, podrían estar dañados antes o después de ser enviados a través de la red. En ese caso, la suma de verificación adicional dentro del mensaje podría proteger la integridad del mensaje más allá de solo entre los dos hosts de la red.

UDP proporciona una suma de verificación, sin embargo.

1. La suma de comprobación UDP es de solo 16 bits. Eso significa una probabilidad de 1 en 65536 de que un paquete corrupto pase la suma de verificación.
2. en UDP sobre IPv4, la suma de verificación es opcional, por lo que un remitente podría terminar enviando un paquete sin una suma de verificación.
3. La suma de comprobación cubre la información de IP / puerto, así como los datos. Si bien esto es útil para descartar paquetes con direcciones corruptas, significa que si el paquete pasa a través de un NAT, el NAT debe volver a calcular la suma de verificación.
4. La suma de verificación solo protege los datos mientras viaja en el paquete UDP. Una suma de comprobación de nivel de aplicación puede proteger los datos de extremo a extremo a medida que pasan a través de un sistema más complejo.
5. La suma de comprobación UDP solo le dice que el paquete fue generado por una implementación UDP. No te dice que vino de tu sensor. Una suma de comprobación de nivel de aplicación, por otro lado, puede ayudar a rechazar paquetes que son UDP válidos pero provienen de alguna otra fuente.

Por lo tanto, puedo ver razones legítimas para no confiar en la suma de verificación UDP pero igualmente no confiar en la suma de verificación UDP y luego implementar una suma de verificación igualmente débil en el nivel de la aplicación parece extraño.

Existe la posibilidad de que la persona que diseña el protocolo simplemente no supiera que UDP proporcionó sumas de verificación o que el protocolo es en realidad una ligera variante de uno diseñado para ejecutarse en un medio que no proporciona sumas de verificación.

PD: dado que esta publicación tiene etiquetas de seguridad, tenga en cuenta que las sumas de verificación en cuestión están diseñadas para proteger contra cambios involuntarios. La protección contra la modificación deliberada o la suplantación de identidad requiere tanto el uso de funciones hash criptográficas que son resistentes a colisiones / preimpresiones deliberadas como el uso de algún mecanismo (por ejemplo, firmas hechas con una clave pública) para verificar que los hash no hayan sido modificados.