wdiff rfc9467.original.xml rfc9467.xml

<?xml version='1.0' encoding='UTF-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc> rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc version='3'
     docName='draft-ietf-babel-mac-relaxed-05'
     ipr='trust200902'
     consensus='true'
     submissionType='IETF'
     category='std'
     updates='8967'
     xml:lang='en'
     xmlns:xi="http://www.w3.org/2001/XInclude"> version="3"
     docName="draft-ietf-babel-mac-relaxed-05"
     number="9467"
     ipr="trust200902"
     submissionType="IETF"
     category="std"
     consensus="true"
     updates="8967"
     obsoletes=""
     xml:lang="en"
     xmlns:xi="http://www.w3.org/2001/XInclude"
     tocInclude="true"
     symRefs="true"
     sortRefs="true">

<front>
<title abbrev='Babel-MAC abbrev='Babel MAC Relaxed PC'> Verification'>
Relaxed Packet Counter Verification for Babel MAC Authentication
</title>
<seriesInfo name="RFC" value="9467"/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>IRIF, University of Paris-Cité</organization>
<address>
<postal>
<street>Case 7014</street>
<city>Paris CEDEX 13</city>
<code>75205</code>
<country>France</country>
</postal>
<email>jch@irif.fr</email>
</address>
</author>

<author fullname='Toke Høiland-Jørgensen' initials='T.'
        surname='Høiland-Jørgensen'>
  <organization>Red Hat</organization>
  <address>
    <email>toke@toke.dk</email>
  </address>
</author>

<date year='2023' month='June' day='12'/> year='2024' month='January'/>
<area>rtg</area>
<workgroup>babel</workgroup>

<keyword>security, authentication, packet reordering, wifi</keyword>

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

<middle>

<section><name>Introduction</name>

<t>The design of the Babel MAC authentication mechanism <xref
target="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.</t>

<t>In particular, IEEE 802.11 (Wi-Fi) <xref target="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, 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 Packet Counter (PC) verification procedure in
RFC 8967 to systematically fail for multicast packets.</t>

<t>This document defines two distinct ways to relax the PC validation:
using validation:</t>
<ul>
<li>using two separate receiver-side states, one for unicast and one for
multicast packets (<xref target="separate-pc"/>), which allows arbitrary
reordering between unicast and multicast packets, and using and</li>
<li>using a window of
previously received PC values (<xref target="window"/>), which allows
a bounded amount of reordering between arbitrary packets.  We packets.</li></ul>
<t>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, <bcp14>RECOMMENDED</bcp14>, while usage of the latter is OPTIONAL. <bcp14>OPTIONAL</bcp14>.
The two mechanisms MAY <bcp14>MAY</bcp14> be used simultaneously (<xref target="combining"/>).</t>

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

</section>

<section><name>Specification of Requirements</name>

<t>The

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
"OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

</section>

<section><name>Relaxing PC validation</name> Verification</name>

<t>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 successively transmitted packets.</t>

<t>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:</t>
<ul><li>if the new value is smaller or equal,
then the packet is discarded; otherwise, discarded;</li>
<li>otherwise, the packet is accepted, and the
highest PC value for that neighbour is updated.</t> updated.</li></ul>

<t>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 a 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.</t>

<section anchor="separate-pc"><name>Multiple highest Highest PC values</name> Values</name>

<t>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 (<relref target="RFC8967" section="3.2"/>) is replaced
by:</t>
<ul>
<li>a
by a triple (Index, PCm, PCu), where Index where:</t>
<ul>
  <li>Index is an arbitrary string of 0 to 32 octets, and PCm and</li>
  <li>PCm and PCu are 32-bit (4-octet) integers.</li>
</ul>

<t>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 <relref target="RFC8967" section="4.3"/> is replaced
by:</t>
<ul>
<li>If
as follows:</t>

<t>OLD:</t>
<blockquote>
<t>If the packet contains a successful Challenge Reply, then the PC
and Index contained in the PC TLV MUST <bcp14>MUST</bcp14> be stored in the
neighbour table entry corresponding to the sender (which already exists in
this case), and the packet is accepted.</t>

</blockquote>
<t>NEW:</t>
<blockquote>
<t>If the packet contains a successful Challenge Reply, then the Index
contained in the PC TLV <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be stored in both the PCm and
PCu fields of the neighbour table entry, and the packet is accepted.</li>
</ul> accepted.</t>
</blockquote>

<t>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 <relref target="RFC8967" section="4.3"/> is
replaced by:</t>
<ul>
<li>At as follows:</t>
<t>OLD:</t>
<blockquote>
<t>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 <bcp14>MUST</bcp14> 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.</t>
</blockquote>
<t>NEW:</t>
<blockquote>
<t>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 <bcp14>MUST</bcp14> 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.</li>
</ul>
accepted.</t></blockquote>

<section><name>Generalisations</name>

