Subject: [babel] IETF-95 follow-up: security slides transcript

From: Denis Ovsienko <[email-masked]>
Date: Wed, 20 Jul 2016 22:40:24 +0100

Hello list.

Below you can find a transcript for the slides [1] on Babel security that I presented at IETF-95. Much of the originally intended text had not fitted into the 15 minutes slot, so if anybody is interested in the full version, here it is. Everything in this text still stands.

1: https://www.ietf.org/proceedings/95/slides/slides-95-babel-2.pdf

--------------------------------------------------------------------------
# slide 1
(the title page)

# slide 2
To explain better what I consider important input to this meeting let me remind that there are four point of view on a network protocol. They are closely related but don't substitute each other.
In this list the user is not the end user but the network administrator and the researcher may be an academic researcher or a security concerned engineer, whether trying to break the protocol or trying to make it stronger.
With those roles in mind let's make a look at protocol complexity.

# slide 3
Protocol complexity consists of several aspects. This table for a set of well-known protocols expresses one such aspect, namely, complexity of wire encoding, through the amount of lines of C code required to decode it. On this scale RIP may be used as a landmark, in that you would want to know where it is even if you are going to a somewhat different place. Babel is comparable with OLSR, which may miss recent additions to the protocol though.

The metric isn't quite accurate for a number of reasons. **First**, only Babel and RIP decoders here incorporate all published extensions. **Second**, decoders consist of the actual code and copies of protocol parameters registries in varying proportions. And **third**, a protocol's encoding may be compact but the control logic may be complicated (and the other way around).

The interesting thing is, this complexity estimation, as approximate as it is (similar to the number of pages in an RFC), is useful not only for packet analyzer development. It also estimates the difficulty of keeping the protocol secure and the next slide briefly explains a practical case of this.

# slide 4
My own experience with fuzzing stands for a few Open Source projects, for that other people were finding and sending vulnerabilities. In the course of making or proofreading the fixes for some of those vulnerabilities I have learned that fuzzing may be very effective. It seems to me, protocol designers and implementers have to account for fuzzing anyway. The only difference is if they don't do it early they do it later with a great discomfort.

In my experience the work required to protect a protocol from fuzzing seemed to be mostly the same as the work required to support the protocol in a network analyzer. Respectively, if you run into difficulties implementing the dissector, you are likely to run into difficulties implementing fuzzing protection.

# slide 5
This flowchart diagram looks simple. In fact, to work with a network protocol that allows to apply this process as shown is indeed much simpler. In particular, this diagram applies to Babel.

The first step tests whether the structure is valid as far as protocol encoding goes. If this simple test fails, the packet is not a valid packet, period.

The next step tests whether the packet is authentic, as far as the protocol authentication mechanism is concerned. It cannot be the first step because authentication uses protocol encoding, which you need tested first. In addition, authentication is more expensive on CPU and should not be done too early.

The next step tests semantics of the data contained in such structurally valid packet. This is the most interesting part as you would be looking for multicast addresses, IPv4 prefixes in IPv6 messages, multiple data items in messages that specifically allow only one data item and so on. Such checks are often a part of the specified protocol instance but this needs to be double-checked.

The main point of this diagram is, if you cannot implement this process for any single packet, expect complications.

# slide 6
With this network protocol fuzzing in mind it should be easier to see how this work started. The amount of time spent on each step in this slide varies greatly but overall story was going as it is shown and eventually resulted in the first revision of the Internet Draft in 2012. The next slide takes us fast-forward to 2015.

# slide 7
RFC 6709 discusses cryptographic agility but in a way that requires a notable interpretation as cryptography isn't the main focus of it. At the I-D time I made those interpretations as much as I could. Eventually RFC 7696 was published, and it covers exactly the area that RFC 6709 discussed only briefly. The good news is, RFC 7298 is compliant with that as well, so this aspect doesn't add to the working group list of things to fix.

# slide 8
For example, parameter size in this case is the output digest size, and RFC 7298 requires it to be at least 16 octets as it needs to make enough space for padding to fit an IPv6 address. Then, it should be clear how to switch -- and yes, it is reasonably clear as the algorithm ID is a part of the security association. RFC 7298 even requires to support at least two digests per packet, which makes rollovers of algorithm and/or key simple.

# slide 9
So we come to a simple question with a simple and correct answer. Let me explain it.

# slide 10
On this slide you can see four wireless routers, which have formed a small mesh network. In this diagram wireless links are dotted and wired links are solid. The mesh is not a __full__ mesh network because there is a big mountain in the centre of the picture. It is invisible, partly because I did not have a picture handy, and partly because the wireless routers don't see the mountain as well. However, they do see the effects of the natural obstacle and work around them as much as they can. This way the networks A and B eventually have a two-way path between them.

# slide 11
Now some resourceful guy puts a repeater on the summit of the mountain. The repeater is configured to relay packets transparently between the routers (a) and (b), but only in a selective way. As a result, those two speakers will discover each other and prefer the direct link for routing between the networks A and B. The problem is, the Babel neighbourship is OK but the payload gets dropped. This is link spoofing in action and Babel is just a particular case of it.

# slide 12
On this slide you can see the same attack performed against two BGP speakers on an Ethernet switch (or something that pretends to be a switch or even just a length of wire). Many other scenarios of link spoofing are possible. So long as the attacker can tell what is being transmitted and can drop packets selectively, this attack remains in scope. That's why for a strictly point-to-point link it often makes the most sense to encrypt and authenticate every packet. How much it is feasible and useful in mesh networks, should be considered separately.

# slide 13
With that in mind let's try once again to understand what sense it makes for the working group. If you read this longer version of the answer carefully, you may see it does not imply a better class of solution already exists elsewhere or even may exist in theory. What needs to be done here is to ask real cryptographers. Depending on what they say the working group should either produce an applicability statement like it is done for MANET, or, if there __is__ a better way, the working group should just take it. In this case RFC 7298 should serve as a useful baseline for comparison.

# slide 14
Having said all that, the conclusions boil down to the general "before you do, stop and think" rule. In addition to what is stated on the slide, let me stress that for security considerations this rule applies even much more. Also let me remind that very valuable experience comes from working in those 4 roles, that is, an operator, an implementer, a researcher and a designer. It is valuable enough such that if you have a use case for a new angle of exposure to a network protocol, don't lose it.

# slide 15
Thank you!

-- 
 Denis Ovsienko