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

[Dave Crocker]

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>



-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>