<t>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 the 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) (TOS) field, or with different IEEE 802.11 <xref
target="IEEE80211"/> access
categories.  However, choosing a highest PC field by consulting a value
that is not protected by the MAC Message Authentication Code (MAC) (<relref
target="RFC8967" section="4.1"/>) would no longer protect against replay.
In effect, this means that only the destination address and port number
and
as well as the 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 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.</t>

<t>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.</t>
</section>

</section>

<section anchor="window"><name>Window-based validation</name> anchor="window"><name>Window-Based Verification</name>

<t>Window-based validation verification is similar to what is described in <relref
target="RFC4303" section="3.4.3"/>.  When using window-based validation, verification,
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 (<relref
target="RFC8967" section="3.2"/>) is replaced by:</t>
<ul>
<ul spacing="normal">
<li>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).</li> <bcp14>RECOMMENDED</bcp14>).</li>
</ul>

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

<t>Whenever a packet is received, the receiver computes its <em>index</em> index
i = (PC - PCh + S - 1).  It then proceeds as follows:</t>
<ol>
<ol spacing="normal">
  <li>If the index i is negative, the packet is considered too old,
  and MUST it <bcp14>MUST</bcp14> be discarded.</li>

  <li>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 <bcp14>MUST</bcp14> be discarded.  Otherwise, the corresponding window value is marked as set, and the packet is accepted.</li>

  <li>If the index i is larger or equal to the window size (i.e., PC
  is strictly larger than PCh), the window MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be set to the received PC.  The value at
  the right of the window (the value with index S - 1) MUST <bcp14>MUST</bcp14> be set, and
  the packet is accepted.</li>
</ol>

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

</section>

<section anchor="combining"><name>Combining the two techniques</name> Two Techniques</name>

<t>The two techniques described above serve complementary purposes:
splitting purposes:</t>
<ul>
  <li>splitting the state allows multicast packets to be reordered with respect
  to unicast ones by an arbitrary number of PC values, while the while</li>
  <li>the window-based technique allows arbitrary packets to be reordered but only
by a bounded number of PC values. values.</li></ul><t> Thus, they can profitably be combined.</t>

<t>An implementation that uses both techniques MUST <bcp14>MUST</bcp14> maintain, for every
entry of the neighbour table, two distinct windows, one for multicast and
one for unicast packets.  When a successful challenge reply Challenge Reply is received,
both windows MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be consulted and possibly
updated, as described in <xref target="window"/>; otherwise, target="window"/>. Otherwise, the unicast
window MUST <bcp14>MUST</bcp14> be consulted and possibly updated.</t>

</section>

</section>

<section><name>Security considerations</name> Considerations</name>

<t>The procedures described in this document do not change the security
properties described in Section 1.2 of RFC 8967. <xref target="RFC8967" sectionFormat="of"
section="1.2"/>.  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 cannot replay a unicast packet as a
multicast one or vice versa.</t>

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

</section>

<section title="IANA Considerations">

  <t>This document requires has no IANA actions.</t>

</section>

<section title="Acknowledgments">

<t>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 <xref target="separate-pc"/>.</t>

</section>

</middle>

<back>
<references><name>Normative references</name>

<reference anchor="RFC8967" target="https://www.rfc-editor.org/info/rfc8967">
<front>
<title>MAC Authentication for the Babel Routing Protocol</title>
<author initials="C." surname="Dô" fullname="C. Dô"/>
<author initials="W." surname="Kolodziejak" fullname="W. Kolodziejak"/>
<author initials="J." surname="Chroboczek" fullname="J. Chroboczek"/>
<date year="2021" month="January"/>
</front>
<seriesInfo name="RFC" value="8967"/>
<seriesInfo name="DOI" value="10.17487/RFC8967"/>
</reference>

<reference anchor="RFC2119"><front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"/>
<date year="1997" month="March"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>

<reference anchor="RFC8174"><front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba"/>
<date year="2017" month="May"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> References</name>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8967.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

</references>

<references><name>Informative references</name> References</name>

<reference anchor="IEEE80211" target="https://ieeexplore.ieee.org/document/9363693">
<front>
<title>IEEE Standard for Information Technology — Telecommunications 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.</title>
<author/>
</front>
</reference>

<reference anchor='RFC4303' target='https://www.rfc-editor.org/info/rfc4303'>
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials='S.' surname='Kent' fullname='S. Kent'/> Specifications</title>
          <author>
            <organization>IEEE</organization>
          </author>
          <date year='2005' month='December' /> month="February" year="2021"/>
        </front>
        <seriesInfo name='RFC' value='4303'/> name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
        <seriesInfo name='DOI' value='10.17487/RFC4303'/> name="IEEE Std" value="802.11-2020"/>
      </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>

</references>

<section title="Acknowledgments" numbered="false">

<t>The authors are greatly indebted to <contact fullname="Daniel Gröber"/>,
who first identified the problem that this document aims to solve and first
suggested the solution described in <xref target="separate-pc"/>.</t>

</section>
</back>
</rfc>