Subject: Re: Yahoo goes commercial -Reply From: Rex Ballard Date: Mon, 8 May 1995 22:34:58 -0400 (EDT)
How the Web Was Won
Subject: Re: Yahoo goes commercial -Reply From: Rex Ballard Date: Mon, 8 May 1995 22:34:58 -0400 (EDT)
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
X-Status: 



On Mon, 1 May 1995, Tony Tancredi wrote:

> Rex,
> 
> A year ago, when I first contemplated the mechanics of
> connecting to the Internet, I envisioned a new Internet node
> acting as an intermediate link in a chain.  If you were a new
> node you would connect to two existing nodes (call them
> Node 1 and Node 2).  Packets wanting to go from Node 1 to
> Node 2 could route through your node.

For many years, that was exactly how it was done.  There were actually 
about 5 IP "backbones" and they were redundanly linked.  IBM went from 
Poughipsie to Boulder, DEC went from Boston to Colorado Springs, HP went 
from Longmont to Colorado Springs to California.  The "NSF link" went
from Boulder to Longmont, and under 3000 feet of Centennial Drive in 
Colorado Springs.

> I found out that this method was not often, if ever, used. 
Today, with all of the security issues, it is not a frequently endorsed 
practice.  I have worked at 3 companies where the SysAdmin refused to
enable IP routing, and only discovered that people were "Slipping in" 
through the Terminal Server, when one discovered that certain frequently 
used telephone numbers were actually internet providers.  When he added 
up $2000 in phone bills, he couldn't wait to connect everybody to the 
Internet, eventually, the terminal servers were unplugged and 
kerberos/encrypted TCP/IP became the only way in, and firewalled TCP/IP, 
the only way out.  Properly managed by someone who really knows Unix and 
TCP/IP, the security for the internet is BETTER than the security of a 
modem/dial-up.

> Finding this out was not straightforward.  The people at my
Of course not.  Many SA's try to threaten immediate suspension or 
dismissal upon discovery of connection to the internet.

> company who handle our Internet link did not know the
> labyrinth linking my company with other nodes on the Net.
This is normal.  I you try to block the door, they will come through the 
window.  With TIA, they can come in through the cracks in the floor, and 
you would never know.  Full internet availability is actually a way of 
providing better tracking (who connected from what host).

Most of the security problems come from what were originally called "slut 
servers and bastard clients".  A slut server will accept a connect from 
anything.  A bastard client is a proxy which accepts connections from one 
hosts and forwards them unaltered to a remote host.  We have more polite 
names, but the terminalogy actually describes the solution.

The solution to a slut server is to make sure that the server validated 
the socket address of the caller before accepting the listen, or before 
processing the receivefrom(udp).  The solution to the bastard client is 
to pass around a session identifier and a pseudo-random number which is a 
product of exponentiation/modulus synchronized random number generator.

Unfortunately, the exp/mod algorythm actually constitutes an encryption 
scheme (because the prime numbers are "keys").  The RSA algorytm was 
originally published as this type of pseudorandom number generator, but
the encryption scheme becomes trivial once you can sync the generators.

> All they knew was that we connected to an ISP.  Upon
> calling our ISP I discovered, also not straightforwardly, that
> the ISP connected to a bigger ISP.  Presumably the bigger
> ISP was part of CIX or the equivalent.

Yes.  Up until they "pulled the plug on the NSF", the "Official Backbone 
of the Internet" was actually reduced to a series of routers which 
connected AT&T, Sprint, MCI, and BT at about 30 different BOC switching 
offices.  AT&T used ATM, the rest use primarily frame-relay.  From there, 
the administrative hassles of dealing with customers 1 on 1 is handled by 
the various internet providers.  The cost ratio is about 3/1 for a 24/1 
return on the telephone lines (pay 3 times more, get 24 times more 
bandwidth).  Businesses can connect directly to protected IP backbones 
through Sprintnet, AT&T Accunet, or MCI, but the buyer has to really show 
that they know their stuff.  Otherwise they preferr to let the IAPs 
handle the Firewall/Router/CSU/DSU issues.  The "guppies in the pond" are 
the little "internet bbs operators".  These operators tend to support 
about 22 dial-ups and 2 56kb links through one fractional T-1.  The 
start-up costs are steep - about $10-20K.  But the expenses are low 
($1000/month) and the income can be great ($3500/month).

> After reading your post, I started thinking that although my
> original concept does not reflect the way people hook up to
> the Net now, perhaps it does reflect the way they hooked up
> in the days between ARPA and NSF.

Actually, your labarynth was trivial compared to the original ARPA-Net.
There were no "routers", traffic was routed through every kind of "mutt 
and jeff host and link" imaginable.  To get to an IBM mainframe from a 
DEC system, one might have to go through a PDP/11 running Unix and a 
System/36 just to support the async to SDLC links between them.
TCP/IP let each host/gateway speak their proprietary link protocols, and 
provided the IP layers to the end-points.

