Innovators: How do you rise above the crowd?

[dfmischler]

How would John Doe solve design problems in the "X" product and be noticed/hired/whatever by a major manufacturer?

Most useful innovation occurs in small steps within ones area of expertise (i.e. you already have the job, and you came up with a better way to do it).  It is much rarer to come up with something disruptive that is a bit out of your area.

I admit that I was thinking about the time when I stumbled upon this approach to hiding an IP network behind a single IP address, and asked for opinions on the firewalls mailing list in December of 1992.  I was heavily involved in TCP/IP networking at the time, but this was not a problem my employer was interested in pursuing.  You probably all have systems that use this idea now, whether you call it NAT, IP Masquerade, or just let whoever built your router worry about it.  But as far as I know it was a new idea at that time.  Putting it on the firewalls list got me several valuable opinions back, and also widely disseminated the idea.  If I had intended to patent it then I guess that would have been a bad thing.  As far as I know I was the only one with a working implementation before 1994.

[coppice]

An interesting example is Microsoft Research. Microsoft started buying all kinds of talent to staff the place in the 1990's when they had more money coming in than they knew what to do with. I laughed out loud when a professor I was talking to called it "the roach motel of computer science". All these smart guys going in, nothing coming out. It was funny because it was so true.

Microsoft is an interesting place. However staid, and badly managed, and uninnovative a company is, there are usually little groups doing interesting things, skunkworks style - probably out of boredom most of the time. Its really hard to stop this happening, even though management frequently tries really hard. However, Microsoft has been so effective at stifling its own innovation that the only novel thing ever to come out of their doors was Bob.

[SirNick]

I admit that I was thinking about the time when I stumbled upon this approach to hiding an IP network behind a single IP address, and asked for opinions on the firewalls mailing list in December of 1992.  I was heavily involved in TCP/IP networking at the time, but this was not a problem my employer was interested in pursuing.

Wow, that is a cool piece of history right there.  I especially like this part:

I don't see any real problem in building the connection table, but I am not sure what rules to use for removing connection entries.  I don't think detecting normal connection closures will be a problem but I am concerned about all of the other possibilities.  I certainly don't want to remove a connection entry prematurely, but it could become a real security problem if an entry is not removed when it should be.

So, when you get around to finding the perfect alternative to UDP timeouts and SPI, let us know, OK?

[dfmischler]

I admit that I was thinking about the time when I stumbled upon this approach to hiding an IP network behind a single IP address, and asked for opinions on the firewalls mailing list in December of 1992.  I was heavily involved in TCP/IP networking at the time, but this was not a problem my employer was interested in pursuing.

Wow, that is a cool piece of history right there.  I especially like this part:

I don't see any real problem in building the connection table, but I am not sure what rules to use for removing connection entries.  I don't think detecting normal connection closures will be a problem but I am concerned about all of the other possibilities.  I certainly don't want to remove a connection entry prematurely, but it could become a real security problem if an entry is not removed when it should be.

So, when you get around to finding the perfect alternative to UDP timeouts and SPI, let us know, OK?

I didn't come up with anything better than that for my implementation.  In fact, you need timeouts on TCP connections, too (e.g. what if both endpoints of the connection reboot; the TCP connection will never see a FIN or RST so it will sit there forever if there is no timeout).  I stopped working on this stuff a long time ago (2000?  When I could buy a low-cost router with functional NAT and site-to-site VPN).  I find it interesting that if you read that first description of NAT you will not find any of the terms we now use to describe this stuff because they did not yet exist.

The on-topic part of this story is that I thought of these concepts and implemented them because nobody was doing it and I wanted the capabilities for myself.  The best "innovator" in the world will be stuck if he can't find any problems that he personally has a stake in solving.