Re: CRC Issue in Security Draft

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

On 23/5/06 19:37, "P.Pillai@Bradford.ac.uk" <P.Pillai@Bradford.ac.uk> wrote:

> Hi Sunny,
> 
> See replies inline:
> 
> Quoting S.Iyengar@surrey.ac.uk:
> 
>> Hi Prashant and all,
>> Thanks for your useful comments.
>> 
>> Please find my comments below:
>> 
>> 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.
> 
> Prashant: The security processing should not be done before the CRC check and
> handling of the SNDU. This would violate the normal processing of the ULE SNDU
> and this would not be a standard extension (as you have proposed) as descirbed
> in the ULE RFC. If this is supposed to be a standard header extension (as
> described in Section 5 of RFC 4326) then the processing of the extension
> header
> (in this case the security extension header) should take place only after the
> the CRC check. Gorry, am I correct in saying this?
> 
Gorry: Extension headers do not impact the CRC-32. It therefore seems most
desirable to use a security format that preserves the ULE framing and CRC
usage that was defined in RFC 4326.
> 
>> 2) In case of having the cryptographic integrity block, I agree that the CRC
>> field becomes redundant whether it is encrypted or not. Because they both are
>> doing the same thing but with more assurance in the cryptographic case
>> (better anti collision properties). But the downside of this is more
>> complexity.
> 
> Prashant: The integrity block may increase complexity but there is definitely
> no use to have them both.
> 
I'd like to see the integrity requirements expressed clearer in the
requirements I-D. 

>> 3) If only encryption is done on the packet then I agree with you that the
>> CRC needs to be after the encryption block , so that some level of integrity
>> is provided atleast against bit errors (physical channel).
>> 
Yes.

>> 4) The other option could be and this is addressed to the group to have a
>> choice between the CRC or additional integrity block (if needed).
> 
> Prashant: This is what I had proposed in my
> draft(draft-ppillai-ipdvb-sule-00.txt). But you have to be careful as you have
> proposed that the integrity block is optional. And also removing the CRC
> modifies the recevier processing of the SNDU as explanined in my draft. And
> this would not be a standard extension header.
> 
>> 5) I agree that the CRC should be after the encryption block, but may be
>> redundant if using stronger cryptographic checksums.(MD5 , SHA-1).
>> 
Do we need a stronger check than a CRC-32 at the link layer? - there seems
to be a trade-off between overhead and strength of check.

>> Regards
>> Sunny
>> 
>> ***********************************************************
>> Sunil Iyengar,
>> Research Fellow, Networks Group,
>> Centre For Communication And Systems Research(CCSR),
>> School of Electronics, Computing & Mathematics,
>> University Of Surrey, Guildford GU2 7XH,
>> Surrey, England, United Kingdom.
>> Office: +44 (0)1483 686008
>> ***********************************************************
>> 
>> 
>> ________________________________
>> 
>> From: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk
>> Sent: Tue 23/05/2006 12:46
>> To: ipdvb@erg.abdn.ac.uk
>> Subject: CRC Issue in Security Draft
>> 
>> 
>> 
>> Hi Haitham and Sunny,
>> 
>> I have a few questions regarding your security
>> draft(draft-cruickshank-ipdvb-sec-01.txt):
>> 
>> 1) I am not sure as to what is the main reason for encrypting the entire PDU
>> including the checksum as indicated by the draft on Page 4? As indicated in
>> the
>> RFC4326, section 7.2 the receiver should be able validate the CRC as soon as
>> it
>> gets the complete SNDU in the buffer. I do not think that encrypting of this
>> CRC is a good idea, as this would violate the standard processing of the ULE
>> SNDU, where it would be have to skip this CRC check and first perform
>> decryption of the packets and then come back and perform the CRC check.
>> (Hence
>> it can no longer be just an extension header for ULE, as the processing has
>> changed)
>> 
>> 2) Even if the CRC is not encrypted, another major conflict in the SNDU
>> format
>> is the presence of the integrity block after your CRC. At the receiver side
>> as
>> indicated in the RFC4326, section 7.2 the receiver should be able validate
>> the
>> CRC as soon as it gets the complete SNDU in the buffer. At this stage the
>> ideal
>> working of the receiver (for standard ULE) is to take the last 32 bits which
>> would be the CRC and perform the CRC check. But now the CRC is not at the end
>> and it may be difficult to extract the CRC from the SNDU especially because
>> the
>> integrity block has not shown to have fixed size.
>> 
>> 3) Also it is not clear why is the CRC required when the integrity block is
>> present. The integrity block would be using much complex algorithms like
>> HMACs
>> etc to detect if there is any change in the transmitted data and the received
>> data. This change could have resulted by an attacker modifying the message or
>> could have also been due to transmission/processing errors. In either case
>> the
>> packets should be discarded. So does this not mean that the CRC is only
>> duplicating the work and may not be really required when we have a stronger
>> integrity block?
>> 
>> Regards
>> Prashant
>> 
>> 
>> --
>> Prashant Pillai
>> Research Assistant
>> School of Engineering, Design and Technology
>> University of Bradford
>> Bradford, BD7 1DP
>> West Yorkshire
>> United Kingdom
>> Phone: 0044-1274-233720
>> email: p.pillai@bradford.ac.uk
>> ------------------------------------------------------------
>> This mail sent through IMP: http://webmail.brad.ac.uk
>> To report misuse from this email address forward the message
>> and full headers to misuse@bradford.ac.uk
>> ------------------------------------------------------------
>> 
>> 
>> 
>> 
>