I payload dei dati UDP dovrebbero includere un CRC?

Il protocollo UDP non garantisce che i messaggi siano consegnati in ordine o consegnati a tutti, ma garantisce che quelli i messaggi che fanno vengono consegnati sono completi e invariati includendo automaticamente un checksum a 16 bit. Ciò significa che l'aggiunta di un altro checksum a 16 bit sul livello dell'applicazione è solitamente ridondante.

... di solito ....

Innanzitutto, con IPv4 (non IPv6), il checksum è opzionale . Ciò significa che potresti utilizzare una configurazione esotica che non esegue la generazione e la convalida del checksum (ma in tal caso dovresti piuttosto aggiustare lo stack di rete invece di applicare questa opzione sul livello dell'applicazione).

In secondo luogo, con un checksum a 16 bit c'è una probabilità su 65536 che un messaggio completamente casuale abbia un checksum valido. Quando questo margine di errore è troppo grande per il vostro caso d'uso (e nel settore della difesa potrei immaginarne diversi dov'è), aggiungendo un altro checksum CRC-16 lo ridurrebbe ulteriormente. Ma in tal caso potresti prendere in considerazione l'utilizzo di un messaggio digest appropriato come SHA-256 anziché CRC-16. O andare fino in fondo e utilizzare una vera firma crittografica. Questo protegge non solo dalla corruzione casuale ma anche dalla corruzione intenzionale da parte di un utente malintenzionato.

In terzo luogo, a seconda di dove provengono i dati e dove si trova, potrebbe essere danneggiato prima o dopo essere stato inviato in rete. In tal caso, il checksum addizionale all'interno del messaggio potrebbe proteggere l'integrità del messaggio più che solo tra i due host di rete.

UDP fornisce comunque un checksum.

1. Il checksum UDP è solo a 16 bit. Ciò significa 1 su 65536 possibilità di un pacchetto corrotto che passa il checksum.
2. in UDP su IPv4 il checksum è facoltativo, quindi un mittente potrebbe teoricamente finire per inviare un pacchetto senza checksum.
3. Il checksum copre le informazioni IP / porto e i dati. Sebbene ciò sia utile per far cadere pacchetti con indirizzi corrotti, significa che se il pacchetto passa attraverso un NAT, il checksum deve essere ricalcolato dal NAT.
4. Il checksum protegge solo i dati mentre viaggia nel pacchetto UDP. Un checksum del livello dell'applicazione può proteggere i dati end-to-end mentre passa attraverso un sistema più complesso.
5. Il checksum UDP mostra solo che il pacchetto è stato generato da un'implementazione UDP. Non ti dice che proviene dal tuo sensore. Dall'altro lato, un checksum del livello dell'applicazione può aiutare a rifiutare pacchetti che sono UDP validi ma provengono da un'altra fonte.

Quindi posso vedere motivi legittimi per non fidarsi del checksum UDP ma ugualmente non fidarmi del checksum UDP e quindi implementare un checksum altrettanto debole a livello di applicazione sembra strano.

C'è la possibilità che la persona che desinging il protocollo semplicemente non sappia che UDP ha fornito checksum o che il protocollo è in realtà una leggera variante di uno progettato per funzionare su un supporto che non ha fornito checksum.

P.S. dal momento che questo post è contrassegnato dalla sicurezza, sii consapevole che i checksum in questione sono progettati per proteggere da modifiche involontarie. La protezione da modifiche intenzionali o spoofing richiede sia l'uso di funzioni hash crittografiche che resistono a collisioni / preimmagini intenzionali e l'uso di alcuni meccanismi (ad es. Firme fatte usando una chiave pubblica) per verificare che gli hash stessi non siano stati modificati.