RE: CRC Issue in Security Draft

[P.Pillai@Bradford.ac.uk]

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?


> 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.

> 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).
>
> 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).
>
> 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
> ------------------------------------------------------------
>
>
>
>


-- 
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
------------------------------------------------------------