[e2e] End-to-end is a design guideline, not a rigid rule

[Fred Baker]

I'll agree with points made in each of the emails in this thread.

 From my perspective, "end to end" includes both "end-to-end-across-a- 
single-communication" and the "end-to-end-in-a-disruption-tolerant- 
manner" models that Dave C mentioned. End to end in an email means  
that when I send a message to the various recipients of end2end- 
interest, I expect service in each of the hundreds of cases of that  
to be essentially the same - that the content of the message will not  
be changed en route, that the envelope of the SMTP message will be  
updated at each application layer hop to facilitate problem  
diagnosis, and that delivery will be timely within the service limits  
of the application or a response will be sent to me saying that it  
could not be accomplished. Supporting that, the MUA-MTA, MTA-MTA, and  
MTA-MUA hops will similarly be handled with minimal effort. One would  
expect that the interaction of MUAs and MTAs across a network of ISPs  
to be indistinguishable from one in which they all happened to be  
colocated on a common LAN apart from the rate and timing side-effects  
of the engineering of the network.

One place where I depart from a common view of the end to end  
argument is that there are times when it makes sense to actively  
enquire of the network and expect the network to make a response that  
characterizes itself. A completely "stupid" network, such as a 3/4"  
diameter yellow coaxial cable, would not be able to respond, and as I  
understand Isenberg, that is the way all networks should behave. All  
intelligence should be in the end system and only in the end system.  
But (Dave R, tell me if I am wrong) Saltzer/Reed doesn't seem to  
suggest that. The point of the original end-to-end argument was not  
that intelligence should reside only in the end station or only in  
the application; it was that a lower layer should not do something  
that also had to be done at a higher layer without a good  
justification. An example, often repeated, is that LAPB go-back-N  
retransmission is redundant in the presence of TCP or application  
retransmission, and that it measurably resulted in packet duplication  
around bit errors. That said, 802.11 also has retransmission, and if  
it didn't, behavior on wireless LANs would be a lot worse than it is.  
Hence, we retransmit in TCP in the general case, but 802.11 presents  
a case where link layer retransmission is still justified. This  
understanding of the end-to-end principle would seem to suggest that  
interactions with the network that inform the intelligent edge and  
enable it to make better decisions are within the principle's scope.  
I view both the integrated services and the differentiated services  
architectures in that light - one doesn't want the network to subvert  
the intent of the intelligent edge, but interactions that enable it  
to better achieve its intent are good.

And then, what is subversion? It is pretty common to put in what  
amounts to a network honeypot, in which one of the addresses in a  
prefix is routed down a tunnel to a collector. In the event that  
anyone sends something to the address, the collector picks it up, and  
management remediation actions follow. Is this "subversion of  
routing"? I would argue that it is "routing", but is not  
"subversion". Ditto the case where a system comes under attack and  
network ops staff reroutes the address through the same kind of  
tunnel. That certainly subverts the attack, and makes the targeted  
system unavailable for a period of time until the attack can be  
interdicted. But for any legitimate use of the targeted system, it's  
hard to describe as subversion; it's part of the process of restoration.

As to NATs and such - to my way of thinking, a NAT is two things in  
one. It is a stateful firewall (it maps active authorized address/ 
port pairs, creates such a mapping if it originates from "inside",  
and if the mapping doesn't exist it blocks communication from the  
"outside"), which if one thinks having skin on the human body is good  
for its health one has to consider a reasonable prophylactic  
protection. To the extent that applications and protocols above the  
network layer know something about network layer addresses, NATs also  
create difficulties in deploying such applications. In that sense, a  
NAT is a man-in-the-middle attack, something that makes life  
difficult for the application. I'm all for good firewalls; the end to  
end model doesn't speak highly of things that break application  
behavior, however.

