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

[David P. Reed]

At 11:22 AM 6/11/01 -0700, Jonathan Stone wrote:


>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.

When I first said MD5 I meant a keyed crypto hash function.  The keyed 
versions of MD5 are not particularly more complex than MD5.  MD5-MAC 
involves only a small increment of cost, for example.  So we could debate 
"considerably" and I think you'd have a hard time convincing me that it's a 
very large difference.  I'll bow to  a careful complexity-class analysis.


>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?

I think I side with Vernon Schryver (as I understand his 
point).  Checksumming is going to be done in outboard boxes even if it is 
cheap, because that gets a few percent.  It shouldn't be done there, but it 
will.  So this is not a strong argument for good design.  One could even 
argue the opposite - by making the checksum a complex operation that can 
only be done efficiently on the application CPU, one encourages it to be 
done there.  One can increase the probability by providing microcode in the 
processor (hey, Intel!) like the inclusion of true random number source in 
recent Pentiums.


>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?

I did, but it does not make sense.  Detecting the same fraction is not the 
same as having a good probability of detecting the errors that happen in 
fact.  The constant function is particularly bad on this front.  But by 
using a keyed class of cryptographically based functions, you increase the 
potential set of errors that will be detected eventually if they are repeated.


>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.

But they aren't standard.  If they were standardly used, we wouldn't need 
checksums.



>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?

IPSEC or something like it would do the job.  But it isn't mandatory that 
boxes implement IPSEC, and it probably should be mandatory.  The end-to-end 
argument does support the idea that if security is needed, it must be done 
at the endpoints.

I've nearly lost hope that one can argue against those who would deny 
authentication and security to all end users.  The FBI, NSA, firewall 
vendors, and even many operators all have a vested interest in providing 
unreliable, insecure, unauthenticatable communications services.

But one more argument is that if most users want some degree of security 
and authentication, the "checksum" becomes merely a low-level redundancy 
that is unnecessary if the higher levels are doing such checks.

The presumption that most users *don't* want such services end-to-end is 
one of the "big lies" (ok, maybe a middle-sized one).

- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html