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

[Joe Touch <[e-mail]>]

Hi, Anumita,

Biswas, Anumita wrote:
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]] 
>> Sent: Wednesday, June 09, 2010 5:46 PM
>> To: Scheffenegger, Richard
>> Cc: [e-mail]; Anantha Ramaiah (ananth)
>> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
>>
>>
>> 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.
>>
> If middleboxes are not RFC compliant, then yes.

I don't know what that means, FWIW. NATs by their very definition violate RFC
1122 and 1812, but we don't need to rehash that here. My view is that it's not
sensical to talk about "laws for the lawless", and AFAICT most middleboxes
*want* to violate the standards.

>> Some will drop the segment simply because it has an option 
>> they don't understand.
>
> I guess our goal is not to solve the problem for workaround middleboxes
> that do not follow RFC 1122 interoperability mandate in 4.2.2.5. 

This is an issue more with, e.g., RFC 1812. The middlebox isn't an endpoint, so
it has no business caring about or modifying such options. RFC 1122 is only
about endpoints.

However, my point is that this is the common behavior of many middleboxes,
AFAICT. Ignoring that is saying "we don't expect it to work at all anyway."

> I am more worried about the bigger problem of losing data integrity for
> packet MTUs greater than 1500. Today we are storing peta bytes of data
> in a single storage bin. Imagine copying peta bytes of data over the
> network to that bin. The likelihood of bit errors going undetected just
> increased probably by many magnitudes. 

There are two separate issues:

1- integrity of the data

2- coordinating that integrity with TCP

TLS gets you #1, if you deal with retries at the application layer (you need to
write your own "file transfer over TLS" protocol.

#2 - which is better, AFAICT, since TCP will do the retries - can be achieved
various ways with existing protocols using any other IP encapsulation that
provides similar strength, e.g., using IPsec or SEAL E2E. That would ensure bad
segments would be dropped before TCP processing, and then TCP's retransmission
would fix the hole.

Another trick is to build a wrapper on some other system, e.g., using Java and
FTP. FTP the files, use Java to do a local stronger whole-file check, and resend
if the check fails.

So although I appreciate the problem, it's not at all clear TCP is the
appropriate or easiest place to fix it, IMO.

...
>> 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.
>>
> Based on comments I received from Richard Scheffenegger offline, we have
> to continue to put in the summation based 16-bit checksum in the TCP
> header so that we don't break the existing standard of what the TCP
> checksum is expected to be. 

You can't do this without redefining RFC 1146 - i.e., that's not RFC 1145
anymore. That may be OK, but that's a limit of this approach.

> However, I am a bit skeptical about the comment that the 16-bit
> summation based checksum is adequate to pass off as protecting the TCP
> header. In theory it does protect the TCP header, but in practice, when
> the checksum spans MTU sizes larger than 1500 bytes, it is not going to
> catch the random bit flip in the sequence number, ack number etc.
> Instead, the draft proposes a stronger tcp checksum  

A single random bit flip will be caught by the TCP checksum; it's certain
patterns of multiple flips that won't.

> The draft also only debates over whether the psuedoheader must be added
> to the TCP checksum. But it states that the TCP header + Data must be
> included in the CRC 32C checksum.

FWIW, the TCP header *includes* the IP pseudoheader. It's an artifact of how TCP
and IP were split that the info isn't copied into the TCP header. The only way
around that is to have some other crypto state shared at the endpoints that
identifies the connection - e.g., this is why I suggested we could drop some of
the pseudoheader for TCP-AO support over NATs (draft-touch-tcp-ao-nat).

> Again, these are details that can be worked out if the WG thinks that
> this draft is worth taking up by the WG for further consideration.

I think what you're hearing (the WG chairs can correct me if not) is that some
of these details may need working out in order to make that decision.

Joe