Re: CRC Issue in Security Draft

[Christian Praehauser <cpraehaus@cosy.sbg.ac.at>]

Hello Sunil!

S.Iyengar@surrey.ac.uk wrote:

> 1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide bit errors and integrity protection. And the receiver should first check CRC before it gets the complete SNDU in the buffer.  But once the security processing is done, at the receiver side the security process should be done first and then handle the SNDU.
>  
The CRC also protects all extension headers, so it should be verified 
before inspecting/processing any extension headers.
If you do not generate ULE SNDUs following the general format, you will 
get lots of ugly CRC errors at non-ULE-security-aware receivers.

Repeating the question from Prashant:
What is the reason for encrypting the whole SNDU including the CRC32?

Is it a check if decryption was successful, thus avoiding to get wrong 
data up the receiver stack, e.g. if the transmitter/receiver keys are 
out of sync?

Cheers,
Christian.

--
________________________________________
| Christian Praehauser                  |
|---------------------------------------|
| Email:                                |
|  cpraehaus@cosy.sbg.ac.at             |
| Address:                              |
|  Institut fuer Computerwissenschaften |
|  Jakob-Haringer-Strasse 2             |
|  A-5020 Salzburg, Austria             |
|_______________________________________|