Internet-Draft Babel-MAC Relaxed PC June 2023
Chroboczek & Høiland-Jørgensen Expires 14 December 2023 [Page]
Workgroup:
Network Working Group
Updates:
8967 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Chroboczek
IRIF, University of Paris-Cité
T. Høiland-Jørgensen
Red Hat

Relaxed Packet Counter Verification for Babel MAC Authentication

Abstract

This document relaxes packet verification rules defined in the Babel MAC Authentication protocol in order to make it more robust in the presence of packet reordering. This document updates RFC 8967 by relaxing the packet validation rules defined therein.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 14 December 2023.

Table of Contents

1. Introduction

The design of the Babel MAC authentication mechanism [RFC8967] assumes that packet reordering is an exceptional occurrence, and the protocol drops any packets that arrive out-of-order. The assumption that packets are not routinely reordered is generally correct on wired links, but turns out to be incorrect on some kinds of wireless links.

In particular, IEEE 802.11 (Wi-Fi) [IEEE80211] defines a number of power-saving modes that allow stations (mobile nodes) to switch their radio off for extended periods of time, ranging in the hundreds of milliseconds. The access point (network switch) buffers all multicast packets, and only sends them out after the power-saving interval ends. The result is that multicast packets are delayed by up to a few hundred milliseconds with respect to unicast packets, which, under some traffic patterns, causes the Packet Counter (PC) verification procedure in RFC 8967 to systematically fail for multicast packets.

This document defines two distinct ways to relax the PC validation: using two separate receiver-side states, one for unicast and one for multicast packets (Section 3.1), which allows arbitrary reordering between unicast and multicast packets, and using a window of previously received PC values (Section 3.2), which allows a bounded amount of reordering between arbitrary packets. We assume that reordering between arbitrary packets only happens occasionally, and, since Babel is designed to gracefully deal with occasional packet loss, usage of the former mechanism is RECOMMENDED, while usage of the latter is OPTIONAL. The two mechanisms MAY be used simultaneously (Section 3.3).

This document updates RFC 8967 by relaxing the packet validation rules defined therein. It does not change the security properties of the protocol.

2. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Relaxing PC validation

The Babel MAC authentication mechanism prevents replay by decorating every sent packet with a strictly increasing value, the Packet Counter (PC). Notwithstanding the name, the PC does not actually count packets: a sender is permitted to increment the PC by more than one between two packets.

A receiver maintains the highest PC received from each neighbour. When a new packet is received, the receiver compares the PC contained in the packet with the highest received PC; if the new value is smaller or equal, the packet is discarded; otherwise, the packet is accepted, and the highest PC value for that neighbour is updated.

Note that there does not exist a one-to-one correspondence between sender states and receiver states: multiple receiver states track a single sender state. The receiver states corresponding to single sender state are not necessarily identical, since only a subset of receiver states are updated when a packet is sent to a unicast address or when a multicast packet is received by a subset of the receivers.

3.1. Multiple highest PC values

Instead of a single highest PC value maintained for each neighbour, an implementation of the procedure described in this section uses two values, the highest multicast value PCm and the highest non-multicast (unicast) value PCu. More precisely, the (Index, PC) pair contained in the neighbour table (Section 3.2 of [RFC8967]) is replaced by:

  • a triple (Index, PCm, PCu), where Index is an arbitrary string of 0 to 32 octets, and PCm and PCu are 32-bit (4-octet) integers.

When a challenge reply is successful, both highest PC values are updated to the value contained in the PC TLV from the packet containing the successful challenge. More precisely, the last sentence of the fourth bullet point of Section 4.3 of [RFC8967] is replaced by:

  • If the packet contains a successful Challenge Reply, then the Index contained in the PC TLV MUST be stored in the Index field of the neighbour table entry corresponding to the sender (which already exists in this case), the PC contained in the TLV MUST be stored in both the PCm and PCu fields of the neighbour table entry, and the packet is accepted.

When a packet that does not contain a successful challenge reply is received, the PC value that it contains is compared to either the PCu or the PCm field of the corresponding neighbour entry, depending on whether the packet was sent to a muticast address or not. If the comparison is successful, then the same value (PCm or PCu) is updated. More precisely, the last bullet point of Section 4.3 of [RFC8967] is replaced by:

  • At this stage, the packet contains no successful challenge reply and the Index contained in the PC TLV is equal to the Index in the neighbour table entry corresponding to the sender. The receiver compares the received PC with either the PCm field (if the packet was sent to a multicast IP address) or the PCu field (otherwise) in the neighbour table; if the received PC is smaller or equal than the value contained in the neighbour table, the packet MUST be dropped and processing stops (no challenge is sent in this case, since the mismatch might be caused by harmless packet reordering on the link). Otherwise, the PCm (if the packet was sent to a multicast address) or the PCu (otherwise) field contained in the neighbour table entry is set to the received PC, and the packet is accepted.

3.1.1. Generalisations

