[ih] inter-network communication history

[Jack Haverty]

Dan Lynch's recollection of the sacred "end-to-end" nature of  TCP is
right on target.  (Hi Dan!)   The Internet was architected to place TCP
at the ends of any interaction, as close to the "user" (human or
program) as possible.  

The IP transport service along the paths between the ends was always to
be under suspicion, and it might drop, delay, replicate, misdeliver,
mangle, or even inject IP datagrams that might look like they came from
the endpoint source.   But TCP, and other technical and procedural
mechanisms at the endpoints, would detect such behavior and compensate
for it.

The scenarios driving such thinking were simple in military arenas - you
had to assume that some of the stuff between the endpoints might have
been compromised and under enemy control, possibly without your
knowledge.  In that scenario, tanks, troops, special ops and such are
involved.  In today's Internet it's more likely to be bugs, hackers,
viruses, and trojan horses.  In any event, the TCP and related stuff at
the endpoints would counteract such problems in the intermediate IP
environment. 

That was the architecture - TCP to provide end-to-end "sacred"
mechanisms, IP to provide untrustworthy along-the-path best efforts.  

I think of myself as more of an architectural pragmatist than purist. 
For a while in the 80s, I was responsible for BBN's work with DCA in
"DDN System Engineering", i.e., taking this Internet stuff and getting
it to work in the operational world.  It didn't quite work "out of the
box"...

That involved dealing with a lot of "administrative boundaries", and
adding some architectural components to make them possible.  Two
examples come to mind.

First, in early 1982, after Bob Kahn convinced me of the importance of
such boundaries, Eric Rosen and I brainstormed and created the notion of
"autonomous systems" and the EGP protocol.  If you look at RFC827, it
says "It is proposed to establish a standard for Gateway to Gateway
procedures that allow the Gateways to be mutually suspicious."   That
was the key addition to the Architecture that would make it possible to
isolate "bad" pieces of the IP infrastructure and keep the rest of the
IP transport system functioning.  EGP was just a first step, to enable
further experimentation and development (which I don't know ever
happened).  EGP didn't say how to be suspicious; it just established a
boundary so you could be suspicious if you figured out how to do so.

Second, around the same time, we defined a "DDN Standard Node".  This
was simply two gateways, interconnected by a wire.  It built on the
previous idea that a wire was just a very simple network which had only
two "hosts", "this end" and "that end".  

In the DDN, such a node would go into every site.  Instead of a single
gateway at a site, there would be two connected in series.  One gateway
would connect to that site's internal network of LANs and such.  The
other would connect to another site by some long-haul communications
medium, e.g., a PRNet, SATNET or ARPANET clone, etc.  The "inside"
gateway would be "owned" by the base or ship commander and his/her IT
staff.  The "outside" gateway would be owned by DCA and the DDN staff.

in addition to these two, there were other mechanisms for operational
needs, e.g., TACACS to provide a mechanism to identify, and control, who
was using the Internet and what they were doing (connecting to hosts). 

Such an architecture was trying to establish the needed administrative
boundaries.  E.g., he "DDN Standard Node" provided a mechanism to create
such a boundary wherever appropriate, at the IP level.  Different pieces
of the government want to control their own stuff....

Circa 1984, I remember giving lots of presentations where one theme was
that we had spent the first 10 years of the Internet (taking the 1974
TCP paper as the start) making it possible for every computer to talk
with every other computer.  We would spend the next 10 years making it
not possible to do such things, so that only communications that were
permitted would be possible.

Sadly, I'm not sure that ever happened.  The commercial world started
adopting TCP big time.   The government decided to focus on using COTS -
Commercial Off-The-Shelf hardware and software.  The Research world
focused on things like faster and bigger networks.   At BBN, the focus
shifted to X.25, SNA, and such stuff that promised a big marketplace.  
TCP had gone through 5 releases from TCP2 through TCP4 in just a few
years, so remaining items on the To-Do list, like address space, were
expected to be addressed shortly.

I'm not sure if anyone ever conveyed this architecture to the IETF or
all the vendors that were popping up with products to build
Internet(s).  I think changes like NAT came about to solve pragmatic
problems.  But that of course broke the "end-to-end" architecture, which
would view NAT actions as those of an intruder or equipment failure.  
So TCP became no longer end-to-end.  

The Internet is typically viewed as a way to interconnect networks.  But
I think it's evolved operationally to become the way to interconnect
across administrative boundaries, where Autonomous Systems have become
associated with different ISPs, other mechanisms are used by vendors to
create their own walled gardens of services (e.g., "clouds" or
"messaging"), and NAT is used at the edges to connect to users'
internets.  The end-to-end nature is gone. 

But that's just based on my observations from the outside.  I don't have
a clue as to what today's actual Internet Architecture is, other than a
collection of RFCs and product manuals that may or may not reflect
reality, or if there is anyone actually able to manage the
architecture.  From my user's perspective, it's a Wild West out there.....

And the definition of The Internet is still elusive.  I agree that the
users' definition is the best working one -- The Internet is the thing
I'm connected to to do what I do when I get "on the Net."

Fascinating to watch this over 50 years...who would have thought it
would last this long?

/Jack Haverty


On 11/7/19 7:29 AM, Dave Crocker wrote:
> On 11/6/2019 4:08 PM, Jack Haverty wrote:
>> The flaw in my definition of computers talking to computers comes from
>> the tweaks added to the technology well after TCP/IP itself -- things
>> like firewalls, port forwarding, NAT, et al.  When I worked at Oracle,
>> we ran our own internet, which had thousands of computers attached that
>> could all talk to each other.  But only one of them could talk out to
>> the rest of the world.
>
>
> Here I'll disagree.  Nothing about those additional components gets in
> the way of your definition.  (That's written as an small, implicit pun.)
>
> In spite of the changes those components effect, the computers at the
> end points still interoperate, which is what your language specifies.
>
> As for the Oracle example, I'll suggest that it merely demonstrates
> that 'the' Internet includes other internets, and that while true, I
> don't offer it as much of an insight.
>
> As for the strong reactions Internet architecture purists have about
> these additional components, mostly it seems to stem from a failure to
> appreciate the operational importance of administrative boundaries. 
> For some reason, we think it fine to have those when doing global
> routing, but not for other aspects of transit data processing, in
> spite of the continuing and pervasive demonstration of their need.
>
> I'm never any good at attributing quotations or getting their wording
> right, but there was long ago an observation that a law, which is
> violated by a large percentage of the population, is not a very good
> law.  The same logic applies to architectural purity criticisms of
> NATs, etc.
>
> d/
>