Story continued from Page 1
What other protections are included only with OpenBSD's network stack?
Ryan McBride: Firstly, OpenBSD is aggressive about the use of network randomness. Wherever possible, we use pseudo-random data in variable fields in packets. Counters, timestamps, and session identifiers are all good candidates for such pseudo-random data.
Our network stack randomizes the following values: TCP ISN, TCP Timestamp, Ephemeral Source Port, IPID and the IPv6 Fragment ID. In addition, Randomness is used in userland network code: BIND, ICMP/ICMP6, RPC and the time protocols all use pseudo-random values.
These randomizations make blind insertion attacks much more difficult, and have saved us from serious vulnerabilities which were unknown when we implemented the randomness. An example of such a vulnerability is the TCP sequence number predicion problems disclosed last year by Paul Watson.
Secondly, we make conservative decisions about implementing risky protocol features, or ignore RFCs when they're wrong. A comprehensive list is way too long to include here, but examples include refusing to allow IPv4 mapped address in OpenBSD's IPv6 code, ignoring hard ICMP errors that don't make sense, or [having] our portmapper binding separately to localhost to prevent certain operations from being done remotely.
Finally, including Availability as an aspect of Security, OpenBSD has been making many advances in the area of network redundancy. CARP, interface trunking, and STP allow failover and redundancy at layers 2 and 3, and many daemons are being added or modified to deal with these network stack features: pfsync, sasyncd, ifstated, bgpd, etc.
Keep in mind that much of the above is not new - we've been doing many of these things for nearly 10 years. And while these mechanisms have to be designed very carefully to avoid breaking protocols, it is not impossible. This is not rocket science, it's just good software engineering, But adoption of these measures by other OS projects is sadly lacking. The OpenBSD difference is that we make a concerted effort to implement and enable these features by default.
How does OpenBSD network stack compare with Linux?
Ryan McBride: The "Linux stack" is a concept that is very hard to pin down because there are so many versions, distributions, 3rd party patches and modules, etc. People might tell you that Linux has the capability to do X, Y, or Z that OpenBSD enables by default, but they don't tell you that you have to dig around for the patches, enable the right compile flags, load the right modules and sacrifice a goat on the full moon. And even then it's incomplete and buggy.
Because of this, I think OpenBSD's main strength is the following: these security features are easy to use. (Which is somewhat ironic as OpenBSD has a mistaken reputation for not being user friendly.) Our approach is simple: Proactively implement security features. Enable these features by default. Minimize the number of "buttons" - compile-time or run-time options. And document rigorously.
It seems that OpenBSD focus on proactive security and provides good results even against new attacks. I remember when Paul Watson published his paper "Slipping in the Window: TCP Reset Attacks" around May, 2004, and OpenBSD was the only OS not vulnerable by default. However I'm wondering if sometimes it's also the result of undisclosed information from researchers...
The TCP window attack was particularly effective against long TCP sessions, so the biggest target was BGP, and for some magical reasons in that period you released the first version of OpenBGPD, a BSD-licensed implementation of BGP, so that people could use it to replace vulnerable systems to handle routing information.
I'm wondering how you chose to start working on a bizarre thing such as a BGP implementation in the end of 2003? Did you get any preview of Watson's paper?
Henning Brauer: No. I started to work on bgpd because we were using zebra here, for years. It worked... to some extent. I did patch here and there and fixed some bugs in the code and such, but it was very obvious that the design was (and is) wrong, and that this beast is unfixable. So I had this idea of writing a BGP daemon that doesn't suck for some time. Two years at least.
When I was in Calgary in fall 2003 Theo got me drunk and made me tell him about it, and then he kept kicking my lazy butt to take a stab at it... yeah, and after I've been back I started writing it. Nick reminded me that I vaguely predicted an attack like the RST one against BGP sessions years ago after Paul Watson released his paper. I did not know about Paul's work when I started writing bgpd. I did get informed that there was something upcoming sometime later, I didn't know exactly what though.
The countermeasures in OpenBSD's network stack, requiring RSTs to be right on the edge of the window and using random ephemeral ports, were about 7 years old when Paul released his paper, so they were certainly not in reaction to his work :)
What is OpenBGPD's current status?
Henning Brauer: Quite some work was done between 3.7 and 3.8 in OpenBGPD. Countless little bugs were fixed, I don't think any of them was really critical. One I have to highlight since it was so hard to fix: when you did a "bgpctl reload", causing the config file to be reexamined, and the configuration had errors, we had some memleaks. Nothing dramatic, and rather small leaks, and you're supposed to write correct configs anyway :), but nonetheless a bug - or rather, a number of small bugs. We got that fixed. I did spend some time in the interface validation code, that is used in the nexthop validation - there were some (again, non-fatal) bugs, and in the end I changed quite some things there. I also totally changed the way we allocate listening sockets, fixing a small race condition. Claudio did "network connected", which tells bgpd to redistribute all directly connected networks. Same thing for "network static", redistributing static routes. And you can add networks with attributes like communities and metrics from the command line using bgpctl network add now. There is more of this kind of changes - interested parties should take a peek at my presentation from the DE-CIX 3rd technical meeting.
One thing that is finally completely implemented is the route label stuff. This really rocks: we allow up to 32 bytes to be attached to a route. It is stored together with the route in the kernel routing table. Well, not really, they are stored separately and the routes just refer to them via an ID mechanism to preserve memory, but that is a completely hidden implementation detail. We do it the same way in bgpd though, again to preserve some memory. It turned out we can generalize the ID allocator a bit and do the same for the pftable stuff, so we save another 14 bytes per AS-Path. But back to route labels. bgpd now finally can set route labels via its filter language. You could, for example, store the route's source AS in the label. Or the peer you learned it from. Or something completely different. Now, it gets really powerful because PF can access these labels as well, and take filter decisions based on them. Or, my favorite, QoS queue assignments. Or AS-dependent max-src-conn-rate and the like, to fight DDoS. Everything that pf can do can now be done based on information from BGP as well - that is very very very powerful.
The biggest news is probably IPv6 support. Yes, it is there now. Yes, it hurts to implement it. There's not much to say about it, since it just works. We are still adding v6 support to various bgpctl commands, but the basics all work already.
Aside from the technical advancements there is interest at a number of European exchange points to use OpenBSD and bgpd as route server - presentations and lobbying and stuff take some amount of work too. Fortunately Reyk Floeter, and maxim of the CCC crowd, do a lot of the lobby work.
Which OS can OpenBGPD be run on?
Henning Brauer: Please go whine at Cisco that theirs doesn't run on OpenBSD. I keep repeating it - BGP is not a userland only thing. We did change things in kernel land, and we will continue to do so, to deliver a BGP router (or BGP route server, etc etc) solution. Seeing that as a userland only task is way too shortsighted. It is the combination of kernel and bgpd.
That said, it does work on the other BSDs, with some limitations since they lack the kernel parts. Somebody even got it to run on Linux, but without the ability to change the kernel routing table.