Modern networking hardware tends to maintain more than just two queues, and it might be tempting to generalise the approach taken to more than just two last PC values. For example, one might be tempted to use distinct last PC values for packets received with different values of the Type of Service (ToS) field, or with different IEEE 802.11 [IEEE80211] access categories. However, choosing a highest PC field by consulting a value that is not protected by the MAC (Section 4.1 of [RFC8967]) would no longer protect against replay. In effect, this means that only the destination address and port number and data stored in the packet body may be used for choosing the highest PC value, since these are the only fields that are protected by the MAC (in addition to the source address and port number, which are already used when choosing the neighbour table entry and therefore provide no additional information). Since Babel implementations do not usually send packets with differing ToS values or IEEE 802.11 access categories, this is unlikely to be an issue in practice.

The following example shows why it would be unsafe to select the highest PC depending on the ToS field. Suppose that a node B were to maintain distinct highest PC values for different values T1 and T2 of the ToS field, and that initially all of the highest PC fields at B have value 42. Suppose now that a node A sends a packet P1 with ToS equal to T1 and PC equal to 43; when B receives the packet, it sets the highest PC value associated with ToS T1 to 43. If an attacker were now to send an exact copy of P1 but with ToS equal to T2, B would consult the highest PC value associated with T2, which is still equal to 42, and accept the replayed packet.

3.2. Window-based validation

Window-based validation is similar to what is described in Section 3.4.3 of [RFC4303]. When using window-based validation, in addition to retaining within its neighbour table the highest PC value PCh seen from every neighbour, an implementation maintains a fixed-size window of booleans corresponding to PC values directly below PCh. More precisely, the (Index, PC) pair contained in the neighbour table (Section 3.2 of [RFC8967]) is replaced by:

  • a triple (Index, PCh, Window), where Index is an arbitrary string of 0 to 32 octets, PCh is a 32-bit (4-octet) integer, and Window is a vector of booleans of size S (the default value S=128 is RECOMMENDED).

The window is a vector of S boolean values numbered from 0 (the "left edge" of the window) up to S-1 (the "right edge"); the boolean associated with the index i indicates whether a packet with PC value (PCh - (S-1) + i) has been seen before. Shifting the window to the left by an integer amount k is defined as moving all values so that the value previously at index n is now at index (n - k); k values are discarded at the left edge, and k new unset values are inserted at the right edge.

Whenever a packet is received, the receiver computes its index i = (PC - PCh + S - 1). It then proceeds as follows:

  1. If the index i is negative, the packet is considered too old, and MUST be discarded.
  2. If the index i is non-negative and strictly less than the window size S, the window value at the index is checked; if this value is already set, the received PC has been seen before and the packet MUST be discarded. Otherwise, the corresponding window value is marked as set, and the packet is accepted.
  3. If the index i is larger or equal to the window size (i.e., PC is strictly larger than PCh), the window MUST be shifted to the left by (i - S + 1) values (or, equivalently, by the difference PC - PCh) and the highest PC value PCh MUST be set to the received PC. The value at the right of the window (the value with index S - 1) MUST be set, and the packet is accepted.

When receiving a successful Challenge Reply, the remembered highest PC value PCh MUST be set to the value received in the challenge reply, and all of the values in the window MUST be reset except the value at index S - 1, which MUST be set.

3.3. Combining the two techniques

The two techniques described above serve complementary purposes: splitting the state allows multicast packets to be reordered with respect to unicast ones by an arbitrary number of PC values, while the window-based technique allows arbitrary packets to be reordered but only by a bounded number of PC values. Thus, they can profitably be combined.

An implementation that uses both techniques MUST maintain, for every entry of the neighbour table, two distinct windows, one for multicast and one for unicast packets. When a successful challenge reply is received, both windows MUST be reset. When a packet that does not contain a challenge reply is received, then if the packet's destination address is a multicast address, the multicast window MUST be consulted and possibly updated, as described in Section 3.2; otherwise, the unicast window MUST be consulted and possibly updated.

4. Security considerations

The procedures described in this document do not change the security properties described in Section 1.2 of RFC 8967. In particular, the choice between the multicast and the unicast packet counter is done by examining a packet's destination IP address, which is included in the pseudo-header and therefore participates in MAC computation; hence, an attacker cannot change the destination address without invalidating the MAC, and therefore cannot replay a unicast packet as a multicast one or vice versa.

While these procedures do slightly increase the amount of per-neighbour state maintained by each node, this increase is marginal (between 4 and 36 octets per neighbour, depending on implementation choices), and should not significantly impact the ability of nodes to survive denial-of-service attacks.

5. IANA Considerations

This document requires no IANA actions.

6. Acknowledgments

The authors are greatly indebted to Daniel Gröber, who first identified the problem that document aims to solve and first suggested the solution described in Section 3.1.

7. Normative references

[RFC8967]
Dô, C., Kolodziejak, W., and J. Chroboczek, "MAC Authentication for the Babel Routing Protocol", RFC 8967, DOI 10.17487/RFC8967, , <https://www.rfc-editor.org/info/rfc8967>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

8. Informative references

[IEEE80211]
"IEEE Standard for Information Technology — Telecommunications and information exchange between systems Local and metropolitan area networks — Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.", <https://ieeexplore.ieee.org/document/9363693>.
[RFC4303]
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, , <https://www.rfc-editor.org/info/rfc4303>.

Authors' Addresses

Juliusz Chroboczek
IRIF, University of Paris-Cité
Case 7014
75205 Paris CEDEX 13
France
Toke Høiland-Jørgensen
Red Hat