So, coming back to Dave C's point about our current network  
architecture not doing very well with hidden boundaries, I would say  
"you are correct; it doesn't". I don't think that is a failure of the  
end-to-end principle, however. It may be a failure of our ability to  
apply it correctly. If all applications were message-based, like  
email is, one could imagine a firewall acting something like an MTA -  
terminating the conversation in one domain and then repeating it in  
another, in a manner entirely consistent with the end-to-end  
principle as applied to email in its two forms of end-to-end-ness. If  
all applications were able to be proxied, like SIP, or the various  
users of SOCKS are, the proxy could literally be the trusted-and- 
known third party that made the transition happen. If IP were very  
slightly different, with the AS number in the header and listed in  
DNS and the routing protocols, and addresses being understood as  
local to the identified AS, we could assign an AS to every region  
behind a NAT, and the whole thing would work quite nicely end to end.

The problem is not that the architecture and available tools don't  
handle the concept of separation of domains; it is that our current  
common implementation of separation of domains involves a man-in-the- 
middle attack on a subset of the relevant applications and protocols.  
As Dave R points out, the man-in-the-middle attacks that we build in  
make the network harder to manage and harder to maintain, and makes  
the applications harder to improve. Fixing the architecture, in my  
opinion, will involve removing the things that subvert the intent of  
the end system, which is to say, changes them in the direction of  
Salter/Reed's version of the end-to-end principle.



> From: Dave Crocker <dhc2 at dcrocker.net>
> Date: December 1, 2005 7:04:04 AM PST
> To: end2end-interest at postel.org
> Subject: [e2e] End-to-end is a design guideline, not a rigid rule
> Reply-To: dcrocker at bbiw.net
>
> Folks,
>
> A posting on Farber's IP list finally prompted me to write some  
> thoughts that have been wandering around in the back of my mind.   
> I'm interested in reactions you might have:
>
>
> "Andrew W. Donoho" wrote:
> > The debate about NAT obscures the real issue - that there are  
> legitimate reasons to assert policies for net access at  
> organizational boundaries. Yes, we want the internet architecture  
> to be end to end.
>
>
> This struck me as a particularly useful summary statement about  
> some core architectural issues at hand:  Internet technical  
> discussions tend to lack good architectural constructs for  
> describing operations, administration and management (OA&M)  
> boundaries, and we lack robustness in the "end to end" construct.
>
> The issue of OA&M boundaries has long been present in the Internet.  
> Note the distinction between routing within an Autonomous System  
> and routing between ASs.  To carry this a bit further, note that  
> the original Internet had a single core (backbone) service, run by  
> BBN.  The creation of NSFNet finally broke this simplistic public  
> routing model and required development of a routing protocol that  
> supported multiple backbones.
>
> As another example, the email DNS MX record, that one finds over  
> the open Internet, is also generally viewed as marking this  
> boundary and is often called a Boundary MTA.  However the Internet  
> Mail architecture does not have the construct explicitly.  For a  
> year or so, I have been searching for a term that marks  
> independent, cohesive operational environments, but haven't found  
> one that the community likes.  Some folks have suggested a  
> derivation of an old X.400 term:  Administrative Management Domain  
> (ADMD).
>
> More generally I think that this issue of boundaries between  
> islands of cohesive policy -- defining differences in the trust  
> within an island, versus between islands -- is a key point of  
> enhancement to the Internet architecture work that we must focus  
> on.  I have found “Tussle in Cyberspace: Defining Tomorrow’s  
> Internet,” (Clark, D., Wroclawski, J., Sollins, K., and R. Braden,   
> ACM SIGCOMM, 2002) a particularly cogent starting point, for this  
> issue.
>
> On the question of the "end to end" construct I believe we suffer  
> from viewing it simplistically.  What I think our community has  
> missed is that it is a design guideline, not a rigid rule.  In fact  
> with a layered architecture, the construct varies according to the  
> layer.  At the IP level, this is demonstrated two ways.  One is the  
> next IP hop, which might go through many nodes in a layer-2  
> network, and the other is the source/destination IP addresses,  
> which might go through multiple IP nodes.
>
> The TCP/IP split is the primary example of end-to-end, but it is  
> deceptive. TCP is end-to-end but only at the TCP layer.  The  
> applications that use TCP represent points beyond the supposed end- 
> to-end framework.
>
> My own education on this point came from doing EDI over Email.  Of  
> course I always viewed the email author-to-recipient as "end to  
> end" but along comes EDI that did additional routing at the  
> recipient site.  To the EDI world, the entire email service was  
> merely one hop.
>
> This proved enlightening because the point has come up repeatedly:   
> For email, user-level re-routing and forwarding are common, but  
> outside the scope of the generally recognized architecture. I've  
> been working on a document that is trying to fully describe the  
> current Internet Mail architecture:
>
>   <http://bbiw.net/specifications/draft-crocker-email-arch-04.html>
>
> However it is not clear whether it will reach rough consensus.
>
> My own view is that the email concept of end to end  has two  
> versions. One is between the posting location and the SMTP RCPT-TO  
> (envelope) address and the other is between the author and the  
> (final) recipient.  Failure to deal with this explicitly in the  
> architecture is proving problematic to such email enhancements as  
> transit responsibility, such as by SPF or DKIM).
>
> In other words, the Internet technology has never been a pure "end  
> to end" model.  Rather, end to end is a way of distinguishing  
> between components that compose an infrastructure versus components  
> that use the infrastructure -- at a particular layer. "End to end"  
> is a way of characterizing a preference to keep the infrastructure  
> as simple as possible.
>
> This does not mean that we are prohibited from putting anything  
> into the infrastructure or changing the boundaries of the  
> infrastructure, merely that we prefer to keep the it unchanged.  In  
> this light, NATs (and firewalls) are merely a clear demonstration  
> of market demand for some facilities that make end to end layered  
> with respect to some operational policies, to permit the addition  
> of a trust boundary between intra-network operations and inter- 
> network operations.
>
> We should not be surprised by this additional requirement nor  
> should we resist it.  The primary Internet lesson is about scaling,  
> and this appears to be a rather straightforward example of scaling  
> among very large numbers of independent and diverse operational  
> groups.  Growth like this always comes with vast cultural  
> diversity.  That means that the basis for trust among the  
> independent groups is more fragile.  It needs much more careful  
> definition and enforcement than was required in the kinder and  
> gentler days of a smaller Internet.
>
>
> d/
> -- 
>
> Dave Crocker
> Brandenburg InternetWorking
> <http://bbiw.net>


