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

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

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Thursday, June 10, 2010 6:54 AM
> To: Scheffenegger, Richard
> Cc: [e-mail]; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
> 
> 
> Hi, Richard,
> 
> Scheffenegger, Richard wrote:
> > 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...
> 
> Yes - TLS operates at the application layer, not in 
> conjunction with TCP.
> 
> > 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.
> 
> Defined therein where? 
http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/

Section 3 - "Negotiating the use of CRC 32C"

The alternate checksum isn't TLS; TLS 
> is an application-layer security protocol.
> 
> > 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...
> 
> RFC1146 defines a handshake behavior, during which only a 
> short label is exchanged and confirmed, and the conventional 
> TCP checksum is used. This is more appropriate for TCP; 
> options in the SYN should not render the rest of the SYN 
> unintelligible to parties that don't support the option.
> 
> As to retry with or without options, that is not typically 
> defined at the level of a TCP option. That too is application 
> behavior - i.e., to try to open a TCP connection with certain 
> parameters, and to try a different attempt if the first 
> fails. Having an option redefine core TCP protocol behavior 
> (such as timeouts, retries, etc.) seems more than just an 
> option. Options should extend, not redefine, that core behavior.
> 
> ...
> > 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.
> 
> Yes. But that's what you've described above when the TCP 
> handshake fails - i.e., that's no different. It's worth 
> thinking further about that, as a result.
> 
> Joe
> 
>