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

[Joe Touch <[e-mail]>]

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