|
|
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
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tcpm
|
|