Relaxed Packet Counter Verification for Babel MAC Authentication

Internet-Draft	Babel-MAC Relaxed PC	May 2022
Chroboczek	Expires 11 November 2022	[Page]

Abstract

This document relaxes the procedures described in RFC 8967 to allow it to better deal with packet reordering.¶

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 11 November 2022.¶

Copyright Notice

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

1. Introduction

The Babel MAC authentication mechanism [RFC8967] assumes that packet reordering is an exceptional occurrence, and therefore drops any packets that arrive out-of-order. This assumption is generally correct on wired links, but turns out to be incorrect on some types of wireless links.¶

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

This document defines two ways to relax the PC validation: using separate receiver-side PC values for unicast and multicast, and using a window of previously received PC values. Usage of the former is strongly RECOMMENDED, while usage of the latter is OPTIONAL. The two MAY be used simultaneously. This document updates RFC 8967.¶

2. Relaxing PC validation

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

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

Note that there is not a one-to-one correspondence between sender state and receiver state: to a single sender state correspond multiple receiver states, one in every neighbour. The receiver states corresponding to single sender state are not 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 dropped by some receivers.¶

2.1. Multiple last PC values

Instead of a single last PC value maintained for each neighbour, an implementation of the procedure described in this section uses two values, the last unicast PC and the last multicast PC. More precisely, the (Index, PC) pair contained in the Neighbour Table (Section 3.2 of RFC 8967) 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 last PC values are updated to the value contained in PC TLV from the packet containing the successful challenge. More precisely, the last sentence of the fourth bullet point of Section 4.3 of RFC 8967 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 packet is accepted, and the PC contained in the TLV MUST be stored in both the PCm and PCu fields of the Neighbour Table entry.¶

When a packet that does not contain a successful challenge reply is received, then the PC value it contains is compared to either the PCm or the PCu field of the corresponding neighbour entry, depending on whether the packet was sent to a unicast or a multicast address. 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 RFC 8967 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 PCm field (if the packet was sent to a multicast 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.¶

2.1.1. Generalisations

Since networking hardware tends to maintain more than just two queues, it might be tempting to generalise the approach taken to more than just to last PC values. For example, one might be tempted to use distinct last PC values for packets received with different Type of Service (ToS) fields or with different 802.11e priorities. However, chosing a last PC field by using a value that is not protected by the MAC (Section 4.1 of RFC 8967) would not be safe, in that it would not protect against replay. In practice, this means that only the destination address and the packet body may be used for choosing the last PC value, since these are the only fields that are protected by the MAC (in addition to the source address, which is already used when choosing the Neighbour Table entry and therefore provides no additional information).¶

Suppose that a node B were to maintain multiple last PC values for different values of the ToS field; for the sake of concreteness, suppose that all of the last PC fields at B have value 42. Suppose 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 last PC value associated with ToS T1 to 43. Suppose now that an attacker sends P2, a copy of P1 with ToS equal to T2; if B uses a different last PC field for packet with a ToS value equal to T2, then the last PC field will still have value 42, and B will accept the replayed packet.¶

2.2. Window-based validation

3. Security considerations

If implemented correctly, the procedures described in this document do not change the security properties described in Section 1.2 of RFC 8967. While they do slightly increase the amount of per-neighbour state maintained by each node, this increase is negligible (32 bits per neighbour for duplicating the last PC, and a few hundred bits for window-based validation), and should not significantly impact the ability of nodes to survive denial-of-service attacks.¶

4. References

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

Author's Address

Juliusz Chroboczek