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

[Joe Touch <[e-mail]>]

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? 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