Re: [tcpm] draft-eggert-tcpm-historicize-00

[Joe Touch <[e-mail]>]

Richard,

Scheffenegger, Richard wrote:
> Anantha,
> 
> I think for purposes of documenting "legacy" implementations, the
> RFC1146 would still be valid.
> 
> I will try to define the goal of that recent proposal again, at least as
> far as I understand this, so that we are all on the same page here.
> 
> Our expirience has shown, that TCP often runs over links with much
> higher error rates, than intended for the technology (ie. Design goal of
> BER <= 1E-12 over Ethernet often has an actual BER >> 1E-12). If such
> error-prone links are running at a high speed and with large segment
> sizes (jumbo / giant frames), there exists the real problem that within
> a short timeframe (weeks to months), TCP will deliver corrupted data, as
> CRC-16 was not able to catch the error.

Just to confirm, is this a measured problem or a mathematical one? I.e., have
you seen this actually occur (i.e., TCP with invalid CRC-16 but valid checksum)
in the wild, in a lab, or have you never seen it but consider it important anyway?

> From my point of view, I understood the recent discussions around
> RFC1146 in such a way, that for the intended purpose, which is to
> provide a stronger payload checksum (equivalent to SCTP levels), a new
> option would be required rather than reusing the alternate checksum
> option. The reasoning is that currently deployed gear, especially NAT /
> PAT gateways - which have to re-calculate the TCP Checksum as the
> Pseudo-Header is changed - might know about the originally defined
> alternate checksum algorithms, but not the new ones.

NATs would recalculate the TCP checksum, which, for packets using alternate
checksums as per 1146, would remain valid. The NAT would destroy the alternate
checksum, though, since it is defined by 1146 over the pseudoheader and TCP
header, so any changes to IP addresses or ports would result in an incorrect
alternate checksum unless corrected by the NAT (which is, as you note, unlikely).

So no matter how you proceed, you're better off with RFC 1146's version of how
the existing checksum field is calculated. (your current proposal puts part of
the new checksum in the TCP header field, which the NAT would interpret as
invalid and drop). Which means you're calculating TWO checksums for every packet
- the current one (which the NAT will update), and the new (alternate) one
(which NATs won't/can't update).

> Furthermore, RFC1146 specifically requires the Pseudo Header to be
> included - which one wouldn't want to do if only payload CRC is
> required.

Agreed.

> Providing a Payload-only CRC (ie. as the first TCP option), would enable
> the transparent forwarding of such a new option by NAT/PAT gateways
> without any problems.

TCP options are not ordered. Their processing may be suggested, when defining
how the option interacts with other options, e.g.

> Of course, if RFC1146 could be extended to include algorithms which
> actually "violate" some of the specs of it, but maintain using the same
> TCP options with a new algorithm codepoint, that would be fine with me.

That would involve writing two docs (IMO):
	- one specifying a new algorithm you'd like to use
	- one specifying an alternate way to calculate the alt-cs value
	as a change to RFC1146

These are, in effect, two different issues.

> But this would probably ask for a new RFC obsoliting RFC1146 anyway (in
> effect making it again historic :) ).

It doesn't need to obsolete 1146; it does need to explain how an implementer
knows the difference between just a new algorithm and a different way to compute
it (i.e., over different data bits). That might be by redefining the codes so
that some codes mean "skip the header" and others don't, etc. The group would
need to discuss this as a legacy issue.

An interesting question is why you care that the payload doesn't get
accidentally altered, but you don't care if the port or address does (and you
don't notice), though.

Joe

>> -----Original Message-----
>> From: Anantha Ramaiah (ananth) [mailto:[e-mail]] 
>> Sent: Donnerstag, 24. Juni 2010 20:17
>> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Lars 
>> Eggert; [e-mail]
>> Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
>>
>> I have already communicated earlier that the TCP alternate 
>> checksum option needs to be removed from this list. Reason 
>> being it is still being used and there are proposals out 
>> there that is trying to make use of this option. Other than 
>> that point I am fine with this draft moving forward.
>>
>> -Anantha
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm