RealSecurity

This book was published in late 2000 and took several months to write. The actual process of writing it was interesting. IPSec is actually the combination of many, many RFCs from the IETF, and there is no single document that covers the protocol from stem to stern. By the time I started writing the book I was very familiar with the RFC’s and had implemented, some on a very large scale, virtually every product that provided IPSec VPN services. However, while I was writing I was always concerned I would get something technically wrong. In my office I had printed out every RFC and draft related to IPSec and pasted each page on the wall! Yep – that’s right… IPSec wallpaper (it was a big office). Needless to say, I have nightmare images of those dang walls. I can still almost recite word for word those RFC’s.

I would write notes in the margins and would use a marker to draw lines from one section of an RFC to another, with a few actually going all the way around to the other side of the room. Above the line I would write a short “article” to myself explaining the connection, why it was important, and the technical elements. The result was a huge map of the standards with roughly 50 1-2 page documents explaining the connection. Interestingly, none of these notes made it directly into the book. I only wanted to influence my writing and not become a collection of notes. The documents were additional reference material to myself to support my writing. An odd tactic, but I think this is why there are some interesting points made in the book. So, from that perspective, if you’re looking for how put all that “stuff” together and make connections between the RFC’s and understand the nuances, read the book:) Now that I think about it… those notes would make a great blog post (if I can find them).

I wrote the book for several reasons. First and foremost there wasn’t a whole lot out there other than the RFC’s, which, again, are not all that obvious or easy to digest. At the time I was doing a lot of design and implementation work with VPNs. In fact, one of these (at the time) was the largest in the world and I was trying to do things that no one had really tried or thought of. For example, VoIP over IPSec, or off-loading non-essential services and other things, such as e-mail that were not extraordinarily time sensitive, but consumed expensive internal Frame bandwidth.  In one case I was encapsulating routing protocols and using VPNs to hide the “real” network from the routing tables. I know, sounds odd, but there were some interesting benefits concerning failover and other things. Needless to say, you don’t have to do silly stuff like that today.

In fact a little story for you. When working on the global VPN solution Cisco became involved as the platform provider. The customer had several significant requirements and Cisco’s implementation of IPSec was still in development. As a result I spent several weeks in one of their huge labs in Cisco City to work through the solution. Each day we would find gaps, define changes to the IOS, and during the night programmers would make updates and deploy the updates to the lab. The next morning we start the process all over again. At the end of one of the days everything worked as planned, it was pretty satisfying. So, on the last day – seeing we had all this killer equipment at our disposal – we started playing around. I saw this server sitting in the corner, which does stand out in a lab full of Cisco gear, that was running a very early version of what we know today as call manager. Like any good room full of geeks, we plugged it into the VPN and started making VoIP calls – probably the first ever of its kind. We did a lot of stuff like this, played with GRE and routing protocols and tested some other concepts. I will look back at that time in the lab as some of the best “fun” I’ve had. Lastly, the people at Cisco were simply awesome… great people, very smart.

I’ve found this book used as a reference in more than 250 other articles and books from universities, VPN product companies (Cisco, Microsoft, etc.), service providers, and even in standards, such as NIST’s SP’s and IETF, and on ISACA’s K-NET. As with my Ethical Hack book, I was pleased to find references used in IEEE articles. Interestingly, many of these works expound on security and secure communications as it relates to other technologies, which I think is a testament to the versatility of IPSec.

I will be the first to say that there have been some mixed reviews. Most have been of a positive nature, but comments concerning how it was written, poor grammar and the like. It was my first book and I was very focused on getting the content out of my head. Well, I guess some feel it didn’t make it to paper very well. One commenter took me to town because I spelled out PIN (personal identification number), but didn’t for CHAP and PAP. The funny thing, is he is right, of course, but in a book jammed packed full of acronyms you start to forget if you spelled it out or not in earlier chapters. Minor error in my humble opinion.

Nevertheless, I believe my grammar is getting better, but I know I have a ways to go before I’m perfect. The problem I have is I write and don’t look back, which you can probably tell on my blog. Anyway, I don’t really do that anymore and I think that’s why the Ethical Hack book came out so well.

I did find two reviews (comments) that were really harsh concerning the technical elements, which I immediately gravitated to because – well – it’s a TECHNICAL guide. Interestingly, turns out one of the comments actually came from someone I know. Long story short, we sometimes create enemies in life and in work, and this particular individual went on a little anti-Tiller campaign. Such as life, I guess if you don’t make a few enemies along the way you’re doing something wrong.

However, the other I didn’t know, but absolutely thrashed me on non-IPSec related elements in the book. For example, I didn’t explain very well and made errors in discussing RARP, L2TP, PPTP, and DHCP- and that I left out a bunch of other protocols. Of course, I find this interesting for many reasons. First, the book was about IPSec… nuf said. Second, I only added those in a chapter where I introduced that there are other VPN related protocols and it wasn’t meant as providing technical details. Lastly, I actually pulled all the text about other protocols because of these very points, but at the last minute put them back in. Later, he did say he didn’t like that I talk about NAT translation without showing port translation. I can defiantly see his point. However, at the time the book was written, in the world of IPSec, NAT was the overarching method; PAT wasn’t incorporated in products for a while after. In short, no one was really doing it and many of the same rules concerning header fields applied. An omission on my part and a valid point by the commenter. The only unfortunate thing about the commenter is that he stated he was an expert in these other protocols and because I made mistakes and omissions he felt the other chapters on IPSec  - I suspect – would be wrong as well. If you’re reading the book, rest assured that is not the case. My discussions on the other protocols were meant simply as “Hey, these exist,” and not as a technical guide to RARP, hence the title of the book.

One day I received a note from an author of a different VPN book where they highlighted that I used the same graphic of a header to explain two different, but similar scenarios. So, one graphic is technically inaccurate. Other than that, they offered praise for such a technically accurate book (and a few bits of advice on grammar:) Anyway, during the publication process images to be used as figures are separate from the manuscript and must be combined later. Either I used the wrong filename, didn’t update the graphic, or there was an error during copy setting… regardless, it happened, which is not a huge deal, but could be confusing to readers.

I’ve talked with many, many others in the security industry and people who work with IPSec as a technology everyday and I always find that my book is helping them in some way. Either as a reference they can leverage from time to time, or something they use every day to deal with tactical challenges.