Subject: [Tsvwg] RE: SCTP Data Integrity

From: Tuexen Michael <[email-masked]>
Date: Wed, 11 Jul 2001 09:36:55 +0200

Hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii,

this topic should be discussed on the tsvwg list. Therefore I CCed it.
see my comments below.
Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Jim Hughes [SMTP:[email-masked]]
> Sent:	Wednesday, July 11, 2001 5:08 AM
> To:	sigtran
> Subject:	SCTP Data Integrity
> 
> SCTP data integrity.  
>    
>    This note is a general comment on the "SCTP Checksum Change"
>    document to suggest the possibility of using a chained hash instead of
>    a 32 bit CRC.
> 
>    A chained hash algorithm (SHA-1) will
> 
>    1. Significantly increase the reliability of the transfer.
>    2. without significantly increasing the computing cost on current 
>       commodity processors.
>    3. Only slightly increasing the packet size (by less than 0.1% for
>       2k packet size).
	[Tuexen Michael]  Well, let us thinking about signalling 
	transport. Message size 22 bytes:
	Overhead with CRC:   12 bytes (common header) + 16 byte (data chunk overhead)

	This increases the packet size by a 20 / 50 = 40%. That is significantly.
>  
>    4. Retain the ability to check the reliability of each packet.
> 
	[Tuexen Michael]  If I understand you right, you need all packets with
	smaller TSN to verify that a packet is correct? Than you have to choices:
	1. Deliver it to the user without having it checked.
	2. Wait until you have all packets to be able to do the check.
	Solution 1, for me is unacceptable, and knowing that some of the packets
	are not checked and not knowing which one the checkes are useless. So it
	would be better to do no checking.
	Solution 2 is for me unacceptable, too. This introduces head of line
	blocking and the usage of streams becomes useless. 
>    5. Allow a complete check of the entire transfer.
	[Tuexen Michael]  What is "an entire transfer"? In signalling transport
	an association will be established for a long time. And knowing at the end
	that some packets were wrong does not help.
>    6. Allow a signature to be sent after session is complete to
>       non-reputably authenticate and integrity check the entire session
>       without the need for any key exchange or shared secrets of any
>       kind.
>    7. Works with multicast streams
	[Tuexen Michael]  Does SCTP support mulitcast?
>    8. Allow packet and session integrity of the entire session to be
>       checked by intervening nodes (firewalls) allowing covert channels
>       auditing after the session is complete without preestablished
>       secrets. 
>    9. Can be done after encoding the transmission for confidentiality.
	[Tuexen Michael]  If you really need SHA-1 I would suggest to use TLS/SCTP with NULL encryption and NULL compression and SHA as MAC. See
	http://www.ietf.org/internet-drafts/draft-tuexen-tsvwg-tls-over-sctp-00.txt 

> INCREASING THE RELIABILITY
> 
>    Considering the lifetime of a standard like SCTP, one must pay
>    attention to the assumptions made in the standard, and this note
>    argues, among other things, that a 32 bit CRC (actually a 32 bit
>    anything) is not enough. 
	[Tuexen Michael]  This is being discussed on the tsvwg list. 
