Relaxed Packet Counter Verification for Babel MAC Authentication

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

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 unicast PC and the highest 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 highest 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 highest 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 highest 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 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.

Window-based validation Window-based validation is similar to that described in . When using window-based validation, in addition to remembering the highest PC value seen from a given neighbour, an implementation maintains a fixed-size window of individual sequence numbers below this highest PC value. The PC value itself is updated if the new packet PC value is higher than the existing value being remembered, while the window is used to track individual values so that out-of-order PC values can be accepted without allowing any duplicates. Conceptually, 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"). Thus, the window can be stored as a fixed-size bitmap, but other more complicated data structures are also possible. Shifting the window to the left by an integer amount k consists in 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, its PC value is first compared with the PC value kept in the neighbour table, and the window index of the received PC value is computed as the difference between the received PC value and the stored highest PC value plus the window size.

If the window index is negative, the packet is considered too old and MUST be discarded.
If the window index is non-negative and less than or equal to the size of the window, the window value at the window 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.
If the window index is larger than the window size (i.e., the received PC is higher than the largest received value), the window MUST be shifted to the left by the difference between the window index and the window size (or, equivalently, by the difference between the received PC and the highest PC stored in the neighbour table) and the highest PC value MUST be set to the received PC. The value at the right of the window (the value numbered S - 1) MUST be set, and the packet is accepted.

When receiving a successful Challenge Reply, the remembered highest PC value MUST be set to the value received in the challenge reply, and all of the values in the window MUST be reset.

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.