> From: Joe Touch <touch at ISI.EDU>
> Date: December 1, 2005 11:38:42 AM PST
> To: dcrocker at bbiw.net
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] End-to-end is a design guideline, not a rigid rule
>
> The "ends" and "hops" in E2E are relative, at least they always  
> have been to me. All the E2E argument says, in that context, is  
> that you can't compose HBH services to end up with the equivalent E2E.
>
> It never said not to do HBH (e.g., for performance). It never said  
> where the ends definitively were for all layers, IMO.
>
> Joe


> From: "David P. Reed" <dpreed at reed.com>
> Date: December 1, 2005 11:40:08 AM PST
> To: end2end-interest at postel.org
> Subject: Re: [e2e] End-to-end is a design guideline, not a rigid rule
>
> [oops, Dave C. pointed out that I replied only to him, instead of  
> only to e2ei, and encouraged me to send it to the whole list]
>
> The end-to-end argument was indeed a design guideline not a rigid  
> rule as proposed.   On the other hand, as you point out, Dave, its  
> value as a guideline is making a system scalable and evolvable.    
> And there's a corollary:  building function into the network has  
> costs as well as benefits.   Too often we ignore those costs,  
> because they are less visible than the benefits.
>
> However, I disagree with your example.  The problem is that  
> topology doesn't map to authority.   Yes, there are organizational  
> boundaries, and organizations have an interest in communications  
> between peers. However, those organizational boundaries do NOT  
> correlate closely with physical network boundaries.   The premature  
> binding of organizational boundaries to physical topological  
> connect points is why NATs and so forth so often miss the mark on  
> solving the true "end-to-end" problems we have.
>
> So, I agree with you on your major point, but I disagree that email  
> is a good example of how to either apply or ignore the end-to-end  
> argument.
>
> One merely has to examine the move to having hotel ISPs spoofing  
> SMTP connections based on their organizational "interest" in  
> blocking spam (and their lawyers assert that the the law *requires*  
> them to do this). That man-in-the-middle solution actually prevents  
> better solutions (such as crypto-authentication that prevents man- 
> in-the-middle attacks) to the actual end-to-end requirements that  
> users want.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051201/9f228242/PGP-0001.bin