Network Working Group

Internet Engineering Task Force (IETF)                     J. Chroboczek
Internet-Draft
Request for Comments: 9467                IRIF, University of Paris-Cité
Updates: 8967 (if approved)                                       T. Høiland-Jørgensen
Intended status:
Category: Standards Track                                        Red Hat
Expires: 14 December 2023                                   12 June
ISSN: 2070-1721                                              August 2023

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

Abstract

   This document relaxes packet verification rules defined in "MAC
   Authentication for the Babel
   MAC Authentication protocol Routing Protocol" (RFC 8967) in order to
   make it the rules more robust in the presence of packet reordering.
   This document updates RFC 8967 by relaxing the packet validation
   rules defined therein.

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 14 December 2023.
   https://www.rfc-editor.org/info/rfc9467.

Copyright Notice

   Copyright (c) 2023 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)
   (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Relaxing PC validation  . . . . . . . . . . . . . . . . . . .   3 Validation
     3.1.  Multiple highest Highest PC values  . . . . . . . . . . . . . . .   3 Values
       3.1.1.  Generalisations . . . . . . . . . . . . . . . . . . .   4
     3.2.  Window-based validation . . . . . . . . . . . . . . . . .   5  Window-Based Validation
     3.3.  Combining the two techniques  . . . . . . . . . . . . . .   6 Two Techniques
   4.  Security considerations . . . . . . . . . . . . . . . . . . .   6 Considerations
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Normative references  . . . . . . . . . . . . . . . . . . . .   7
   8. References
   7.  Informative references  . . . . . . . . . . . . . . . . . . .   7 References
   Acknowledgments
   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.  The assumption
   that packets are not routinely reordered is generally correct on
   wired links, but turns out to be incorrect on some kinds of wireless
   links.

   In particular, IEEE 802.11 (Wi-Fi) [IEEE80211] 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 it 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 packets.
   Under some traffic patterns, this causes the Packet Counter (PC)
   verification procedure in RFC 8967 to systematically fail for
   multicast packets.

   This document defines two distinct ways to relax the PC validation:

   *  using two separate receiver-side states, one for unicast and one
      for multicast packets (Section 3.1), which allows arbitrary
      reordering between unicast and multicast packets, and

   *  using a window of previously received PC values (Section 3.2),
      which allows a bounded amount of reordering between arbitrary
      packets.

   We assume that reordering between arbitrary packets only happens
   occasionally, and, since Babel is designed to gracefully deal with
   occasional packet loss, usage of the former mechanism is RECOMMENDED,
   while usage of the latter is OPTIONAL.  The two mechanisms MAY be
   used simultaneously (Section 3.3).

   This document updates RFC 8967 by relaxing the packet validation
   rules defined therein.  It does not change the security properties of
   the protocol.

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.

3.  Relaxing PC validation 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: a sender is permitted 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 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 Highest PC values Values

   Instead of maintaining a single highest PC value maintained for each neighbour,
   an implementation of the procedure described in this section uses two
   values,
   values: the highest multicast value PCm and the highest non-multicast
   (unicast) value PCu.

   More precisely, the (Index, PC) pair contained in the neighbour table
   (Section 3.2 of [RFC8967]) is replaced by:

   * by a triple (Index, PCm, PCu), where
   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 Challenge Reply is successful, both highest PC values are
   updated to the value contained in the 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:

   * as follows:

   OLD:

   |  The preparse phase above yields two pieces of data: the PC and
   |  Index from the first PC TLV, and a bit indicating whether the
   |  packet contains a successful Challenge Reply.  If the packet does
   |  not contain a PC TLV, the packet MUST be dropped, and processing
   |  stops at this point.  If the packet contains a successful
   |  Challenge Reply, then the PC and Index contained in the PC TLV
   |  MUST be stored in the neighbour table entry corresponding to the
   |  sender (which already exists in this case), and the packet is
   |  accepted.

   NEW:

   |  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 (which
   |  already exists in this case), the PC contained in the TLV MUST be
   |  stored in both the PCm and PCu fields of the neighbour table
   |  entry, and the packet is accepted.

   When a packet that does not contain a successful challenge reply Challenge Reply is
   received, the PC value that it contains is compared to either the PCu
   or the PCm field of the corresponding neighbour entry, depending on
   whether or not the packet was sent to a muticast address or not. 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:

   * as follows:

   OLD:

   |  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 the PC contained in the neighbour
   |  table; if the received PC is smaller or equal than the PC
   |  contained in the neighbour table, the packet MUST be dropped and
   |  processing stops (no challenge reply is sent in this case, since the
   |  mismatch might be caused by harmless packet reordering on the
   |  link).  Otherwise, the PC contained in the neighbour table entry
   |  is set to the received PC, and the packet is accepted.

   NEW:

   |  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 the PCm field (if the packet
   |  was sent to a multicast IP address) or the PCu field (otherwise)
   |  in the neighbour table; if table.  If the received PC is smaller than or
   |  equal
      than to the value contained in the neighbour table, the packet
   |  MUST be dropped and processing stops (no stops.  Note that no challenge is
   |  sent in this case, since the mismatch might be caused by harmless
   |  packet reordering on the link). 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 the last two 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) (TOS) field, or with
   different IEEE 802.11 [IEEE80211] access categories.  However, choosing a the
   highest PC field by consulting a value that is not protected by the MAC
   Message Authentication Code (MAC) (Section 4.1 of [RFC8967]) would no
   longer protect against replay.  In effect, 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 value.  This is because
   these are the only fields that are protected by the MAC (in addition
   to the source address and port number, which are already used when
   choosing the neighbour table entry and therefore provide no
   additional information).  Since Babel implementations do not usually
   send packets with differing ToS TOS values or IEEE 802.11 access
   categories, this is unlikely to be an issue in practice.

   The following example shows why it would be unsafe to select the
   highest PC depending on the ToS TOS field.  Suppose that a node B were to
   maintain distinct highest PC values for different values T1 and T2 of
   the ToS TOS field, and that initially 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 TOS
   equal to T1 and PC equal to 43; when B receives the packet, it sets
   the highest PC value associated with ToS TOS T1 to 43.  If an attacker
   were now to send an exact copy of P1 but with ToS 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.

