Subject: RE: CRC Issue in Security Draft

From: <[email-masked]>
Date: Tue, 23 May 2006 17:06:13 +0100

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: [email-masked] on behalf of [email-masked]
Sent: Tue 23/05/2006 12:46
To: [email-masked]
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: [email-masked]
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to [email-masked]
------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 23 May 2006 19:37:08 +0100

Hi Sunny,

See replies inline:

Quoting [email-masked]:

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

---

From: Christian Praehauser <[email-masked]>
Date: Wed, 24 May 2006 08:59:30 +0200

Hello Sunil!

>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 buffe…
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:                                |
|  [email-masked]             |
| Address:                              |
|  Institut fuer Computerwissenschaften |
|  Jakob-Haringer-Strasse 2             |
|  A-5020 Salzburg, Austria             |
|_______________________________________|

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 24 May 2006 19:07:32 +0100

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

>> is provided atleast against bit errors (physical channel).
Yes.

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

---

From: [email-masked]
Date: Thu, 25 May 2006 09:43:38 +0100

Hi Sunny,

I also wanted to ask one more thing- What is the reason to have an encrypted
Type field? What do we need to protect it for?

Regards
Prashant

---

From: [email-masked]
Date: Thu, 25 May 2006 10:09:21 +0100

Hi Haitham,

In my opinion there are two alternatives for the CRC problem: The first is to
replace the CRC completly with the Integrity block. The receivers who are not
configured for security will still use the CRC, while the others that are
configured for security would expect to have an integrity block at the end of
the SNDU instead of the CRC and hence have to just skip the CRC check.
Christian, how feasible do you think this is?

I have another alternate solution for the Secure ULE. I think this could be used
in the combined security draft that we plan to write together.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+----------------------------+------------------------------+
 |D|          Length            |       Type = S-ULE           |
 +-+----------------------------+------------------------------+
 |              Receiver Destination NPA Address *             |
 |                              +------------------------------+
 |                              |      ULE_Security_ID         |
 +------------------------------+-+-+--------------------------+
 |       ULE_Security_ID        |S|A|  Sequence Num.(Optional) |
 +------------------------------+-+-+--------------------------+
 |  Sequence Number (Optional)  |        MAC (Optional)        |
 +------------------------------+------------------------------+
 |        MAC (Optional)        |     Type = Type of PDU       |
 +------------------------------+------------------------------+
 |                                                             |
 |                                                             |
 =                         Encrypted PDU                       =
 |                                                             |
 |                                                             |
 +-------------------------------------------------------------+
 |                    Cyclic Redundancy Code                   |
 +-------------------------------------------------------------+

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+----------------------------+------------------------------+
 |1|      Length (15 bits)      |       Type = S-ULE           |
 +-+----------------------------+------------------------------+
 |                     ULE_Security_ID                         |
 +-+-+---------------------------------------------------------+
 |S|A|                 Sequence Number (Optional)              |
 +-+-+--------------------------+------------------------------+
 |          Message Authentication Code (Optional)             |
 +-------------------------------------------------------------+
 |         Type = IPv4          |                              |
 +------------------------------+                              |
 |                                                             |
 |                                                             |
 =                    Encrypted IP Datagram                    =
 |                                                             |
 |                                                             |
 +-------------------------------------------------------------+
 |                    Cyclic Redundancy Code                   |
 +-------------------------------------------------------------+

The security extension header would be in complete accordance with the RFC 4326.
The processing of the ULE SNDU would also remain the same, and there would be no
violations. When the SNDU is received in the buffer, first the CRC check is
performed and then passed up for the processing of the SNDU.

Two new fields have been added:
S – Set to 1 if Sequence number is present else set to 0
A – Set to 1 of Message Authentication Code (Integrity block) is present

The ULE_secuirity_ID could be used to search the SAD to see if the optional
fields are present or not. But I Prefer to have the two 1-bit fields which
should provide faster processing of the SNDU (less searching from the
database).

The MAC would provide authenticity/integrity for the encrypted block (also for
the sequence number if required).

The processing steps at the transmitter would be:
i) The higher layer PDU is encrypted.
ii) The Encrypted PDU + Sequence Number + Key is used for generation of MAC
iii) Add all fields in the SNDU and then finally calculata the CRC and add it in
the end.

The processing steps at the receiver would be:
i) Perform CRC Check, Discard if mistmatch
ii) ULE SNDU processing starts, sees that it is the mandatory security extension
header, reads the ULE SID
iii) The next two fields can be used to see if the optional sequence number and
MAC are present or not
iv) If Sequence number is present, then it would be verified to prevent replayed
packets
v) Next the MAC is verified to make sure that there has been no modifications to
the PDU
vi) Finally the decryption of the higher layer PDU is done and the PDU is passed
up.

Regards
Prashant

---

From: "yangming" <[email-masked]>
Date: Fri, 26 May 2006 08:45:56 +0800

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
[email-masked]
发送时间: 2006年5月25日 17:09
收件人: [email-masked]
抄送: [email-masked]; Christian Praehauser
主题: Re: CRC Issue in Security Draft

Hi Haitham,

In my opinion there are two alternatives for the CRC problem: The first is
to
replace the CRC completly with the Integrity block. The receivers who are
not
configured for security will still use the CRC, while the others that are
configured for security would expect to have an integrity block at the end
of
the SNDU instead of the CRC and hence have to just skip the CRC check.
Christian, how feasible do you think this is?

I have another alternate solution for the Secure ULE. I think this could be
used
in the combined security draft that we plan to write together.

The security extension header would be in complete accordance with the RFC
4326.
The processing of the ULE SNDU would also remain the same, and there would
be no
violations. When the SNDU is received in the buffer, first the CRC check is
performed and then passed up for the processing of the SNDU.

The MAC would provide authenticity/integrity for the encrypted block (also
for
the sequence number if required).

The processing steps at the transmitter would be:
i) The higher layer PDU is encrypted.
ii) The Encrypted PDU + Sequence Number + Key is used for generation of MAC
iii) Add all fields in the SNDU and then finally calculata the CRC and add
it in
the end.

The processing steps at the receiver would be:
i) Perform CRC Check, Discard if mistmatch
ii) ULE SNDU processing starts, sees that it is the mandatory security
extension
header, reads the ULE SID
iii) The next two fields can be used to see if the optional sequence number
and
MAC are present or not
iv) If Sequence number is present, then it would be verified to prevent
replayed
packets
v) Next the MAC is verified to make sure that there has been no
modifications to
the PDU
vi) Finally the decryption of the higher layer PDU is done and the PDU is
passed
up.

Regards
Prashant

---

From: "yangming" <[email-masked]>
Date: Fri, 26 May 2006 08:53:58 +0800

I just want to unsubscribe this user group 
Thank you

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
yangming
发送时间: 2006年5月26日 8:46
收件人: [email-masked]
主题: 答复: CRC Issue in Security Draft

-----邮件原件-----

Hi Haitham,

Regards
Prashant