[e2e] Fwd: Camel's nose in the tent

[Eric A. Hall]

Both sides are right, IMO.

> The end-to-end argument applies at each protocol layer, not just the 
> transport layer.  Both the rationale for it, and the explicit
> description  we wrote in our paper apply at application layers as well.

My understanding is that in the context of an argument that applies to
enforcement of data integrity, the number of layers/hops/whatever is
irrelevant. IOW, if you are arguing that only the ends can ensure
integrity, then that applies to SMTP over a quiet ethernet as much as it
does to chunked messages over avian carrier.

EG, if you want to ensure that the contents of a particular message are
always preserved, then sign it before you ship it. This is a great
illustration of the strengths of the e2e argument, IMO.

But this is also a different argument from what goes on normally, and what
goes on with SMTP as a case study of TCP's role in typical e2e functions
on the Internet.

SMTP specifies an interaction between a sending system and a recieving
system. The protocol specifically deals with a single hop. What happens at
the next hop is beyond the scope of the protocol. After all, the recipient
in any given SMTP exchange may strip off the headers, convert the body
into EBCDIC, and then beam it off to the space station, and non of that
would have had anything to do with SMTP, while the process may not have
been the message recipient either.

In the most commmon scenario, unless there is some extraneous mechanism to
verify the contents of the message, then SMTP relies on TCP to provide the
integrity indicators. TCP works on the tuple. There is nothing that TCP
can do beyond the current active session (this is particularly true with
SMTP, where the recipient system may completely rewrite the message
contents before opening another session and forwarding the message along a
non-Internet path).

Thus, in the most common case, the TCP end-points are the end points for
the e2e argument (as it applies to SMTP, inclusive). If this isn't
reliable enough, sign the message.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/