The NES boxes use a firefly algorithm to encrypt unclassified data, pass it over the classified packet network, and decrypt it on the other side, where it gets routed onto the DDN and evetually onto the Internet.
I'm a U.S. Army officer stationed in Darmstadt, Germany and forward deployed to the former Yugoslavia. Soon after coming to Europe in 1994 I discovered the “Linux Revolution” and have looked for innovative uses ever since. My first opportunity was with my unit in Darmstadt: I converted an unused 80386 machine with 8MB of RAM and a 120MB hard drive into a router/mailer/WWW server. Its primary purpose was to route packets between the 10Mb/s Ethernet and a 19.2 kb/s SLIP link into a DDN termserver. In the 20 months since it came on-line, it has never failed to provide reliable routing and dependable e-mail service.
When the US Army deployed to Bosnia as part of the Implementation Force, we brought with us a complex, impractical data lifeline. The backbone of Army tactical communications is a system called Mobile Subscriber Equipment. It provides between 13 and 58 secure, encrypted digital voice trunks and 16-64KB of encrypted data trunks. Every headquarters has a communications shelter outside with a BBN T/20 packet switch that routes TCP/IP traffic onto an X.25 packet switch network, effectively creating a giant, secure Class B network spanning all of Northern Bosnia.
The unsecured, unclassified portion of the network is provided by Motorola Network Encryption System (NES) boxes scattered throughout the theater. The NES boxes use a firefly algorithm to encrypt unclassified data, pass it over the classified packet network, and decrypt it on the other side, where it gets routed onto the DDN and evetually onto the Internet.
The plus side of this arrangement is Internet access to the soldiers in Bosnia. Originally, we intended to use the system to pass logistical and other non-sensitive data to the supporting elements in the rear, but it provided a way to pass non-sensitive data and morale e-mail as well. The pipelines are small, and the amount of data forced down them is huge, but it has proved to be an effective, if unwieldy system.
As the signal officer for one of the twelve US Brigades in Bosnia, I am responsible for the care and feeding of approximately 100 desktop and laptop computers, all running Windows for Workgroups with the Microsoft TCP/IP stack. The physical layout of the network at our Brigade Headquarters is quite tenuous: two 250m 10Base2 segments with 30 computers on one and 6 on the other, joined by an Ethernet repeater. In the rough and tumble military world, it's almost a full-time job keeping the cable and all connectors together, dry, and passing data.
The Linux solution stems from the need for a centralized SMTP gateway and information warehouse. The machine is a Pentium 166 sitting on an Intel Atlantis motherboard, with 512KB of cache and 64MB of RAM, with just under 2GB of storage. I'm running kernel version 1.3.100, completely ELF and modularized.
Before I came on the unit, Pegasus mail (a free POP3-based mail client for MS Windows) was used to retrieve mail from various e-mail hosts in Germany. Because of the low bandwidth, users were waiting 5-10 minutes to download just a few messages, and users' mail was “trapped” on the computer used to retrieve messages.
My solution involved the Samba package coupled with the security built in to Windows for Workgroups. I used Samba to export the /home directory of the server, and created user accounts for everyone. The Pegasus mail executables and library files were put in the /home directory with 640 permission flags and root:users as the owner:group. Windows users were then instructed to attach (in Windows parlance) the \\MAILSERV\MAIL share as their M: drive. The Pegasus initialization file required that I use a static drive label (M:, for mail) The user then created an icon in Windows pointing to the M:\WINPMAIL.EXE file.
Adding users was tedious until I broke down and wrote a Perl script to create the entry in /etc/passwd and personalize a generic PMAIL.INI file that was copied over from the /etc/skel directory.
The result is a secure, seamless e-mail server that allows users to log in using the familiar WfW login prompt and run a common e-mail client from any PC on the network. Pegasus uses POP3 to download mail from the Linux box, then stores the mail on the Linux box in the user's home directory. Outgoing mail is sent to the Linux machine for delivery; unreliable links and slow network response made it too easy for a user to leave mail stuck in the outbound queue when he shut down the e-mail client.
One additional advantage of the Linux box on my network is that I can run my own name server. I began with Nicolai Langfeldt's caching named mini-howto and set all my Windows clients to point to the Linux machine as a primary DNS. I discovered that a significant chunk of my bandwidth was disapearing due to net surfers. I tried to limit the number of browsers my users had, but I found it was easier to send the browsers bogus IP addresses for certain “unsavory” sites that shouldn't be visited with a government computer. I told my named to return the IP of the Linux machine, and created a web page to scold my serious offenders. Everyone got a chuckle out of it, and I got my bandwidth back to a usable level.
I have also been able to provide a whois server for a sizable chunk of the deployed soldiers with e-mail accounts, and an intranet web site with photos and info pertinent to the command.
The Samba programming team has put together an excellent package that allows me to cater to the users' demand for a Windows operating system without tying me to the propriatary e-mail and server programs of Windows NT. I look forward to future releases of Samba that will include domain services and validation, and I'm always on the lookout for new ideas and applications for Linux.