Relaxed Packet Counter Verification for Babel MAC Authentication
IRIF, University of Paris-Cité
Case 7014
Paris CEDEX 13
75205
France
jch@irif.fr
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.
Introduction
The design of the Babel MAC authentication mechanism 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 (), and using a window of previously
received PC values (). Usage of the former is
RECOMMENDED, while usage of the latter is OPTIONAL. The two MAY be used
simultaneously (). This document updates RFC
8967.
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
when, and only when,
they appear in all capitals, as shown here.
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:
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.
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 () 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 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 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.
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.11e access
categories. However, chosing a last PC field by consulting a value that
is not protected by the MAC ()
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.
Window-based validation
Use a window in the style of .
Combining the two techniques
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 ; otherwise, the unicast window MUST
be consluted and possibly updated.
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 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.
Normative references
MAC Authentication for the Babel Routing Protocol
Key words for use in RFCs to Indicate Requirement Levels
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
Informative references
IP Encapsulating Security Payload (ESP)