[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
答复: CRC Issue in Security Draft
I just want to unsubscribe this user group
Thank you
-----邮件原件-----
发件人: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] 代表
yangming
发送时间: 2006年5月26日 8:46
收件人: ipdvb@erg.abdn.ac.uk
主题: 答复: CRC Issue in Security Draft
-----邮件原件-----
发件人: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] 代表
P.Pillai@Bradford.ac.uk
发送时间: 2006年5月25日 17:09
收件人: H.Cruickshank@surrey.ac.uk
抄送: ipdvb@erg.abdn.ac.uk; 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.
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
--
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
Quoting 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.
>
--
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
------------------------------------------------------------