Our research on fuzz testing of the RRC protocol - why and how

Imagine being the diver from the photo, trying to figure out what moves this shoal of fish and what will be the next direction they will take. Well, that´s how a system under test feels faced with a vast number of inputs in the fuzz testing.

But before “diving” deeper, let´s start with a couple of explanations, to ensure we are on the same page.

The RRC protocol

In a telecom network, Radio Access Network (RAN) provides wireless communication service to User Equipment (UE), namely mobile phones. The RAN consists of radio base stations that are called gNB in 5G, and the radio access technology used by a gNB is called New Radio (NR).

Now, check the figure below, showing the control plane protocol stack in NR.

The control plane protocol, among other things, is responsible for establishing and maintaining connections and setting up security. The Physical (PHY) layer, which is Layer 1, carries traffic using radio resources in time and frequency domains. Layer 2 consists of Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Convergence Protocol (PDCP) layers. They enable functionalities such as uplink and downlink scheduling, packet segmentation, encryption, and integrity protection.

Figure: Control plane protocol stack in NR

The Radio Resource Control (RRC) layer, which is the focus of this blog post, is Layer 3 of the control plane protocol. It is responsible for creating and maintaining radio connections, broadcasting system information, delivering paging notifications, managing radio measurements, and handovers.

Are you still with us? Good! Then let´s move on.

The RRC message formats are defined using platform-agnostic ASN.1 and can be seen as a tree in the figure below. Each RRC message comprises structured (CHOICE, SEQUENCE, and SEQUENCE OF) and primitive (BOOLEAN, INTEGER, ENUMERATED, BIT STRING, and OCTET STRING) data types as its members. The STRUCTURED data types can consist of any other data type.

Mind that, during transfer, the RRC messages are encoded using ASN.1 Unaligned Packed Encoding Rules (UPER) that convert data structures into compact series of bytes.

Figure: Illustration of RRC message definition using ASN.1

A robust telecom network needs a robust RRC implementation

Telecom networks must be robust to provide uninterrupted services to billions of users worldwide. The first step in achieving this robustness is proper design and standardization in 3GPP.

But, when the 3GPP technical specifications (TS) are implemented by different vendors, factors like human errors or poor coding practices may introduce implementation bugs that go unnoticed. To uncover such implementation bugs, the network vendors generally need to perform two broad categories of software testing – conformance and fuzz testing.

Since RRC protocol occupies a prominent role in a telecom network, any faults in its implementation could lead to severe service disruptions. Hence, RRC protocol implementations must be thoroughly tested for robustness before deploying them in the field.

Fuzz testing the RRC implementation for robustness

While conformance testing ensures that a System Under Test (SUT) works properly with expected messages, fuzz testing identifies vulnerabilities in the SUT by sending unexpected messages. In other words, fuzz testing is used as negative testing, in which unexpected inputs are sent to a SUT, and then the SUT's behavior is monitored.

Fuzz testing complements conformance testing by discovering faults not identified by the latter, such as buffer overflow and race conditions. With an early discovery of faults, network vendors can fix their product before it is shipped and ensure the robustness of the product.

How is the RRC fuzz testing performed in reality? An example is shown in the figure below.

Figure: Fuzz testing the RRC protocol

From the network vendor perspective, the RAN side is the SUT, and the fuzzing is done from the UE side as explained here:

• Act an additional shim layer in a concrete implementation of UE between Layer 3 and the lower layers.
• Intercept RRC messages in Layer 3 before they are passed down to lower layers.
• Fuzz or replace the intercepted RRC messages.
• Pass down the fuzzed or replaced messages to lower layers.

Thus, the fuzzer is unaffected by lower-layer protocol handlings, like encryption, integrity protection, segmentation, and scheduling. On a high level, the fuzzing technique could be either mutation-based or generation-based.

When some part(s) of an existing message are changed (mutated), we call it mutation-based. If a new message is generated from scratch, we call it generation-based. The decoding and encoding of RRC message are necessary because an RRC message on-flight is a series of bytes in ASN.1 UPER encoding.

