Subject: [Tsvwg] RE: SCTP Data Integrity

From: Tuexen Michael <[email-masked]>
Date: Wed, 11 Jul 2001 15:44:47 +0200

Dear all,
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 1:31 PM
> To:	Tuexen Michael
> Cc:	[email-masked]'; [email-masked]; 'Jim Hughes'
> Subject:	Re: SCTP Data Integrity
> 
> I will copy both lists on this one, but all subsequent followup will be to
> [email-masked] only.
> 
> On Wed, Jul 11, 2001 at 09:36:55AM +0200, Tuexen Michael wrote:
> > 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.
> 
> Are there other uses for SCTP?
	[Tuexen Michael]  Of course, there are. And some of them
	might need 20 Bytes of checksum/CRC. My point is that no ALL
	of them need it (in my understanding) and some of the users
	are teh adapatation layers of SIGTRAN. They do not need it.  
> > >  
> > >    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.
> 
> Wait until you have all previous packets.  
	[Tuexen Michael]  This is not acceptable. This makes streams
	(and the out of order delivery option) useless. 

> Alternatively one can accumulate individual per packet hashes...
> 
> > 	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. 
> 
> "head of line blockage", do you mean reliable ordering?
	[Tuexen Michael]  SCTP supports multiple streams. Userdata is
	delivered in sequence only within each stream. So DATA chunks 
	belonging to different streams are dilivered to the user without
	waiting for each other.

> Is this better than TLS? TLS does not give you any information about the
> quality of the stream until it is complete?
	[Tuexen Michael]  Well, I only mean that you can use TLS/SCTP
	to provide a SHA-1 checksum per DATA chunk. Generally speacking,
	it is up to the ULP.  
> 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.
	[Tuexen Michael]  What you are saying is that your solution
	works for all applications which make no use of the multiple 
	streams feature of SCTP. But you should not disallow this feature.
	It is a fundamental feature of SCTP.

> 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. 
> 
	[Tuexen Michael]  Well, if your SCTP implementation is buggy
	you have a problem.
> > >    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.
> 
> 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.
	[Tuexen Michael]  This is what you get with a normal checksum. 
> Another (optional) indication of the authenticity of the complete long
> time association is also valuable (consider a file transfer). 
> 
> > >    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 
> 
> 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.
	[Tuexen Michael]  This is something different that you proposed.
	You described a solution were you not only have longer CRC but require
	the in sequence processing of all SCTP packets.
	BTW: How will you make sure that the SCTP control chunks and the DATA
	chunks are in the right sequence? You could use the TSN for DATA chunks
	but the control chunks have no sequence numbers.  
> Thanks. 
> jim

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