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

["Scheffenegger, Richard" <[e-mail]>]

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.

Furthermore, as Koopman has demonstrated, the Hamming distance is a
function of data bits covered - the fewer bits covered, the higher the
HD. Also, As TCP CRC-32 can detect *every* corruption affecting an
uneven number of bits, yet another CRC-32 could be choosen that works
especially well only for even bit corruptions...

The combination of CRC-32 + "CRC-32E" might have even better compound
properties than CRC-32C.

However, the drawback would be to do two calculations (one for the
standard TCP CRC-32, and one for CRC-32C covering only the data
portion).

Also, to stay with Alternate Checksum semantics, if that option is
negotiated once, it should be kept for the remainder of the session -
even if PMTUD / BH decide to start sending only small (MTU<=1500)
packets at some point.


Further, I have spent some time looking for research on the
effectiveness of SACK - as this option would reduce the typical number
of SACK fields from a maximum of 3 down to 2. But from what I learned,
it seems that the number of SACK fields in an ACK have the property of
diminishing returns. You gain a lot from the 1st field; somewhat from
the 2nd, a bit from the 3rd, and having a 4th is surplus :). Besides, if
that option would only be valid for data-carrying segments, it could be
omitted if no data is to be carried - but still kept in "enabled" mode
instead of disabling.

Other than that, only a few nit-picks in wording and definitions (can be
addressed in a later version).


Richard Scheffenegger


> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Mittwoch, 9. Juni 2010 21:27
> To: Lars Eggert
> Cc: [e-mail]; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
> 
> 
> 
> Lars Eggert wrote:
> > Hi,
> > 
> > On 2010-6-9, at 21:07, Anantha Ramaiah (ananth) wrote:
> >> FWIW, there is a recent proposal which talks about enhancing TCP 
> >> checksums as well :-
> >>
> >> 
> http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/
> >>
> >> The above proposal tries to leverage on the TCP alternate checksum 
> >> option.
> > 
> > I've skimmed through this draft when it first came out. I may be 
> > missing something, but why isn't TLS the right solution 
> here? Sure, it 
> > may be overkill, but it's readily available.
> 
> Hi, Lars,
> 
> I don't know if they say it in detail, but:
> 
> TLS doesn't protect TCP against errors which result in bad 
> segments not being retransmitted at the TCP layer; TLS 
> secures, but does not retransmit lost info (it's not a 
> 'reliability' layer). Further, TLS would interpret a bad MAC 
> as an attack and would drop the connection, AFAICT (RFC 5246, 
> see "bad_record_mac").
> With large frames, TCP's checksum would allow false positives 
> (bad segments would get sent to TLS), and TLS would fail.
> 
> Joe
> 
> 
>