[1168] in Commercialization & Privatization of the Internet
Re: Who wasn't at IETF.
daemon@ATHENA.MIT.EDU (Erik E. Fair" (Your Friendly Postm)
Tue Aug 13 03:58:05 1991
From: "Erik E. Fair" (Your Friendly Postmaster) <fair@apple.com>
In-Reply-To: <9108130540.AA01164@rivendell.us.oracle.com>
To: Jack Haverty <jhaverty@us.oracle.com>
Cc: Gene.Hastings@boole.ece.cmu.edu, ari@mordor.stanford.edu, com-priv@psi.com,
Date: Tue, 13 Aug 91 00:56:27 -0700
Jack,
I think that the question was phrased to imply that "network
operator" meant the regionals and nationals, not us corporate types.
However...
>From my point of view, participation in the IETF is well worthwhile (I
just got back from Atlanta), and I am the operational side of Apple's
Internet connections, although my purpose in attending Atlanta IETF was
to contribute to the E-mail and NNTP standardization discussions (and
listen in on anything else that struck me as interesting).
As for whether the IETF is addressing our needs, I'd say that in
general, they are, although there are blind spots. If you believe that
the Internet is an existence-proof of the scalability of TCP/IP
networks, then it behooves one to do things internally the same way as
things are done on the Internet, e.g. use the DNS instead of host
tables, MX records for E-mail, etc. (this also helps a manufacturer
like us; to the extent that our internal environment where development
is done resembles the Internet, our TCP/IP products should work
correctly when they escape here to the Internet, and, yes, part of why
we're on the big-I Internet is to test forthcoming stuff). We're
already the size of a small regional network - 102 IP subnets,
stretching from Tokyo, Japan to Paris, France (and that's just
Engineering; the corporate types have another 70 IP subnets of their
own).
I learned a number of things in Atlanta that will be important for
Apple to consider in the coming year or two for our internal and
external internet (they are subtly linked - they are not entirely
dependent or independent - such is the nature of a security firewall).
W.r.t. your personnel problems, I'm afraid for any reasonably sized
network, you're gonna hafta have a guru somewhere (either hired or on a
consulting basis) to fight the serious fires, and do your network
design. You can only run a network with just wire jockeys for so
long. This goes double for the regional networks - which is why
network wizards are in demand.
I'm hoping that one day, the Internet community will provide
authentication and encryption technology strong enough that we can open
up our internal network to the Internet just like a typical university,
but with the confidence that our proprietary information will not be
compromised, and I'm working on cleaning up the operational details of
our internal network so that such a decision is possible (that is, we
can open up without siginificant pain after the security issues are
dealt with). In part, this means that we must track what goes on in
the IETF.
Our biggest problem is not with the IETF, but with the various TCP/IP
vendors - their systems usually come default insecure, and default
configuration for an isolated LAN (which is to say, it is messy to
configure most systems for correct interoperation on the Internet, or
any reasonable facsimile thereof (which we believe our internal
environment is)). To the extent that we trust our firewall (and our
employees), security of the internal systems is less of a concern (and
less of a pain) than the "isolated LAN" default configuration problem.
One item which makes this message com-priv related is that all of the
commercial IP service providers would like to carry Apple's internal
network traffic. At least, they have all said so to me at one time or
another. We don't trust any of them enough yet to do it, whereas we do
trust the phone companies to provide us with relatively secure bit
pipes (slight contradiction there, which I will explain). We really
don't know exactly what goes on between the DS0 or T1 D-marks, but the
venture for a leased line is cooperative only to the extent that we get
the timing and ones density right from both ends, and there has never
been any question about the phone company hooking our bit pipes to the
wrong places (e.g. to the wrong company). It's hard enough to get a
leased line to work to the right place...
TCP/IP routing is a much more cooperative affair between the service
provider, and the customer, and we (customer) know exactly what router
technology (and the limits thereof) that the service providers are
using at present. This is what makes me mistrust the existing IP
service providers where my internal traffic is concerned. Until more
effort is put by the IETF and the router vendors into robustifying and
securing the routing system so that I can believe that my IP traffic
won't be misrouted (either accidentally or intentionally) into the arms
of a competitor, we will not move our sensitive internal traffic over a
commercial IP network (and this presumes that the POPs are physically
secure too). This concern tends to limit the commercial IP service
market to inter-company collaborative links, which (I'll bet) is not
where the big bucks are (although hopefully it will sustain the
commercial IP service providers until the technology improves).
Erik E. Fair apple!fair fair@apple.com
P.S. A completely separate issue: we need to keep the bozos away
from the IETF. I don't have a solution for this (serious)
problem. Simply stated: as long as the IETF is open to anyone,
and operates on a consensus basis, it is open to being overrun
by idiots and connivers with axes to grind. We need to think
hard about good people filters.
