2003

A History of the PIX

ABrief Introduction

My names is Brantley Coile and in 1994 I co-founded, with John Mayes, Network Translation, Inc, to produce and market our new creation: The PIX Firewall. We sold the company to Cisco in 1995, and soon after I was no longer involved with the day-to-day support of the PIX, but most of what you see in the PIX today, we did.

 

A few weeks ago I bought a copy of your excellent book. It is very nice to again see names that I created, like PIX (Private Internet eXchange, a play on Private Branch eXchange) and Finesse (Fast INternEt Server Executive).

 

I get a real thrill in knowing that people are still finding my work useful.

 

I would recommend your excellent book to everyone who has a PIX. Great work.

 

And Now the History Lesson From Brantley

In, 1990 John Mayes and I worked together to embed Unix into the Adaptive STM18 DS3/DS1 intelligent MUX. He had worked for NET, Adaptive's parent company, setting up the company's development network and was looking forward to getting into development himself. We really liked each other and worked closely together.

 

By 1992 we had both left to pursue our own dreams. I moved back home to Athens, GA and he was fast becoming the most sought after systems admin consultant in the bay area. About 1993 we had both hit a wall; he was working 19 hours a day and falling behind, and I was finding the Atlanta market far behind CA in it's acceptance of consultants. We both, independently reached the conclusion that we must have a product to sell other than simply ourselves.

 

In the spring of 1994, John asked if I could solve a problem for one of his customers: years before when the customer had installed Sun Systems they made up their own IP addresses for their networks. They never dreamed of being connected to the public. Now they wanted to be on the Internet. I didn't see why they couldn't if I changed the IP addresses on the fly using some sort of appliance and fix up the checksums in the headers.

 

At first this was going to be a program running under SunOS. I thought better of that and then it was going to be run under BSDI. The more I thought about it the more it seemed to me to be unnecessary. The job just didn't need timesharing; it was more like a router really. I decided to write the code directly on commodity

Intel hardware.

 

I was working on consulting contracts, so it took me a while to get serious about it. I started pulling things together in the late summer. The actual coding wasn't the big effort. Keeping myself from going off on a tangent was hard.

 

I checked the RFC index as usual but couldn't find any reference to what I was trying to do. There was an entry reserved for RFC 1631 but it didn't show a title or any other information. Late in 1994 someone told me that there was already an RFC about something called NAT. I found a copy and was pretty excited. We both had done almost the exact same things, run into the same problems and come up with similar solutions. Theirs wasn't concerned with security, so our PIX was truly new in that respect. But it makes the solitary programmer feel not quite as alone to see that someone else has also been in the same mental space.

 

I suggested the name PIX to explain how you could have more internal hosts than public IP addresses. The global addresses were like trunk lines and the local addresses were like extensions. The analogy to the PBX seemed obvious. John was torn until he used it to explain what our box did for a group of lawyers. He called back saying the name worked great! It was the PIX from then on!

 

In November 1994, we beta'ed at KLA instruments without a single bug. (There were some, but we found them before the customer did.) The PIX was one of Communications Magazine's products of the year.

 

The earliest PIX had the core features of today: adaptive security,

conduits, global address pool, static xlates, TCP/UDP fixups. It became obvious that the PIX was also a firewall. The data structures that are required to do NAT were perfect to implement what I called a connection diode. Next I added VPN with the private link. Just after we were purchased by Cisco I came up with the idea of UnProxy--what is now called cut-thru-proxy.

 

The failover scheme occurred to me during the beta test of the other Cisco product John and I did, the LocalDirector. The customer would not put the LocalDirector in line with their web servers for fear a failed LocalDirector would take their site down. I had to think of a way to do failover and get it to them in a very short time. Custom hardware was out of the question, and that was the only way I had ever done failover. So, I looked at what was left unused on the equipment and saw the extra serial interface. The active could reassure the standby by sending short messages over the serial cable. But how would it know if the other machine had failed, or was just unplugged? The Cable I came up with worked and was installed at the beta site in the next day or two. So, I now have a patent on a cable!

 

In 1995 we hired Rebecca Jepsen as VP of marketing and sales really started to grow. By late in the year we had sold several million dollars of PIX and John met the CTO of Cisco at a party. In December I happily found myself Cisco employee 6877. I stayed with Cisco for the required two years and left to continue pursuing new challenges.

 

One story I like to tell is about when the folks at SRI in Menlo Park wanted to evaluate the PIX along with lots of other firewalls. We packed them up a PIX and had it sent over. A few days later they called and asked what were we going to do with this particular box when they were finished? We couldn't sell it now, could we? Might it be possible for them to keep it? I asked what for? They said they wanted to use it as their firewall. Can't get a better eval than that!

 

It thrills me to see the PIX still kicking. It was designed to do one thing well. While it doesn't run on Unix, it is really the Unix philosophy applied to the task. It was meant to run as close to wire speeds as possible. It didn't have great numbers of settings. It was meant to be easy to install (4 commands on the original), not require attention, and just do it's job, quietly and effectively. It was also meant to have a very simple policy model that was easy to understand. How can one feel secure when the basic model is complicated. How can anyone feel secure behind a firewall made from Unix or windows?

 

I ran one of the original PIX here in my Athens, GA lab until last year. The PIX didn't have PAT until late. My version never had it. When my service provider said they could no longer support my full class C network I had to replace the PIX with some new code I wrote that just does PAT. I call it NIX. PIX does NAT, NIX does PAT. NIX is not a product, it's just for me.

 

I've left lots of stuff out of this. I'm working on a new storage product, like everyone else it seems. Still I don't worry. There were firewalls before the PIX. Just not ones like the PIX.