Re: [tcpm] draft-anumita-tcpm-stronger-checksum

["Biswas, Anumita" <[e-mail]>]

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Wednesday, June 09, 2010 5:46 PM
> To: Scheffenegger, Richard
> Cc: [e-mail]; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
> 
> 
> Some notes below...
> 
> Scheffenegger, Richard wrote:
> > To further this discussion:
> > 
> > I believe the suggestion using Alternate Checksum Option has the 
> > highest
> > merits:
> > 
> > O) no new tcp option number would be needed
> > O) only an additional checksum option type would need to be defined 
> > (and there are still plenty left; I found no evidence so 
> far, that any 
> > other value than 0 and 1 were ever used - scanning though the I-D 
> > archives).
> > 
> > To make this proposal compatible with existing middleboxes, which 
> > might not understand the option, but choose to simply 
> forward it, my 
> > suggestion would be to *NOT* include the TCP pseudo-header in that 
> > alternate checksum, but *only* cover the data section. This 
> would make 
> > it also possible to traverse NAT/PAT gateways, which are 
> agnostic to 
> > this option.
> 
> Middleboxes will be a problem no matter what you do.
> 
If middleboxes are not RFC compliant, then yes.

> Some will drop the segment simply because it has an option 
> they don't understand.
> 
I guess our goal is not to solve the problem for workaround middleboxes
that do not follow RFC 1122 interoperability mandate in 4.2.2.5. 

I am more worried about the bigger problem of losing data integrity for
packet MTUs greater than 1500. Today we are storing peta bytes of data
in a single storage bin. Imagine copying peta bytes of data over the
network to that bin. The likelihood of bit errors going undetected just
increased probably by many magnitudes. 

The other day I was listening to someone from probably the most largest
software company talk about copying data over the network and seeing bit
corruptions going unnoticed. Bit corruptions will go unnoticed when you
send a large amount of data on the wire. This Internet Draft is just a
small beginning in improving the rate of error detection. 

Also, the cost of costly cryptographic operations have to be weighed
against simpler CRC checksum algorithms that are already offloaded to
modern NICs for SCTP. If we standardize the CRC-32C for TCP, then NIC
vendors can offload them to newer versions of NICs and we get rid of the
in-software computations.

> Some will drop the option, which will result in drops at the receiver.
> 
> Many (most) will try to validate the TCP checksum, which is 
> zero or contains part of the alternate checksum when the 
> alternate checksum is present, so they'll drop the segment in 
> that case.
> 
> As a result, it's not particularly useful to tailor this 
> option to work through middleboxes.
> 
> Further, RFC 1146 defines the option to work over the same 
> fields as the TCP checksum; I don't think it would be 
> appropriate to use that option with merely a different 
> algorithm and redefine the bits covered.
>
Agreed. 
 
> Finally, if the TCP header isn't protected, it's no longer a 
> TCP checksum - it's a data checksum, at which point TLS is 
> probably more appropriate.
> 
Based on comments I received from Richard Scheffenegger offline, we have
to continue to put in the summation based 16-bit checksum in the TCP
header so that we don't break the existing standard of what the TCP
checksum is expected to be. 

However, I am a bit skeptical about the comment that the 16-bit
summation based checksum is adequate to pass off as protecting the TCP
header. In theory it does protect the TCP header, but in practice, when
the checksum spans MTU sizes larger than 1500 bytes, it is not going to
catch the random bit flip in the sequence number, ack number etc.
Instead, the draft proposes a stronger tcp checksum  

The draft also only debates over whether the psuedoheader must be added
to the TCP checksum. But it states that the TCP header + Data must be
included in the CRC 32C checksum.

Again, these are details that can be worked out if the WG thinks that
this draft is worth taking up by the WG for further consideration. 

> I don't think the other suggestions (two checksums, issues of 
> how many bits are covered, etc.) are important. If the above 
> doesn't work, the rest is moot anyway.


> 
> Joe
> 
>