Live WireNew England Telephone brought the 56-Kbps leased line this week: two pairs of copper wire that terminate in BYTE's ground-floor phone closet. At that point, the baton passed to Larry Graffam, our regular telephone-wiring contractor. Six years ago, Larry and I built BYTE's first twisted-pair LAN, and sometimes we still meet on the virtual border that lies somewhere between telephony and data networking. Today he's extending the new circuit to our third-floor computer room. "I don't know what a CSU/DSU is," he says. "Just tell me how to wire the jack." "Straight through on pins 1, 2, 7, and 8," I guess, trying to recall what worked when we connected the 56-Kbps X.25 link to BIX. The lights on the CSU/DSU (channel service unit/data service unit) flicker, but the link only sputters and won't catch.
We perform the ritual scratching of heads, wiggling of plugs, and swapping of wire pairs, all to no avail. A call to MV Communications, our service provider, reveals that our box can answer, but not call, its remote partner. Larry troops back downstairs and soon returns with the solution. The RJ-45 jacks he's used in the past for 10Base-T pin out differently than the RJ-48 that New England Telephone brought. Larry installs the RJ-48 jacks, the CSU/DSU lights up like a Christmas tree, and we have a live digital circuit.
Along with the CSU/DSU that serves as our site's interface to a physical data network, we need a router. MV supplied a Livingston PortMaster, which I now fire up and connect via serial cable to the CSU/DSU. From an NT machine on a dial-up PPP link to the Internet, I ping the address that MV had configured into the router, and it responds. But does that address really correspond to our router? To find out, Ben Smith at MV's Peterborough POP (point of presence) verifies that the Internet protocol traffic that I'm sending maps to the data circuit between there and BYTE. The router is on a live IP link to the Internet, so MV can Telnet into and configure the Ethernet interface we'll use to access the link. From its pool of Class C addresses, MV fishes out one for us and assigns one of that network's 254 usable addresses to the router's Ethernet interface. We're up and running.
Two Schools of Thought
Now that we're operating a public Class C network, how should we use the remaining 253 IP addresses? Of course, we will use one for every machine that provides WWW (World Wide Web), FTP, or other externally visible services. At first, we'll most likely start with a single machine running as both www.byte.com and ftp.byte.com. Later, we might dedicate a machine to each of these services, and perhaps mirror services on additional machines. However, there are lots more LAN clients than servers, and the question is how to get them onto the Internet. There are two schools of thought in this area:
1) Public networking. This vision inspired the design of TCP/IP. Every node has its own globally unique IP address and can converse on equal terms with all other nodes. But to label IP nodes as "hosts" betrays assumptions that predate LANs and desktop computing. Hosts that run Internet services for users at terminals are nothing like Windows or Macintosh hosts that run their own TCP/IP stacks and applications. These desktop systems are personal Internet endpoints on which users can deploy their own Gopher, FTP, or WWW servers. Slick, but can you expect everyone on your LAN to use these rather sophisticated tools well? This crucial question leads to the second (and dominant) school of thought:
2) Private networking. With a private network, you set up gateways, firewalls, and routers that regulate the interaction of your LAN's clients with the outside world. Global peer-to-peer networking often isn't the right choice for corporate LANs. Companies provide Internet services, but most individuals don't really need those capabilities (at least not yet). This asymmetry dictates that corporate servers live either on or outside a defensive perimeter and that LAN clients live within the boundaries.
Public networking means that we dole out one of our 253 addresses to each IP device on our LAN, and we're small enough to do that comfortably. Private networking means that we can use unregistered IP addresses, or none at all--two options that I've been exploring for a while.
Instant Internet, No IP Addresses
Performance Technologies' Instant Internet (see "Short-Order Internet Access," July BYTE) is a network appliance: a box that attaches to the network, powers on, and solves a hard problem so quietly that you forget it's there. Instant Internet connects LAN clients to the Internet by decoupling a popular Internet API--Winsock--from its normal TCP/IP substrate and grafting it onto IPX. This setup is convenient because it does away with client IP addresses, and it's secure for the same reason: no exposure of IP addresses or on-LAN IP traffic.
In fact, the security angle is a bit subtler. Winsock is, after all, an implementation of the Berkeley sockets API, and its basic unit of connectivity is not the host but the port. For Winsock client applications to work, they have to create and attach sockets to ports on hosts. Instant Internet uses a tweaked version of WINSOCK.DLL to make this happen.
The converse is also possible: Inside servers could offer ports to which outside clients could attach sockets. For example, a LAN node's WWW server listening on port 80 would answer connection requests from outside WWW browsers that aim at that port on the Instant Internet box. To prevent this, Performance Technology blocks the inbound use of such well-known ports, except for the SMTP port that you'd need to deploy an Internet mail gateway on your LAN.
NT Gateway, Private IP Addresses
The figure "An NT Gateway Between a Private Network and the Internet" shows the other solution that I've tried. A multihomed host (one with interfaces to two or more networks) routes IP traffic between the Internet and a private IP network. On the first try, I pinged a remote host from the LAN but got no reply. The NT box was the default gateway for TCP/IP clients on the LAN, so what was wrong? You guessed it: addressing. We've always used network address 192.1.1.0, the first Class C network, for internal IP tests.
Private use of this network number is an Internet folk tradition, and lots of these networks touch the official Internet. It's likely that the ICMP (Internet Control and Message Protocol) packets sent by my ping command reached the host, but to which 192.1.1.0 network should the host reply? When there are duplicate addresses, IP breaks.
The missing ingredient was a proxy server (an NT application) to relay messages between inside clients and outside servers. Process Software's Purveyor is one NT WWW server that offers this proxy capability. I installed it on a Digital Equipment Alpha machine running NT, pointed another machine's copy of Netscape at it (see the screen), and--Bingo!--the NT box instantly became a poor man's firewall.
Appliance vs. Gateway
I've tried both solutions for a few weeks on BYTE's LAN. The table above summarizes the pros and cons of each. Which is best? Sorry, but the jury is still out. We like Instant Internet because it gets results fast--after just 30 seconds, you're surfing the WWW. But a Windows-only solution ignores our Mac and Unix users. And the IPX substrate complicates the use of in-house WWW servers to manage private information. You can switch modes by swapping WINSOCK.DLLs on the fly; I do this, but I don't recommend it.
A traditional IP gateway, including our NT solution, requires a lot more up-front effort: TCP/IP stacks on every client, IP addresses all around, and applications configured to talk through proxies. But you can use Unix, OS/2, NT, or any capable OS on the multihomed host (if the necessary proxy has been ported to that platform), and options are equally bountiful on the client side. The gateway also doubles as an Internet server visible to the outside.
Traditional IP is truly powerful stuff. Of course, if we use it, we must decide whether clients get registered addresses or not. Is private networking an abuse of TCP/IP? The experts who hang out in BIX's Internet conference directed me to the RFCs (requests for comment) that frame this question. Details follow.
RFC 1597 vs. RFC 1627
RFC 1597, "Address Allocation for Private Internets," wants to reserve certain network addresses for duplicate use. Primarily driven by the desire to conserve precious address space and ease the administrative burden of IP subnetting (see "Linking LANs," December 1993 BYTE), the authors also note that private addressing enhances security.
Not so fast, say the authors of RFC 1627, "Network 10 Considered Harmful." We should expand address space the right way, by means of IPng (see "Create More IP Addresses," April BYTE), not by violating the principle of unique addressing that's the foundation of the Internet. Maybe you don't need direct, network-layer connections to the outside today, but you might well need them tomorrow. Apple found out the hard way, the authors say, when it had to renumber 5000 hosts. Why bother? "Apple, IBM, and Motorola could not collaborate as easily as they have to [in order to] produce the PowerPC without uniquely assigned IP addresses."
The process used to assign IP numbers is the crux of the issue. RFC 1597 argues that with an automated method--such as the DHCP protocol, in which clients boot up without numbers and receive IP addresses on the fly--you can easily switch between public and private addressing or synchronize two private domains. RFC 1627, however, questions DHCP's maturity and effectiveness.
As an experiment, I had our DHCP server (an NT 3.5 service) move the block of addresses it manages. The NT clients caught on after a reboot, while Windows 3.11 and 95 didn't. I scanned the INI files and registries but couldn't flush out the old addresses. This was on a Friday, and the leases on those addresses weren't due to expire until Sunday. So I took the weekend off, and the problem fixed itself on Monday. I later learned that you can break Win 95's DHCP leases with winipcfg, and Win 3.11's leases using ipconfig/release.
Obviously, DHCP works for us, and private networking seems easy, useful, and secure. But RFC 1627's argument is cogent. Business-to-business networking is on the way, and there's no point in throwing obstacles in its path. With that in mind, how should BYTE dole out its public Class C addresses? One for a gateway, or perhaps one for every LAN client? For now, we'll modify the first approach: just one address, and use a server connected only to the Internet. It'll be safe sex for a while, until I've studied the security issue more deeply.
I Outfox the Devil
The security tool named Satan probed our site in both the Instant Internet and NT gateway modes and gave it two thumbs up, for whatever that's worth. But you can't find what you're not looking for, and I doubt the Unix networking culture that spawned Satan understands the Windows networking conventions that Win 95 clients and NT servers follow.
Consider NetBIOS, the API and name service that enables file and printer sharing, NetDDE, and remote administration. One night I added some NetBIOS-name/IP-address pairs to Win 95's LMHOSTS file (see "Wide-Area Windows Networking," January 1994 BYTE) and dialed up the Internet using RAS (Remote Access Service). I found that I could NET USE drives on the Internet server back at the office and even remotely edit its registry.
You couldn't do that without my domain user name and password. But if you knew or guessed the name of the shared directory that I'd unintentionally left open to group Everyone, you could have plundered it. That's the kind of security hole that even Satan can't yet detect or climb through.
I'm pleased to report that the BYTE WWW site is coming along. We're currently putting images on the next BYTE CD-ROM, and you can try out part of the January issue on-line to get a feel for how it will eventually look. I've indexed the text archive using EMWAC's port of freeWAIS (Wide Area Information Service); used Folio's Infobase WWW server to export a preexisting BYTE infobase to the WWW; and tried out the Lotus InterNotes Web Publisher. Also, I am finding the WWW site useful as a channel for private communications between our home office and its satellites.
Finally, BYTE's original PC Unix server, reconstituted under BSDI 2.0 (thanks to Ben Smith), will be coming on-line soon. That will allow Ben and me to scope out how NT and Unix stack up as engines that power Internet sites and as platforms for WWW development.
WHERE TO FIND
EMWAC (European Microsoft Windows NT Academic Consortium) http://emwac.ed.ac.uk Folio Corp. Provo, UT http://www.folio.com Lotus Development Corp. Cambridge, MA http://www.lotus.com O'Reilly & Associates Sebastopol, CA (800) 998-9938 (707) 829-0515 http://www.ora.com Process Software Corp. Framingham, MA (800) 722-7770 (508) 879-6994 http://www.process.com
BOOKNOTE
Network Security: Private Communication in a Public World, $46.00 by Charlie Kaufman, Radia Perlman, and Mike Speciner Prentice Hall, 1995 ISBN 0-13-061466-1
Nuts-and-bolts explanations of all the important encryption and authentication regimes: what they are, why they work, and how they might not. Details on how NetWare, Notes, DCE (Distributed Computing Environment), and Microsoft networks implement security. All this, plus lots of laughs.
TOOLWATCH Aladdin Desktop Tools, $49.95 Aladdin Systems Watsonville, CA (408) 761-6200 fax: (408) 761-6206
Handy Mac utilities, most notably Desktop Shortcut, a utility that makes the Mac File Open and File Save dialog boxes smarter. As we began cranking out images for the BYTE CD-ROM, these dialog boxes became a major bottleneck. Desktop Shortcut remembers recently used folders and last-known positions in lists. Why can't Finder and Win 95 track this crucial context?
INSTANT INTERNET Pros -- Simple installation for NetWare (or Windows-over-IPX) users -- Secure--no IP on the LAN, inbound ports blocked -- Works with any 16-bit Winsock application -- Script support for dialer Cons -- Non-Winsock TCP/IP applications break -- 32-bit Winsock applications (e.g., Netscape 1.1 for Win32) don't work -- No local (i.e., LAN) use of TCP/IP -- No non-Windows access -- Client service only; can't run servers NT GATEWAY Pros -- Less expensive if a Windows NT server is already in use -- Secure--no inside unregistered IP addresses are exposed to the outside -- Allows local (i.e., LAN) use of TCP/IP -- Non-Windows systems (e.g., Macs) can use the connection -- Can run servers (e.g., ftp and WWW) Cons -- Requires a proxy server -- Applications limited to those supported by proxy server -- More complicated installation, even with DHCP to simplify addressing -- No script support in RAS (Remote Access Service)
NT's RAS (Remote Access Service) combined with a proxy WWW server is an innovative way for a small company to both export and import Internet services.
Point your browser at a proxy WWW server to get through a firewall or to hop from a private IP network to a public one. Be sure to refer all the client-side services that you care about to port 80 on the server. If you aim Netscape's FTP client at the FTP port (21) on the server--something I tried--it won't work. That's because a WWW server isn't an FTP server. The WWW proxy handles all the protocols, so all the action's on port 80.
Copyright © 1994-1995
