Systems Approach In 1996, Larry Peterson and I published the first edition of Computer Networks: A Systems Approach in the hope that it would become a widely adopted textbook in networking classes. Our draft manuscripts had been reviewed by a number of professors so we had a decent amount of feedback regarding the content and overall structure of the book.

But once the book was out in the world and the sales team at our publisher Morgan Kaufmann were given the task of driving course adoptions, we started to get a much greater volume of feedback.

Opinion was divided about the value of including the x-kernel as an instructional tool. Most people liked the fact that real, running code was included in the book to illustrate many networking concepts, which was central to our claim to having taken a systems approach to the field. However, many instructors also felt that the startup cost to get students using a very niche research operating system was too high. The x-kernel would move to an online appendix in the second edition.

The most consistent piece of feedback was not about the x-kernel, however, but about our total failure to include security in the first edition.

There were a few reasons for this, including our lack of specific expertise in security and the fact that security had long been something of an afterthought in networking - just ask Vint Cerf, who has over the years given various reasons why the internet had little to no security baked in when it was developed. So we set about filling that gap in the second edition.

The way I recall learning about security was from attending IETF meetings in the early-mid 1990s. (In retrospect this is a poor way to learn about almost anything other than the standards process.) The IETF was in the midst of defining the requirements for “IP Next Generation (IPng)” or what would become IPv6. (Thirty years later IPv6 is, er, well on its way to widespread adoption.) For example, noted security expert Steve Bellovin in 1994 contributed RFC 1675 to the IPng process, which contains the following:

and:

The “starting to experiment” comment is telling: The first IPSEC protocols would appear in RFCs a year later than Bellovin’s document. And firewalls were in the category (not yet named) of middle boxes, which many internet people wished would go away, since they seemed to violate the end-to-end arguments [PDF] on which TCP/IP was based. Bellovin in the quote above is displaying the same realism (and forward thinking) that Paul Francis advocated in his 1995 talk on NAT.

A related memory that I have from this time is that IPng was viewed as a once-in-a-lifetime opportunity to “fix” much that was wrong with IPv4. The list of things to fix was long, headed by the address space but included a laundry list of items such as confidentiality, authentication, mobility support, plug-and-play configuration, and so on.

Interestingly, as each of these issues was addressed in IPng, the equivalent capability was invariably developed for IPv4. Thus, while IPng added headers for encryption (to support confidentiality), message integrity and authentication, the same capabilities were being developed for IPv4.

Expertise

The key problem with my approach to learning about network security via IETF meetings was that I got a very bottom-up view: You learn about specific mechanisms when you hear people proposing them for standardization (and read the drafts and RFCs), but there is very little architectural discussion. This was deliberate, with the IETF having been split out from the Internet Architecture Board in 1992. So when I look back now on the security chapter we produced for the second edition, I see a lot of mechanisms and not much systems thinking.

On top of that, I was definitely not a security expert by any stretch, and nor was my co-author Larry, and while I have learned a lot more about security since then, I still don’t think you can claim security expertise unless you’ve really worked in the field for a long time.

There is a whole style of thinking that’s required in security to put yourself in the shoes of the attacker, who needs to find only one flaw, or perhaps a cascading collection of flaws, in your system to render it insecure.

I also made one pretty serious mistake (in describing message authentication codes) that was picked up by a reader soon after the second edition went into print. We were fortunately able to correct it in the next printing, but it’s embarrassing to publish errors that are easily spotted by an expert reader.

All of this brings me to our current project, which is a book with the working title of Network Security: A Systems Approach. In a similar vein to our book on TCP Congestion Control, our starting point is the relevant chapter of our big textbook. But compared to TCP congestion control, we’re dealing with a chapter where we are less expert, and honestly I’d say that I can see plenty of room for improvement in the existing chapter.

Sure, we have had four editions in which to improve the chapter already but there’s always so much competing for our attention when we do a complete textbook revision.

The nice thing about tackling this subject as a standalone project is that it will have our full attention. Also, recognizing our relative lack of expertise, we’ll be getting help from a few actual security experts this time. Brad Karp, who teaches a course on Distributed Systems and Security at University College London in the UK, has agreed to help us get our story straight. (He fixed some bugs in this piece, too.)

One thing I appreciate much more now than I did when writing our second edition is how much security is a systems story.

Partly I think this is related to my prior point about how an attacker only needs to find one flaw. So you can’t just go and optimize individual components and then assemble them. There are systems principles to follow, such as the principle of least privilege (which would take another article to fully explain).

The original end-to-end argument uses a security example to illustrate a systems principle. And security has performance implications; addressing them requires a systems approach, as illustrated in the cross-layer design of QUIC, for example. So my hope is that, in our new book, we will more successfully apply the systems lens to the problems of network security, and perhaps, with the benefit of external help and 25 more years of experience, we can make fewer mistakes as well. ®

https://www.theregister.com//2024/02/01/systems_approach_security/