3.2.  Window-based validation  Window-Based Validation

   Window-based validation is similar to what is described in
   Section 3.4.3 of [RFC4303].  When using window-based validation, in
   addition to retaining within its neighbour table the highest PC value
   PCh seen from every neighbour, an implementation maintains a fixed-
   size window of booleans corresponding to PC values directly below
   PCh.  More precisely, the (Index, PC) pair contained in the neighbour
   table (Section 3.2 of [RFC8967]) is replaced by:

   *  a triple (Index, PCh, Window), where Index is an arbitrary string
      of 0 to 32 octets, PCh is a 32-bit (4-octet) integer, and Window
      is a vector of booleans of size S (the default value S=128 is
      RECOMMENDED).

   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"); the edge").  The boolean
   associated with the index i indicates whether a packet with a PC
   value of (PCh - (S-1) + i) has been seen before.  Shifting the window
   to the left by an integer amount k is defined as moving all values so that values:
   the value previously at index n is now at index (n - k); 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, the receiver computes its _index_ i =
   (PC - PCh + S - 1).  It then proceeds as follows:

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

   2.  If the index i is non-negative and strictly less than the window
       size S, the window value at the index is checked; if 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 index i is larger or equal to the window size (i.e., PC is
       strictly larger than PCh), the window MUST be shifted to the left
       by (i - S + 1) values (or, equivalently, by the difference PC -
       PCh)
       PCh), and the highest PC value PCh MUST be set to the received
       PC.  The value at the right of the window (the value with index S
       - 1) MUST be set, and the packet is accepted.

   When receiving a successful Challenge Reply, the remembered highest
   PC value PCh MUST be set to the value received in the challenge
   reply, Challenge
   Reply, and all of the values in the window MUST be reset except the
   value at index S - 1, which MUST be set.

3.3.  Combining the two techniques Two Techniques

   The two techniques described above serve complementary purposes:

   *  splitting the state allows multicast packets to be reordered with
      respect to unicast ones by an arbitrary number of PC values, while and

   *  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 that uses both techniques MUST maintain, for every
   entry of the neighbour table, two distinct windows, windows: one for multicast
   and one for unicast packets.  When a successful challenge reply Challenge Reply is
   received, both windows MUST be reset.  When a packet that does not
   contain a challenge reply 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, 3.2.
   Otherwise, the unicast window MUST be consulted and possibly updated.

4.  Security considerations Considerations

   The procedures described in this document do not change the security
   properties described in Section 1.2 of RFC 8967. [RFC8967].  In particular, the
   choice between the multicast and the unicast packet counter is done made
   by examining a packet's destination IP address, which is included in
   the pseudo-header and therefore participates in MAC computation;
   hence, computation.
   Hence, an attacker cannot change the destination address without
   invalidating the MAC, and therefore MAC; therefore, it cannot replay a unicast packet as
   a multicast one or vice versa.

   While these procedures do slightly increase the amount of per-
   neighbour state maintained by each node, this increase is marginal
   (between 4 and 36 octets per neighbour, depending on implementation
   choices), and should not significantly impact the ability of nodes to
   survive denial-of-service attacks.

5.  IANA Considerations

   This document requires has no IANA actions.

6.  Acknowledgments

   The authors are greatly indebted to Daniel Gröber, who first
   identified the problem that document aims to solve and first
   suggested the solution described in Section 3.1.

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

   [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>.
              <https://www.rfc-editor.org/info/rfc2119>.

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

8. <https://www.rfc-editor.org/info/rfc8174>.

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

7.  Informative references References

   [IEEE80211]
              IEEE, "IEEE Standard for Information Technology — Technology--
              Telecommunications and information exchange Information Exchange between
              systems
              Systems - Local and metropolitan area networks — Specific Metropolitan Area Networks--Specific
              requirements  - Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications.", Specifications",
              DOI 10.1109/IEEESTD.2021.9363693, IEEE Std 802.11-2020,
              February 2021,
              <https://ieeexplore.ieee.org/document/9363693>.

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

Acknowledgments

   The authors are greatly indebted to Daniel Gröber, who first
   identified the problem that document aims to solve and first
   suggested the solution described in Section 3.1.

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