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

[Joe Touch <[e-mail]>]

[e-mail] wrote:
> On 26 Jun 2010, at 20:25, Joe Touch wrote:
>> The only way a packet is accepted erroneously at a receiver, but would cause an
>> problem, would be:
>> 	link check OK
>> 	TCP (1s compl) checksum OK
>> 	new checksum FAIL
>>
>> I.e., the only reason a new TCP checksum would be useful is in this case. If
>> either of the link or existing TCP checks succeed, there's no new problem.
> 
> An example of that scenario is an echo server:
> http://en.wikipedia.org/wiki/Echo_protocol
> http://www.faqs.org/rfcs/rfc862.html

This RFC defines TCP and UDP echo services. Both loop data back to the source,
but at "layer 7" to the transport protocols. Both create new transport packets
to send data back - in fact, the TCP variant might have different segment
boundaries, e.g., if the return path MTU is different. Both thus compute a new
transport checksum, so errors in either would not be detected by a stronger
transport checksum per se.

> http://www.faqs.org/rfcs/rfc2075.html
> 
> which swaps source and destination addresses. These are covered by the pseudo-header
> check; 
...
> A stronger TCP checksum would detect this modification, and have to be
> recomputed. much as payload checksums are recomputed through NAT boxes.

The pseudoheader is not covered by the current proposal, specifically to support
NAT traversal. Any device that recomputes the checksum on traversal (explicitly,
or because that calculation is buried in the NIC and done automatically) will
defeat the ability of the checksum to detect errors inside that node.

The only L7-L7 protection would be a full transfer checksum, which is not being
proposed.

Joe