| Internet-Draft | Babel-MAC Relaxed PC | May 2022 |
| Chroboczek | Expires 23 November 2022 | [Page] |
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 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 23 November 2022.¶
Copyright (c) 2022 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.¶
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. This assumption is generally correct on wired links, but turns out to be incorrect on some kinds 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 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 PC verification procedure in RFC 8967 to systematically fail for multicast packets.¶
This document defines two ways to relax the PC validation: using two separate receiver-side states, one for unicast and one for multicast packets (Section 3.1), and using a window of previously received PC values (Section 3.2). Usage of the former is RECOMMENDED, while usage of the latter is OPTIONAL. The two MAY be used simultaneously (Section 3.3). This document updates RFC 8967.¶
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.¶
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: it is permitted for a sender 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 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.¶
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 [RFC8967]) is replaced by:¶
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 [RFC8967] is replaced by:¶
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 [RFC8967] is replaced by:¶
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.11e access categories. However, chosing a last 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 practice, this means that only the destination address and port number and data stored in 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 and porte number, which are already used when choosing the Neighbour Table entry and therefore provide no additional information).¶
The following example shows why it would be unsafe to select the last PC depending on the ToS field. Suppose that a node B were to maintain distinct last PC values for different values T1 and T2 of the ToS field, and that initially all of the last 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 last 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 last PC value associated with T2, which is still equal to 42, and accept the replayed packet.¶
Use a window in the style of Section 3.4.3 of [RFC4303].¶
The two techniques defined above serve complementar 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 of 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 consluted and possibly updated.¶
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 marginal (between 4 and 32 octets, depending on implementation choices), and should not significantly impact the ability of nodes to survive denial-of-service attacks.¶