> Would you please describe how new nodes hooked up to 
> ARPANET and how this method changed as the Internet
> evolved to its current state?

Actually, the three biggest changes were result of work I did.

At Federal Express, I ran a $1 Million research effort to come up with a 
LAN/WAN solution that would connect an IBM Mainframe, PCs (XTs yet),
VAX/VMS, Sun Unix, and Apollo, into a cohesive network.
	IBM would talk to the PCs, but wouldn't talk DECnet.  They did TCP/IP
	IBM would do PCs, but wouldn't do SNA (full function). They did TCP/IP
	Apollo did their token ring but ONLY TCP/IP
	Sun did SNA, and ethernet, but not decnet.  They did TCP/IP.
	Novell did IPX but not to IBM, VMS, or Apollo.  They did TCP/IP.
	3Com did Lan Manager -  but not to Apollo or Unix. They also did TCP/IP
	Banyan did VINES, and could convert that to TCP/IP.
	Everybody was going to have OSI "real soon", and they still couldn't even
	talk via X.25 (after the Zap-Mail fiasco, they didn't want to go 
	down that tunnel anymore.

In other words, the only product that was working, was TCP/IP!  
Unfortunately NONE of the vendors actually wanted to SELL TCP/IP.  Each 
wanted their lock on the market.  I made my reccomendation and shortly 
thereafter left the company.  Within two months after I left, they not 
only adopted TCP/IP, but made UNIX their primary platform of choice.
With a blessing like that from the company that was supposed to be the 
Flagship Demonstration of ISDN/X.25, corporate America took notice.

I then worked at Great West Life, where I quickly gained the attention of 
the chairman of the LOMA committee that was trying to define 
infrastructure (Protocols, Operating Systems, APIs...).  I wrote several 
draft reccomendations anonymously and he signed them and with his skill 
at working with people, directed the entire insurance industry to move 
toward an "Open Systems" environment (TCP/IP, Unix, X/11, GPL...)

As the insurance industry went, so followed the Banks and the Financial 
Services industries (brokers, analysts...).  Meanwhile, I was able to 
talk to the regional director of Frame Relay sales for MCI.  After 
creating with him, the possibility of rapid frame-relay sales directly to 
TCP/IP routers, and the desirability of "one-way" access to the NSF, it
took him 3 days to convince the national VP to sponsor the NSF on the 
condition that they be allowed to use the links for coporate customers 
and give them access to NSF archives.

While all of this was going on, I was working for a little company called 
SoftTronics, creating a Windows based "Internet for Housewives and 
Truckers" package.  We did get a substantial number of shareware 
downloads and they still offer a very low-cost NFS package.  We invited
many companies to try it out.  The result was that trumpet, winsock, and 
Mosaic "beat us at our own game".

At Dow Jones, I spent a year leading a design effort to create a "Dynamic 
Simplified ASN.1" as one of the senior managers was participating in the 
SGML work.  My work was given to several others who converted my "Dynamic 
Documents" into SGML expressions and extensions.  I also began 
contributing to the online-news groups at it's inception.  For over a 
year now, I have been advising over 4000 readers on approaches to 
publishing on the Internet.

What's in the future:

When ISDN becomes available, the little BBS operators can just connect 
24 raw 56kb links and simultaneously handle about 200 customers (ISDN 
calls are so fast that the circuit can be reestablished in 1/10th of a 
second.  Frame relay and ATM can go even faster.  We may be seeing "the 
works in a card" and "the works in a box" which includes Firewall,
Router, PBX (for voice service), and CSU/DSU in a box the size of a modem 
that just bolts to the inside of your house (near where the "phone line 
comes in") and gives you a multi-line phone and one ethernet connection.
The cost will initially be about $400, and will drop to about $100 within 
1 year.

Also in the future will be the need to automate data-base production and 
layout production.  SGML (or an extension) will lead this trend.  This 
will enable scanners and indexing systems to scan the web and produce 
databases in real-time.  EDI and SGML will merge or become 
transformations of each other.  We will see about 20 million pages 
available within 1 year, and the Internet will be a multibillion dollar 
industry in which the "major players" (Microsoft, Adobe, Netscape) will go
broke trying to buy control of the internet, and GPL software, supported 
by on-line publishers not wanting to be "locked out or starved out" by 
MSN will become the most widely used software (under 30 different trade-names).

> Thank you.

> Tony Tancredi
> Reality Online

	Rex Ballard
	Standard & Poor's/McGraw-Hill
	Opinions expressed do not necessarily reflect
	the Management of the McGraw-Hill Companies.


From rballard@cnj.digex.net Mon May  8 22:49:21 1995