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

[David P. Reed]

The reason middleboxes can "repair" CRC32 type functions is because they 
are not "one-way" functions.  In other words, the inverse of a CRC32 
checksum step is as easy to compute as the step itself.  This means that 
corrupting one byte of a datagram that is CRC'ed or checksummed is easily 
corrected by computing the inverse of the CRC32 on the original data, 
subtracting it, and then  adding back the CRC32 function of the replacement 
data.

I think the idea of a keyed MD5 checksum is the best protection against 
clueless middleboxes.

At 04:55 PM 6/7/01 -0600, vince_cavanna at agilent.com wrote:
>I have been thinking more about this idea of mine and have the following
>addional observations:
>
>1. A middle box can, without ever needing to know the secret key, actually
>make changes to a portion of a protected packet and compensate for the
>effect, on the CRC, of the changes by following the changes with a computed
>32 bit field that restores the CRC "state" to what it would have been at
>that same point in the data stream had the changes not been made.
>
>This observation does not render my idea useless since unintentional changes
>by middle boxes would be caught at the receiver end-node.  The middle box
>would be forced to make an adjustment for the intentional changes that it
>has made to the packet rather than recompute, as many do today, the CRC of
>the entire packet and risk fixing the CRC after making unintentional changes
>as well as intentional ones. The middle box cannot recompute the entire CRC
>because it does not have all the data (is missing the secret key) protected
>by the CRC.
>
>2. The middle box can relatively easily compute the secret key from a single
>packet and thus has no need to discover it nor store it. There is therefore
>little point in using a secure key exchange mechanism to distribute the
>secret key shared by the end-nodes.
>
>Conclusion:
>
>This idea may have some merit in protecting from unintentional changes by
>middle boxes but is not useful for protection from intentional changes.
>
>A motivated and well-heeled middle box can compute the secret key and store
>it and use it to recompute the CRC over the entire packet thus defeating the
>entire scheme.
>
>Vince
>
>|-----Original Message-----
>|From: CAVANNA,VICENTE V (A-Roseville,ex1)
>|Sent: Thursday, June 07, 2001 11:40 AM
>|To: 'Jonathan Stone'
>|Cc: David P. Reed; tsvwg at ietf.org; end2end;
>|sommerfeld at orchard.arlington.ma.us; STEINMETZ,JOE (A-Americas,unix1);
>|WAKELEY,MATT (A-Americas,unix1); CAVANNA,VICENTE V (A-Roseville,ex1)
>|Subject: RE: [e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything
>|else?
>|
>|
>|Jonathan and others,
>|
>|Would a "keyed CRC32" instead of "keyed MD5" be appropriate
>|for the purpose of preventing unauthorized tampering of the
>|protected packet by middle boxes? A CRC is much further from
>|being a one-way hash function than the MD5, but once keyed, by
>|including the shared secret in the data protected by the CRC,
>|it may be good enough to discourage tampering by middle boxes.
>|The benefit, of course, is that computing the CRC32 digest is
>|much easier than computing an MD5 digest. To foil such
>|protection, Middle boxes would need to, first, discover the
>|shared secret and, second, remember the shared secret - for
>|each connection. Since, as David Reed has pointed out, middle
>|boxes do not store per-connection state, the second step alone
>|may be a large enough obstacle to render adequate the
>|communication of the shared "secret" in the clear and thus
>|avoid the use of a secure key-exchange protocol.
>|
>|Vince
>|
>||-----Original Message-----
>||From: Jonathan Stone [mailto:jonathan at DSG.Stanford.EDU]
>||Sent: Friday, May 25, 2001 2:51 PM
>||To: sommerfeld at orchard.arlington.ma.us
>||Cc: David P. Reed; tsvwg at ietf.org; end2end
>||Subject: Re: [e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything
>||else?
>||
>||
>||
>||In message
>||<20010525212300.A8F062A4B at orchard.arlington.ma.us>Bill Sommerfeld wr
>||ites
>||>> [... md5 as an error-check function to defeat would-be
>||middleboxers...]
>||>>
>||>> If you put that in the transport layer, won't that makes
>||communication
>||>> without a shared-secret impossible? At least without using
>||some other
>||>> transport protocol, to bootstrap a D-H or SPEKE or other
>|initial key
>||>> exchange.
>||>
>||>md5 is an unkeyed function, just like the CRC or internet checksum.
>||>
>||>hmac-md5 is a keyed function built out of md5 (it's one of two MAC
>||>functions used with IPsec). [...]
>||
>||Yes, I know.  David Reed was explicitly suggesting md5 *with* a
>||shared-secret (like hmac-md5) as an e2e integrity check in order to
>||detect middle-boxes.  Using shared secrets at the transport protocol
>||needs way -- perhaps unekeyed md5? -- to bootstrap the conversation.
>||
>||I hope just aying "md5" while referring to shared-secrets didn't
>||cause confusion.
>||
>||
>||_______________________________________________
>||tsvwg mailing list
>||tsvwg at ietf.org
>||http://www1.ietf.org/mailman/listinfo/tsvwg
>||
>|