Re: ISSUE: transformations

    On the topic of what to do with Content-MD5, you pointed out
    (around last December I think) that one use is to detect
    packet-splicing errors on ATM links (where the TCP ones-complement
    checksum is not sufficient).
    
This is a slight misinterpretation of what I wrote, if you're
referring to:

	http://www.ics.uci.edu/pub/ietf/http/hypermail/1998q1/0117.html

The main point of this message was that transport-level checksums
do not necessarily provide an "error-free transport layer", and
so higher-level checksums are useful.

But in the same message, I also wrote:

    Unfortunately, the [Content-]MD5 checksum covers just the message
    body, and so if one is reassembling a document from several
    messages (e.g., using Range retrievals) one can still have
    undetected errors.  This is why I speculated that Content-MD5 is
    "not even particularly useful" ... it's end-to-end as far as the
    HTTP messages go, but it's not end-to-end as far as the actual
    documents (or whatever) are concerned.
    
I.e., I still believe that Content-MD5 is not actually the
right solution for the problem.

    This, combined with the transformation issue, leads me to think
    that there could (or ought to) be a distinction between hop-by-hop
    and end-to-end message integrity checks (MICs).  I would think that
    if Cache-control: no-transform is present, one would use an
    end-to-end MIC, otherwise a hop-by-hop MIC could be used.
    
The so-called "End-to-End Argument" (see "End-To-End Arguments in
System Design", J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2,
Number 4, November 1984, pp 277-288. - probably not available online,
alas!) implies that if you care about end-to-end integrity, then
you need an end-to-end MIC.  All you can get from hop-by-hop MICs
is some added efficiency if (1) you have the ability to do
automatic hop-by-hop retransmissions if the MIC detects and error,
and (2) such errors are relatively frequent, or (3) the hop-by-hop
MIC is specifically suited to the kinds of errors seen on that hop.
But none of these conditions seems to be true for HTTP.  (The
Ethernet CRC is useful because Ethernet-level errors are common,
due to CSMA/CD, and the CRC is designed for the kinds of
errors that do occur.)

In any case, it's hard to think of a way to specify "no-transform" in
such a way that it depends on the presence of specific kinds of headers
carrying MICs, especially if we want to be able to extend the set of
MICs in the future.  I think this is a rathole, and we're best off just
saying "no-transform means no transforms of the entity-body, period."

-Jeff

Received on Thursday, 13 August 1998 13:12:28 UTC