Continuously evolving 3GPP standards pose a challenge

So far so good. But…

If an RRC fuzzer implementation is tied to RRC message types and formats conforming to a particular 3GPP TS version, it will be non-backward compatible with older SUTs. Soon it will become obsolete with newer SUTs, because 3GPP TSes are continuously evolving for new features and enhancements.

There are at least 20 versions of 5G/NR RRC TS 38.331 from Release 15 to 16 (and 170+ versions of 4G/EUTRA RRC TS 36.331 from Release 8 to 16). For example, see in the figure below how much the RRC Connection Reconfiguration message has evolved from Release 8 to 15 in 4G/EUTRA.

Therefore, regular re-implementation or updates to the RRC fuzzer become inevitable, and so we come to the major maintenance issue. We see the need for an adaptive RRC fuzzer that can (easily) cope with continuously evolving 3GPP TSes.

Figure: 4G/EUTRA RRC Connection Reconfiguration message definition in Release 8 and 15

Introducing Berserker, a new RRC fuzzer that adapts to the evolving standards

The saying goes "if you can't beat 'em, join 'em".

That´s why we did research on an RRC fuzzing framework called Berserker, that directly takes the 3GPP’s TS as input for obtaining knowledge specific to each version of the RRC message formats, as shown in the figure below.

Figure: Overview of Berserker – an ASN.1 based adaptive fuzzer for RRC

[Berserkers are historic Nordic warriors known to be extremely furious; the name represents our research work on RRC fuzzer that is ruthless with a system under test.]

Different versions of RRC TSes are publicly available from 3GPP as MS Word files. Berserker extracts the complete RRC ASN.1 schema from an RRC TS into a single plain text file, containing all the text paragraphs between the ASN1TSTART tag and the following ASN1STOP tag in the order they appear throughout the TS. For example, see the definition for RRC Setup Request message in the figure below from 3GPP TS 38.331.

Figure: Concrete example of an RRC Setup Request message format defined using ASN.1

Berserker takes advantage of this generic nature of ASN.1 and compiles the extracted RRC ASN.1 schema to produce the corresponding encoder and decoder, which are used to mutate/generate RRC messages. This way, the RRC fuzzer can be (easily) compatible with old and new implementations of the RRC protocol.

When it comes to the actual mutation/generation, check the table to learn which strategies Berserker uses. These strategies are dependent on data type, message/field name, constraints from specs, etc.

ASN.1 constraints and evading them

It looks good, right? But, there is still a “but”…

Using an encoder and decoder based on the RRC ASN.1 schema does introduce one inconvenience: the encoder and decoder will follow constraints imposed by the ASN.1 schema on what values a field can take. For example, if a field is defined to be 39-bits long (see randomValue in the RRC setup message above), the encoder will refuse to set that field to the 80-bits long value.

Figure: ASN.1 schema mutation in Berserker

To overcome this inconvenience, we added a capability in Berserker to mutate the RRC ASN.1 schema itself, for example, changing the field definition from 39-bits to 80-bits. The encoder produced from such mutated RRC ASN.1 schema will then encode 80-bits fields, beyond the constraints imposed by the original schema. Thus, Berserker can test the SUT more rigorously.

The table shows mutation strategies for the RRC ASN.1 schema.

Summary

Now you know how our research on a new RRC fuzzing framework – Berseker – provides backward and forward compatibility with any given RRC TS. Further, by being able to sidestep constraints in a given RRC TS, Berserker can generate RRC messages with a new format and thus increase testing coverage.

And we are far from being done here! We continuously research how to increase the robustness of telecom networks. So, please keep following us for further updates and feel free to keep in touch.

As for that diver from the beginning, hopefully, he will also find a helpful solution for his challenge.

Read more

More details, including our experiments, are available in the pre-print version of our paper: https://arxiv.org/abs/2107.01912. You can cite us using below:

Featured articles

Telecom Security Products and Solutions

A summary of 3GPP Release 16, 5G phase 2: Security and RAN

5G security – enabling a trustworthy 5G system