[e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything else?

Jonathan Stone jonathan at DSG.Stanford.EDU
Mon Jun 11 11:22:56 PDT 2001


In message <5.1.0.14.2.20010611100206.04614b60 at mail.reed.com>
"David P. Reed" writes:

[crypto rather than checksums]

>>That list (of typical hardware and software malfunctions) is a small 
>>fraction of the kinds of errors that a motivated adversary
>>could cause.  And we could imagine designing checksums to be efficacious
>>against such errors.
>
>Agreed.  I stipulate that this paragraph is all true.   But as mentioned 
>above, proving that the checksum will be significantly optimized by 
>handling only this broad and fuzzy "small fraction" and not the more 
>general "adversary-driven" class of corruptions seems to be of value only 
>if the cryptographic approach is dramatically costly.  And it isn't 
>anymore, since silicon and theory have both advanced over the last 25 years 
>a great deal.

David,

I think you are overlooking several points here.


First is that just using md5 doesnt get what you want.  With raw MD5,
the middle-box can recompute (or pass along) MD5 hashes. You have to
do HMAC-MD5, which pushes up the computational cost considerably.


Second is that more computationally expensive error checks are a
stronger push to outboard checksumming.  The data I and Craig have
gathered shows that the path between the NIC's link-level CRC engine,
and the TCP (or IP) checksum computation, is a significant cause of
end-to-end errors.  Not checking that part of the end-to-end path
weakens the end-to-end property of a nominally `end-to-end' error
check.  If advocating ``stronger'', computationally more expensive
error checks encourages outboard checksumming, you are aiding and
abbetting in making the check less of an end-to-end check, to
precisely the degree that outboard checksumming was encouraged.
Is this what you want to do?

Third, is that I wonder if you took in the result from my dissertation
which Craig reported a couple of days ago?  Over the space of all
possible errors, md5 detects the exact same fraction of errors as MD4,
or as a 128-bit CRC, or a 128-bit sum, or even a 128-bit constant.
Given that, what is the *error-detection* rationale for using MD5--
as opposed (per the earlier disscussion) chooisng a cheaper function,
which gives us the same Shannon information?


Last, a question. I've suggested an adversary models with `blind'
adversaries which can't exploit the structure of an error-check
function. You proposed informed, intelligent, malicious adversaries --
an intruder model which suggests cryptographic approaches.
We already have protocols which address those latter models.

Does the end-to-end principle really argue for forcing the cost of
crypographically-strong error checks onto every end-host, for
every packet?  Or can detecting and defeating middle-boxes
be achieved via something like ipsec?





More information about the end2end-interest mailing list