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

["Scheffenegger, Richard" <[e-mail]>]

Hi Joe,

I think you mentioned that a checksum violation in TLS will cause the
connection to be aborted - rather than the corrupted packet to be
resent...

If keeping the standard TCP CRC intact (and covering TCP header & data)
and having an RFC1146 alternate checksum that works differently than
defined therein, perhaps it would be better to make it a new TCP option
then.

During handshake, the CRC-32C capable sender would need to do the proper
think (retry one or two times with all options, and then retry with the
minimum options); For agnostic middleboxes (and NAT/PAT routers
currently deployed), not covering the pseudo-header seems to me to be
the only option, to make this feature work with existing gear... 

Again, if the group feels that this is better not called "Alternative
Checksum" (re-using preexisting TCP options), but rather "TCP Stronger
Data Checksum", that's fine :).

The key is to keep the TCP state and retransmission behaviour intact, as
re-negotiating a new, TLS-protected TCP stream after corruption might
not be good enough these days (too high latency impact). 

As there exist HW that implements SCTP checksum offloading (as well as
segmentation) nowadays, new appliactions could probably make use of
that. However, applications would have to revert back to TCP (with small
segments), if the other side wouldn't support SCTP.

Richard Scheffenegger
 

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Donnerstag, 10. Juni 2010 02:46
> To: Scheffenegger, Richard
> Cc: Lars Eggert; [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.
> 
> Some will drop the segment simply because it has an option 
> they don't understand.
> 
> 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.
> 
> 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.
> 
> 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
> 
>