Relaxed Packet Counter Verification for Babel MAC Authentication
draft-ietf-babel-mac-relaxed-01

Network Working Group                                      J. Chroboczek
Internet-Draft                            IRIF, University of Paris-Cité
Updates: 8967 (if approved)                         T. Høiland-Jørgensen
Intended status: Standards Track                                 Red Hat
Expires: 13 December 2022                                   11 June 2022

    Relaxed Packet Counter Verification for Babel MAC Authentication
                    draft-ietf-babel-mac-relaxed-01

Abstract

   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.

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 13 December 2022.

Copyright Notice

   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.

Chroboczek & Høiland-JørExpires 13 December 2022                [Page 1]
Internet-Draft            Babel-MAC Relaxed PC                 June 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   2
   3.  Relaxing PC validation  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Multiple highest PC values  . . . . . . . . . . . . . . .   3
       3.1.1.  Generalisations . . . . . . . . . . . . . . . . . . .   4
     3.2.  Window-based validation . . . . . . . . . . . . . . . . .   5
     3.3.  Combining the two techniques  . . . . . . . . . . . . . .   6
   4.  Security considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Normative references  . . . . . . . . . . . . . . . . . . . .   6
   7.  Informative references  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

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.

Chroboczek & Høiland-JørExpires 13 December 2022                [Page 2]
Internet-Draft            Babel-MAC Relaxed PC                 June 2022

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

3.1.  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 (Section 3.2 of [RFC8967]) 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 Section 4.3 of [RFC8967] 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

Chroboczek & Høiland-JørExpires 13 December 2022                [Page 3]
Internet-Draft            Babel-MAC Relaxed PC                 June 2022

   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:

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

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

Chroboczek & Høiland-JørExpires 13 December 2022                [Page 4]
Internet-Draft            Babel-MAC Relaxed PC                 June 2022

3.2.  Window-based validation

   Window-based validation is similar to that described in Section 3.4.3
   of [RFC4303].  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.

   1.  If the window index is negative, the packet is considered too old
       and MUST be discarded.

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

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

Chroboczek & Høiland-JørExpires 13 December 2022                [Page 5]
Internet-Draft            Babel-MAC Relaxed PC                 June 2022

   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.

3.3.  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 Section 3.2;
   otherwise, the unicast window MUST be consluted and possibly updated.

4.  Security considerations

   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.

5.  Acknowledgments

   The authors are indebted to Daniel Gröber, who first identified
   the problem that the procedures in this document aim to solve.

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

   [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/rfc/rfc2119>.

Chroboczek & Høiland-JørExpires 13 December 2022                [Page 6]
Internet-Draft            Babel-MAC Relaxed PC                 June 2022

   [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/rfc/rfc8174>.

7.  Informative references

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

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

Chroboczek & Høiland-JørExpires 13 December 2022                [Page 7]