RFC 9467

Relaxed Packet Counter Verification for Babel MAC Authentication

📅 published January 2024, from ietf

RFC 9467 🎀: Relaxed Packet Counter Verification for Babel MAC Authentication

okay bestie, let's get into it 💖 this is RFC 9467, and it's a Standards Track document from January 2024 (ISSN 2070-1721). The authors are J. Chroboczek (IRIF, University of Paris-Cité) and T. Høiland-Jørgensen (Red Hat). It updates RFC 8967, which is the Babel MAC authentication spec, so this one is basically a glow-up for it 🦋

Abstract ✨

This doc loosens the packet verification rules from "MAC Authentication for the Babel Routing Protocol" (RFC 8967) so Babel holds up better when packets arrive out of order. It updates RFC 8967.

Status of This Memo 📋

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9467.

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 🗂️

1.  Introduction
2.  Specification of Requirements
3.  Relaxing PC Verification
  3.1.  Multiple Highest PC Values
    3.1.1.  Generalisations
  3.2.  Window-Based Verification
  3.3.  Combining the Two Techniques
4.  Security Considerations
5.  IANA Considerations
6.  Normative References
7.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌸

Babel's MAC authentication mechanism [RFC8967] assumes that packet reordering is a rare, exceptional thing, so the protocol throws away any packet that shows up out of order. That assumption is usually fine on wired links, but it's just not true on some wireless links 🙈

Take IEEE 802.11 (Wi-Fi) [IEEE80211]. It has power-saving modes that let stations (mobile nodes) turn their radio off for long stretches, sometimes hundreds of milliseconds. Meanwhile the access point (network switch) holds on to every multicast packet and only sends them once the power-saving interval is over. So multicast packets can lag behind unicast packets by up to a few hundred milliseconds. With some traffic patterns, that means the Packet Counter (PC) verification procedure in RFC 8967 keeps failing for multicast packets. Every. Single. Time. 😭

This document describes two different 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. Babel is built to handle occasional packet loss gracefully, so the former mechanism is RECOMMENDED, while the latter is OPTIONAL. The two mechanisms MAY be used simultaneously (Section 3.3).

This document updates RFC 8967 by relaxing the packet verification rules defined there. 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 Verification 💅

The Babel MAC authentication mechanism stops replays by stamping every sent packet with a strictly increasing value, the Packet Counter (PC). Despite the name, the PC doesn't actually count packets. A sender is allowed to bump the PC by more than one between two packets sent back to back 🔢

A receiver keeps track of the highest PC it has received from each neighbour. When a new packet comes in, the receiver compares its PC with that highest received PC:

  • if the new value is smaller or equal, then the packet is discarded;
  • otherwise, the packet is accepted, and the highest PC value for that neighbour is updated.

Here's the tea: there's no one-to-one match between sender states and receiver states. Multiple receiver states track a single sender state. The receiver states for one sender state aren't necessarily identical, since only some receiver states get updated when a packet goes to a unicast address, or when a multicast packet is received by only a subset of the receivers 🦋

3.1. Multiple Highest PC Values 🌈

Instead of keeping one highest PC value per neighbour, an implementation of the procedure in this section keeps two values: the highest multicast value PCm and the highest non-multicast (unicast) value PCu. To be specific, the (Index, PC) pair in the neighbour table (Section 3.2 of [RFC8967]) gets 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 get updated to the value in the PC TLV from the packet with the successful challenge. To be exact, the last sentence of the fourth bullet point of Section 4.3 of [RFC8967] is replaced like this:

OLD:

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

NEW:

|  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 doesn't have a successful Challenge Reply comes in, its PC value gets compared to either the PCu or the PCm field of the matching neighbour entry, depending on whether the packet was sent to a multicast address. If the comparison passes, then that same value (PCm or PCu) gets updated. To be exact, the last bullet point of Section 4.3 of [RFC8967] is replaced like this:

OLD:

|  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 the PC contained in the neighbour
|  table; if the received PC is smaller or equal than the PC
|  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 PC contained in the neighbour table entry
|  is set to the received PC, and the packet is accepted.

NEW:

|  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 than or
|  equal to the value contained in the neighbour table, the packet
|  MUST be dropped and processing stops.  Note that 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 have more than two queues, so it's tempting to stretch this approach to more than just the two last PC values. For example, you might be tempted to keep separate last PC values for packets with different Type of Service (TOS) field values, or with different IEEE 802.11 access categories. But picking a highest PC field by looking at a value that isn't protected by the Message Authentication Code (MAC) (Section 4.1 of [RFC8967]) would stop protecting against replay. Basically, only the destination address and port number, plus the data stored in the packet body, can be used to pick the highest PC value. Those are the only fields the MAC protects (the source address and port number are also protected, but they're already used to pick the neighbour table entry, so they don't add anything new). Since Babel implementations don't usually send packets with different TOS values or IEEE 802.11 access categories, this probably won't be a problem in practice 🤷‍♀️

Here's an example of why picking the highest PC based on the TOS field would be unsafe. Say a node B keeps separate highest PC values for two TOS values, T1 and T2, and at the start every highest PC field at B is 42. Now a node A sends a packet P1 with TOS equal to T1 and PC equal to 43. When B gets it, B sets the highest PC value for TOS T1 to 43. If an attacker then sent an exact copy of P1 but with TOS equal to T2, B would check the highest PC value for T2, which is still 42, and accept the replayed packet 😱 that's a whole replay attack, bestie 💀

to be continued in part 2 🫶

3.2. Window-Based Verification 🪟

Okay so window-based verification is basically a cousin of what's in Section 3.4.3 of [RFC4303] 💅. When you use it, the node still keeps the highest PC value PCh it has seen from every neighbour, but it also keeps a fixed-size window of booleans for the PC values sitting right below PCh. Specifically, the (Index, PC) pair in the neighbour table (Section 3.2 of [RFC8967]) gets swapped out for:

  • 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).

Picture the window as a row of S booleans numbered from 0 (the "left edge") up to S-1 (the "right edge") 🦋. The boolean at index i tells you whether a packet with PC value (PCh - (S-1) + i) has been seen before. Shifting the window left by an integer amount k means everything slides over so the value at index n moves to index (n - k). The k values at the left edge get dropped, and k fresh unset values get added at the right edge.

Whenever a packet comes in, the receiver works out its index i = (PC - PCh + S - 1) and then does one of these things 👑:

  1. If the index i is negative, the packet is too old 💀, and it MUST be discarded.
  2. If the index i is non-negative and strictly less than the window size S, the window value at that index gets checked 🔍. If it's already set, the PC has been seen before and the packet MUST be discarded. Otherwise, the window value gets marked as set and the packet is accepted ✅.
  3. If the index i is larger or equal to the window size (aka PC is strictly bigger 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 one with index S - 1) MUST be set, and the packet is accepted.

When a successful Challenge Reply comes in, 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 do different jobs, and they're super complementary 💜:

  • 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.

So yeah, 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, 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 in this document do not change the security properties described in Section 1.2 of [RFC8967]. The big deal here is that the choice between the multicast and the unicast packet counter is made by looking at a packet's destination IP address. That address is included in the pseudo-header, so it participates in the 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. Iconic, honestly 😤.

These procedures do slightly increase the amount of per-neighbour state each node keeps. The 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 has no IANA actions.

6. Normative References 📚

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8967]  Dô, C., Kolodziejak, W., and J. Chroboczek, "MAC
           Authentication for the Babel Routing Protocol", RFC 8967,
           DOI 10.17487/RFC8967, January 2021,
           <https://www.rfc-editor.org/info/rfc8967>.

7. Informative References 🔎

[IEEE80211]
           IEEE, "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",
           DOI 10.1109/IEEESTD.2021.9363693, IEEE Std 802.11-2020,
           February 2021,
           <https://ieeexplore.ieee.org/document/9363693>.

[RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
           RFC 4303, DOI 10.17487/RFC4303, December 2005,
           <https://www.rfc-editor.org/info/rfc4303>.

Acknowledgments 🫶

The authors are SO grateful to Daniel Gröber, who first identified the problem this document aims to solve and first suggested the solution described in Section 3.1 🙌.

Authors' Addresses 💌

Juliusz Chroboczek
IRIF, University of Paris-Cité
Case 7014
75205 Paris CEDEX 13
France
Email: jch@irif.fr


Toke Høiland-Jørgensen
Red Hat
Email: toke@toke.dk
📦 where this page comes from