[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CRC Issue in Security Draft
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.
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.
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).
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
------------------------------------------------------------
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.
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.
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).
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
------------------------------------------------------------