<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jack, that was Really Excellent... say, in The Interest in further documenting Internet History, could you please elucidate for us on <b>The Internet "Control Panel"</b> and its functionality/workings (as excerpted from your website -- <a href="http://3kitty.org/">http://3kitty.org/</a>):</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style=""><blockquote style="font-family:verdana,sans-serif;font-size:small;margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"> ... <i>(At one point back around 1980, the "control panel" for The Internet was on his desk!)</i>...<br></div></blockquote><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">geoff</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 7, 2019 at 9:23 AM Jack Haverty via Internet-history <<a href="mailto:internet-history@elists.isoc.org">internet-history@elists.isoc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br><br>---------- Forwarded message ----------<br>From: Jack Haverty <<a href="mailto:jack@3kitty.org" target="_blank">jack@3kitty.org</a>><br>To: <a href="mailto:dcrocker@bbiw.net" target="_blank">dcrocker@bbiw.net</a><br>Cc: <a href="mailto:internet-history@elists.isoc.org" target="_blank">internet-history@elists.isoc.org</a><br>Bcc: <br>Date: Thu, 7 Nov 2019 11:22:39 -0800<br>Subject: Re: [ih] inter-network communication history<br>Dan Lynch's recollection of the sacred "end-to-end" nature of  TCP is<br>
right on target.  (Hi Dan!)   The Internet was architected to place TCP<br>
at the ends of any interaction, as close to the "user" (human or<br>
program) as possible.  <br>
<br>
The IP transport service along the paths between the ends was always to<br>
be under suspicion, and it might drop, delay, replicate, misdeliver,<br>
mangle, or even inject IP datagrams that might look like they came from<br>
the endpoint source.   But TCP, and other technical and procedural<br>
mechanisms at the endpoints, would detect such behavior and compensate<br>
for it.<br>
<br>
The scenarios driving such thinking were simple in military arenas - you<br>
had to assume that some of the stuff between the endpoints might have<br>
been compromised and under enemy control, possibly without your<br>
knowledge.  In that scenario, tanks, troops, special ops and such are<br>
involved.  In today's Internet it's more likely to be bugs, hackers,<br>
viruses, and trojan horses.  In any event, the TCP and related stuff at<br>
the endpoints would counteract such problems in the intermediate IP<br>
environment. <br>
<br>
That was the architecture - TCP to provide end-to-end "sacred"<br>
mechanisms, IP to provide untrustworthy along-the-path best efforts.  <br>
<br>
I think of myself as more of an architectural pragmatist than purist. <br>
For a while in the 80s, I was responsible for BBN's work with DCA in<br>
"DDN System Engineering", i.e., taking this Internet stuff and getting<br>
it to work in the operational world.  It didn't quite work "out of the<br>
box"...<br>
<br>
That involved dealing with a lot of "administrative boundaries", and<br>
adding some architectural components to make them possible.  Two<br>
examples come to mind.<br>
<br>
First, in early 1982, after Bob Kahn convinced me of the importance of<br>
such boundaries, Eric Rosen and I brainstormed and created the notion of<br>
"autonomous systems" and the EGP protocol.  If you look at RFC827, it<br>
says "It is proposed to establish a standard for Gateway to Gateway<br>
procedures that allow the Gateways to be mutually suspicious."   That<br>
was the key addition to the Architecture that would make it possible to<br>
isolate "bad" pieces of the IP infrastructure and keep the rest of the<br>
IP transport system functioning.  EGP was just a first step, to enable<br>
further experimentation and development (which I don't know ever<br>
happened).  EGP didn't say how to be suspicious; it just established a<br>
boundary so you could be suspicious if you figured out how to do so.<br>
<br>
Second, around the same time, we defined a "DDN Standard Node".  This<br>
was simply two gateways, interconnected by a wire.  It built on the<br>
previous idea that a wire was just a very simple network which had only<br>
two "hosts", "this end" and "that end".  <br>
<br>
In the DDN, such a node would go into every site.  Instead of a single<br>
gateway at a site, there would be two connected in series.  One gateway<br>
would connect to that site's internal network of LANs and such.  The<br>
other would connect to another site by some long-haul communications<br>
medium, e.g., a PRNet, SATNET or ARPANET clone, etc.  The "inside"<br>
gateway would be "owned" by the base or ship commander and his/her IT<br>
staff.  The "outside" gateway would be owned by DCA and the DDN staff.<br>
<br>
in addition to these two, there were other mechanisms for operational<br>
needs, e.g., TACACS to provide a mechanism to identify, and control, who<br>
was using the Internet and what they were doing (connecting to hosts). <br>
<br>
Such an architecture was trying to establish the needed administrative<br>
boundaries.  E.g., he "DDN Standard Node" provided a mechanism to create<br>
such a boundary wherever appropriate, at the IP level.  Different pieces<br>
of the government want to control their own stuff....<br>
<br>
Circa 1984, I remember giving lots of presentations where one theme was<br>
that we had spent the first 10 years of the Internet (taking the 1974<br>
TCP paper as the start) making it possible for every computer to talk<br>
with every other computer.  We would spend the next 10 years making it<br>
not possible to do such things, so that only communications that were<br>
permitted would be possible.<br>
<br>
Sadly, I'm not sure that ever happened.  The commercial world started<br>
adopting TCP big time.   The government decided to focus on using COTS -<br>
Commercial Off-The-Shelf hardware and software.  The Research world<br>
focused on things like faster and bigger networks.   At BBN, the focus<br>
shifted to X.25, SNA, and such stuff that promised a big marketplace.  <br>
TCP had gone through 5 releases from TCP2 through TCP4 in just a few<br>
years, so remaining items on the To-Do list, like address space, were<br>
expected to be addressed shortly.<br>
<br>
I'm not sure if anyone ever conveyed this architecture to the IETF or<br>
all the vendors that were popping up with products to build<br>
Internet(s).  I think changes like NAT came about to solve pragmatic<br>
problems.  But that of course broke the "end-to-end" architecture, which<br>
would view NAT actions as those of an intruder or equipment failure.  <br>
So TCP became no longer end-to-end.  <br>
<br>
The Internet is typically viewed as a way to interconnect networks.  But<br>
I think it's evolved operationally to become the way to interconnect<br>
across administrative boundaries, where Autonomous Systems have become<br>
associated with different ISPs, other mechanisms are used by vendors to<br>
create their own walled gardens of services (e.g., "clouds" or<br>
"messaging"), and NAT is used at the edges to connect to users'<br>
internets.  The end-to-end nature is gone. <br>
<br>
But that's just based on my observations from the outside.  I don't have<br>
a clue as to what today's actual Internet Architecture is, other than a<br>
collection of RFCs and product manuals that may or may not reflect<br>
reality, or if there is anyone actually able to manage the<br>
architecture.  From my user's perspective, it's a Wild West out there.....<br>
<br>
And the definition of The Internet is still elusive.  I agree that the<br>
users' definition is the best working one -- The Internet is the thing<br>
I'm connected to to do what I do when I get "on the Net."<br>
<br>
Fascinating to watch this over 50 years...who would have thought it<br>
would last this long?<br>
<br>
/Jack Haverty<br>
<br>
<br>
On 11/7/19 7:29 AM, Dave Crocker wrote:<br>
> On 11/6/2019 4:08 PM, Jack Haverty wrote:<br>
>> The flaw in my definition of computers talking to computers comes from<br>
>> the tweaks added to the technology well after TCP/IP itself -- things<br>
>> like firewalls, port forwarding, NAT, et al.  When I worked at Oracle,<br>
>> we ran our own internet, which had thousands of computers attached that<br>
>> could all talk to each other.  But only one of them could talk out to<br>
>> the rest of the world.<br>
><br>
><br>
> Here I'll disagree.  Nothing about those additional components gets in<br>
> the way of your definition.  (That's written as an small, implicit pun.)<br>
><br>
> In spite of the changes those components effect, the computers at the<br>
> end points still interoperate, which is what your language specifies.<br>
><br>
> As for the Oracle example, I'll suggest that it merely demonstrates<br>
> that 'the' Internet includes other internets, and that while true, I<br>
> don't offer it as much of an insight.<br>
><br>
> As for the strong reactions Internet architecture purists have about<br>
> these additional components, mostly it seems to stem from a failure to<br>
> appreciate the operational importance of administrative boundaries. <br>
> For some reason, we think it fine to have those when doing global<br>
> routing, but not for other aspects of transit data processing, in<br>
> spite of the continuing and pervasive demonstration of their need.<br>
><br>
> I'm never any good at attributing quotations or getting their wording<br>
> right, but there was long ago an observation that a law, which is<br>
> violated by a large percentage of the population, is not a very good<br>
> law.  The same logic applies to architectural purity criticisms of<br>
> NATs, etc.<br>
><br>
> d/<br>
><br>
<br><br><br>---------- Forwarded message ----------<br>From: Jack Haverty via Internet-history <<a href="mailto:internet-history@elists.isoc.org" target="_blank">internet-history@elists.isoc.org</a>><br>To: <a href="mailto:dcrocker@bbiw.net" target="_blank">dcrocker@bbiw.net</a><br>Cc: <a href="mailto:internet-history@elists.isoc.org" target="_blank">internet-history@elists.isoc.org</a><br>Bcc: <br>Date: Thu, 7 Nov 2019 11:22:39 -0800<br>Subject: Re: [ih] inter-network communication history<br>-- <br>
Internet-history mailing list<br>
<a href="mailto:Internet-history@elists.isoc.org" target="_blank">Internet-history@elists.isoc.org</a><br>
<a href="https://elists.isoc.org/mailman/listinfo/internet-history" rel="noreferrer" target="_blank">https://elists.isoc.org/mailman/listinfo/internet-history</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font face="verdana, sans-serif" size="2"><font style="color:rgb(136,136,136)"><a href="mailto:Geoff.Goodfellow@iconia.com" target="_blank">Geoff.Goodfellow@iconia.com</a></font></font></div><div dir="ltr"><font face="verdana, sans-serif" size="2">living as The Truth is True<br></font></div><div dir="ltr"><div dir="ltr" style="color:rgb(136,136,136)"><div style="display:inline"><font face="verdana, sans-serif" size="2"><font><a href="http://geoff.livejournal.com/" target="_blank">http://geoff.livejournal.com</a>  </font></font></div></div><div dir="ltr" style="color:rgb(136,136,136)"><div style="display:inline"><font face="verdana, sans-serif" size="2"><br></font><div dir="ltr" style="font-family:arial,sans-serif;font-size:12.8px"><br></div></div></div></div></div></div></div></div></div></div>