>    If one estimates the number of packets that are transfered on the 
>    Internet, the number will be staggering.
>    
>    Assuming 10 years from now and there are 10 million (10e7) GbE
>    links (10e9) operating at 10% duty cycle(10e-1), this is 10e15 bits
>    per second. Assuming 10e-9 bit error rate, this is one MILLION
>    (10e6) errors per second.
> 
>    The characteristic of these errors is an important point. If these
>    are all 1 bit errors, they will all be detected even if we are using a> 
>    checksum, but we know that this is not the case. If we take the> 
>    opposite assumption that each of these errors has a hamming weight
>    larger than the CRC, then the probability of the CRC not detecting the
>    error is roughly one in 4x10e9.
> 
>    This calculates to an undetected error every 4000 seconds or about
>    20 undetected data corruption events per day or 7,000 undetected
>    data corruption events on the Internet per year using the proposed 
>    32 bit CRC. 
> 
>    Considering that these events will be undetected and, if they occur
>    in file transfers, these files will be stored and potentially
>    replicated with these errors. These, arguably, have grave dangers. 
> 
>    Given the place that we are at in deciding what kinds of protection
>    will be available, I believe we should choose something longer (and
>    potentially stronger).
> 
> SMALL INCREASE IN COMPUTING COST
> 
>    In general CRC in software and hash algorithms have OOM similar
>    computing requirements. In general, on a current commodity
>    processor, CRC and SHA1 both require about 1 instruction per byte. 
> 
>    While SHA1 and CRC are similar in software, SHA1 requires
>    significantly more transistors. Given Moore's law, this not
>    significant. 
> 
> SLIGHT INCREASE IN PACKET SIZE
> 
>    SHA1 requires 20 bytes in each packet, compared to 4 bytes for
>    CRC32. The increase is 16/2048. 
> 
> CHECK INDIVIDUAL PACKETS
> 
>    If packet n is P_n and the hash of packet n is H_n, this is calculated by
> 
>         H_n = SHA[H_(n-1),P_n]
> 
>    That is, when a packet is received, H_n can be checked and if
>    the previous packet is known, then you can calculate if this packet
>    is correct. 
> 
>    This does require that the packets be processed in order for this
>    to work. 
> 
> COMPLETE CHECK OF THE ENTIRE TRANSFER
> 
>    If the session is p packets long, if H_p is correct, all previous
>    packets and the reassembly are correct. 
> 
> SIGNATURE OF ENTIRE SESSION IS POSSIBLE
> 
>    Transferring a signature is possible. 
> 
>    A key ingredient in a signature starts with a hash of the entire
>    object to be signed. H_p meets this requirement. It is possible to
>    sign H_p and thus sign the entire session. 
> 
>    Since the hash of a file for signature does not require a key (ala
>    HMAC), then the simple unkeyed SHA1 is all that is needed and the
>    signature can be added at the end. 
> 
> MULTICAST
> 
>    Since there are no prekey, if this is a multicast, signatures are
>    possible. All the end points need is the public key of the source. 
> 
> CHECKING BY INTERMEDIATE NODES
> 
>    In certain cases, it is important that data be known to be
>    authentic before it is let in or out of certain networks. Since
>    anyone can check SHA1 and Signatures (as well as CRCs) intermediate
>    nodes can check this information. 
> 
>    Significantly different than IP-SEC, this does not require any
>    shared secret pre-keying (IKE) of the endpoints.
> 
> CAN BE ADDED AFTER CONFIDENTIALITY
> 
>    Since the data is opaque to SCTP, if the data is encrypted before
>    being transmitted, the addition of SHA1 and signature does not 
>    change this fact. 
> 
> 
> CONCLUSION
> 
>    Adding SHA1 instead of CRC increases reliability and allows
>    signatures of the entire transfer. This change allows PGP like
>    integrity to be possible for any application without the need 
>    for pre encoding the data and post processing the data. 
> 
>    This requires little additional resources and provides more than 10
>    orders of magnitude improvement in data reliability. 
> 
> 
> 
> Certainly, comments are welcome. 
> 
> Thanks
> 
> jim
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 11 Jul 2001 10:04:37 -0400

At 07:30 11/07/01, Jim Hughes wrote:
>Are there other uses for SCTP?

        Yes, it is intended to be a general-purpose transport
protocol, just like UDP or TCP.  It is not limited to either
storage applications or telephony signalling (e.g. SS7) applications.

>My proposal still stands. Per packet integrity larger than CRC32 
>would be valuable.

        SHA-1 or some other keyed hash would obviously be a performance 
killer.  TCP hasless than CRC-32 and has worked fine for many many years.

Ran

---

From: Jim Hughes <[email-masked]>
Date: Wed, 11 Jul 2001 07:30:32 -0400

I will copy both lists on this one, but all subsequent followup will be to
[email-masked] only.

> 	2. Wait until you have all packets to be able to do the check.

Wait until you have all previous packets. 

Alternatively one can accumulate individual per packet hashes...

> 	blocking and the usage of streams becomes useless. 

"head of line blockage", do you mean reliable ordering?

Is this better than TLS? TLS does not give you any information about the
quality of the stream until it is complete?

The majority of applications process information in order.
These applications will not be a problem. If they do not process in
order, but create a ordered "thing" at the end of the transfer, then
this is OK too.

There have been many corruption events where the failure
has been with the reliable ordering mechanism, that is received
correctly and mis-ordered in the delivery to the application. 

> 	that some packets were wrong does not help.

The majority of data corruption events occur because of random
issues, not "man in the middle" attacks. Getting immediate per packet
indication of a random data corruption event is valuable.

Another (optional) indication of the authenticity of the complete long
time association is also valuable (consider a file transfer). 

> 	http://www.ietf.org/internet-drafts/draft-tuexen-tsvwg-tls-over-sctp-00.txt 

TLS certainly works for an indication after the entire transfer of
integrity and authenticity.

My proposal still stands. Per packet integrity larger than CRC32 would
be valuable.

Thanks. 

jim