I payload di dati UDP dovrebbero includere un CRC?

Per un'azienda per cui lavoravo, dovevo implementare un ricevitore socket che prendeva principalmente dati in formato UDP su una connessione locale da un hardware di sensori specializzato. I dati in questione erano un pacchetto UDP ben formato, ma è interessante notare che il payload dei dati finiva sempre con un checksum CRC16 formato utilizzando il resto dei dati.

Ho implementato il controllo da parte mia, come da specifica, ma mi sono sempre chiesto se fosse necessario. Dopotutto, il protocollo UDP stesso non trasporta un CRC a 16 bit? Pertanto, sebbene i pacchetti UDP possano essere persi o fuori servizio, ho avuto l'impressione che non possano essere danneggiati senza essere scartati dall'hardware di rete prima che raggiungano i processi del sistema operativo. O c'è qualche caso d'uso speciale che mi manca?

Vale la pena aggiungere che stavo lavorando nel settore della difesa, che, come sono sicuro che puoi immaginare, ama essere molto esplicito su tutto questo, quindi mi chiedo se si trattasse solo di un "OCD di sicurezza". ..

Il protocollo UDP non garantisce che i messaggi vengono consegnati in ordine o consegnate a tutti, ma lo fa in modo che quei messaggi che non vengano consegnati sono completi e invariati includendo automaticamente a 16 bit di checksum. Ciò significa che l'aggiunta di un altro checksum a 16 bit sul livello dell'applicazione è in genere ridondante.

...generalmente....

Innanzitutto, con IPv4 (non IPv6), il checksum è facoltativo . Ciò significa che potresti utilizzare una configurazione esotica che non esegue la generazione e la convalida del checksum (ma in tal caso dovresti piuttosto sistemare lo stack di rete anziché rigging della giuria a livello di applicazione).

In secondo luogo, con un checksum a 16 bit esiste uno su 65536 possibilità che un messaggio completamente casuale abbia un checksum valido. Quando questo margine di errore è troppo grande per il tuo caso d'uso (e nel settore della difesa potrei immaginarne diversi dov'è), l'aggiunta di un altro checksum CRC-16 lo ridurrebbe ulteriormente. Ma in quel caso potresti considerare di utilizzare un digest di messaggio appropriato come SHA-256 invece di CRC-16. Oppure vai fino in fondo e usa una vera firma crittografica. Questo protegge non solo dalla corruzione casuale ma anche dalla corruzione intenzionale di un utente malintenzionato.

Terzo, a seconda della provenienza e della destinazione dei dati, potrebbe essere danneggiato prima o dopo l'invio sulla rete. In tal caso, il checksum aggiuntivo all'interno del messaggio potrebbe proteggere l'integrità del messaggio oltre che tra i due host di rete.

UDP fornisce comunque un checksum.

1. Il checksum UDP ha solo 16 bit. Ciò significa che 1 su 65536 possibilità che un pacchetto corrotto passi 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 / porta e i dati. Sebbene ciò sia utile nel 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 i dati solo quando viaggiano nel pacchetto UDP. Un checksum a livello di applicazione può proteggere i dati end-to-end mentre passa attraverso un sistema più complesso.
5. Il checksum UDP dice chiaramente che il pacchetto è stato generato da un'implementazione UDP. Non ti dice che proviene dal tuo sensore. Un checksum a livello di applicazione, d'altra parte, può aiutare a rifiutare i pacchetti che sono UDP validi ma provengono da qualche altra fonte.

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

Esiste la possibilità che la persona che sta progettando il protocollo semplicemente non sapesse che UDP forniva checksum o che il protocollo fosse in realtà una leggera variante di uno progettato per funzionare su un supporto che non forniva checksum.

PS poiché questo post è etichettato come security, tieni presente che i checksum in questione sono progettati per proteggere da modifiche involontarie. La protezione da modifiche o spoofing deliberati richiede sia l'uso di funzioni crittografiche di hash resistenti a collisioni / preimmagini deliberate sia l'uso di alcuni meccanismi (ad es. Firme realizzate con una chiave pubblica) per verificare che gli hash stessi non siano stati modificati.