rfc9467.original.xml   rfc9467.xml 
<?xml version='1.0' encoding='UTF-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc>
<rfc version='3' <!-- draft submitted in xml v3 -->
docName='draft-ietf-babel-mac-relaxed-05'
ipr='trust200902' <!DOCTYPE rfc [
consensus='true' <!ENTITY nbsp "&#160;">
submissionType='IETF' <!ENTITY zwsp "&#8203;">
category='std' <!ENTITY nbhy "&#8209;">
updates='8967' <!ENTITY wj "&#8288;">
xml:lang='en' ]>
xmlns:xi="http://www.w3.org/2001/XInclude">
<rfc 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> <front>
<title abbrev='Babel-MAC Relaxed PC'> <title abbrev='Babel MAC Relaxed PC'>
Relaxed Packet Counter Verification for Babel MAC Authentication Relaxed Packet Counter Verification for Babel MAC Authentication
</title> </title>
<seriesInfo name="RFC" value="9467"/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"> <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>IRIF, University of Paris-Cité</organization> <organization>IRIF, University of Paris-Cité</organization>
<address> <address>
<postal> <postal>
<street>Case 7014</street> <street>Case 7014</street>
<city>Paris CEDEX 13</city> <city>Paris CEDEX 13</city>
<code>75205</code> <code>75205</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>jch@irif.fr</email> <email>jch@irif.fr</email>
skipping to change at line 38 skipping to change at line 53
</author> </author>
<author fullname='Toke Høiland-Jørgensen' initials='T.' <author fullname='Toke Høiland-Jørgensen' initials='T.'
surname='Høiland-Jørgensen'> surname='Høiland-Jørgensen'>
<organization>Red Hat</organization> <organization>Red Hat</organization>
<address> <address>
<email>toke@toke.dk</email> <email>toke@toke.dk</email>
</address> </address>
</author> </author>
<date year='2023' month='June' day='12'/> <date year='2023' month='August'/>
<area>rtg</area>
<workgroup>babel</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<!--[rfced] We note that MAC was not expanded in the title of RFC 8967
due to author preference. We have left it unexpanded here to
match that preference. Please let us know if expansion is
desired.
Original:
Relaxed Packet Counter Verification for Babel MAC Authentication
-->
<!--[rfced] In the Abstract, we have made a few updates. Please
review and confirm or provide alternate suggestions.
a) We have clarified that this document is relaxing the packet
verification rules in RFC 8967.
b) We have attempted to clarify what "it" was referring to. Please
let us know if further updates are necessary.
Original:
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.
Current:
This document relaxes packet verification rules defined in "MAC
Authentication for the Babel Routing Protocol" (RFC 8967) in order to
make the rules more robust in the presence of packet reordering.
-->
<abstract> <abstract>
<t>This document relaxes packet verification rules defined in the Babel <t>This document relaxes packet verification rules defined in "MAC Authenticatio
MAC Authentication protocol in order to make it more robust in the n for the Babel Routing Protocol" (RFC 8967) in order to make the rules more rob
ust in the
presence of packet reordering. This document updates RFC 8967 by relaxing presence of packet reordering. This document updates RFC 8967 by relaxing
the packet validation rules defined therein.</t> the packet validation rules defined therein.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section><name>Introduction</name> <section><name>Introduction</name>
<t>The design of the Babel MAC authentication mechanism <xref <t>The design of the Babel MAC authentication mechanism <xref
target="RFC8967"/> assumes that packet reordering is an exceptional target="RFC8967"/> assumes that packet reordering is an exceptional
occurrence, and the protocol drops any packets that arrive out-of-order. occurrence, and the protocol drops any packets that arrive out-of-order.
The assumption that packets are not routinely reordered is generally The assumption that packets are not routinely reordered is generally
correct on wired links, but turns out to be incorrect on some kinds of correct on wired links, but turns out to be incorrect on some kinds of
wireless links.</t> wireless links.</t>
<t>In particular, IEEE 802.11 (Wi-Fi) <xref target="IEEE80211"/> defines <t>In particular, IEEE 802.11 (Wi-Fi) <xref target="IEEE80211"/> defines
a number of power-saving modes that allow stations (mobile nodes) to a number of power-saving modes that allow stations (mobile nodes) to
switch their radio off for extended periods of time, ranging in the switch their radio off for extended periods of time, ranging in the
hundreds of milliseconds. The access point (network switch) buffers all hundreds of milliseconds. The access point (network switch) buffers all
multicast packets, and only sends them out after the power-saving interval 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 ends. The result is that multicast packets are delayed by up to a few
hundred milliseconds with respect to unicast packets, which, under some hundred milliseconds with respect to unicast packets. Under some
traffic patterns, causes the Packet Counter (PC) verification procedure in traffic patterns, this causes the Packet Counter (PC) verification procedure in
RFC 8967 to systematically fail for multicast packets.</t> RFC 8967 to systematically fail for multicast packets.</t>
<t>This document defines two distinct ways to relax the PC validation: <!--[rfced] FYI - we have reformatted this sentence to appear as a
using two separate receiver-side states, one for unicast and one for bulleted list for the ease of the reader. Please let us know any
objections.
Original:
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).
Current:
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).
-->
<t>This document defines two distinct ways to relax the PC 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 multicast packets (<xref target="separate-pc"/>), which allows arbitrary
reordering between unicast and multicast packets, and using a window of reordering between unicast and multicast packets, and</li>
<li>using a window of
previously received PC values (<xref target="window"/>), which allows previously received PC values (<xref target="window"/>), which allows
a bounded amount of reordering between arbitrary packets. We assume that a bounded amount of reordering between arbitrary packets.</li></ul>
<t>We assume that
reordering between arbitrary packets only happens occasionally, and, since reordering between arbitrary packets only happens occasionally, and, since
Babel is designed to gracefully deal with occasional packet loss, usage of 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 former mechanism is <bcp14>RECOMMENDED</bcp14>, while usage of the latter is
The two mechanisms MAY be used simultaneously (<xref target="combining"/>).</t> <bcp14>OPTIONAL</bcp14>.
The two mechanisms <bcp14>MAY</bcp14> be used simultaneously (<xref target="comb
ining"/>).</t>
<t>This document updates RFC 8967 by relaxing the packet validation rules <t>This document updates RFC 8967 by relaxing the packet validation rules
defined therein. It does not change the security properties of the protocol.</t > defined therein. It does not change the security properties of the protocol.</t >
</section> </section>
<section><name>Specification of Requirements</name> <section><name>Specification of Requirements</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section><name>Relaxing PC validation</name> <section><name>Relaxing PC Validation</name>
<!--[rfced] In the following, might rephrasing "by more than one
between two packets" help the reader? If our suggestion is not
correct, please let us know how we may update to make this
sentence.
Original:
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.
Perhaps:
Notwithstanding the name, the PC does not actually
count packets: a sender is permitted to increment the PC by more than
one between two sequentially received packets.
-->
<t>The Babel MAC authentication mechanism prevents replay by decorating <t>The Babel MAC authentication mechanism prevents replay by decorating
every sent packet with a strictly increasing value, the Packet Counter every sent packet with a strictly increasing value, the Packet Counter
(PC). Notwithstanding the name, the PC does not actually count packets: (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 a sender is permitted to increment the PC by more than one between two
packets.</t> packets.</t>
<t>A receiver maintains the highest PC received from each neighbour. When <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 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, 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 the packet is discarded; otherwise, the packet is accepted, and the
highest PC value for that neighbour is updated.</t> highest PC value for that neighbour is updated.</t>
<!--[rfced] In the following, is "single sender state" singular or
plural?
Original:
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.
Perhaps A:
The receiver states corresponding to single
sender states 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.
Perhaps B:
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>Note that there does not exist a one-to-one correspondence between <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 states and receiver states: multiple receiver states track a single
sender state. The receiver states corresponding to single sender state sender state. The receiver states corresponding to single sender state
are not necessarily identical, since only a subset of receiver states are 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 updated when a packet is sent to a unicast address or when a multicast
packet is received by a subset of the receivers.</t> packet is received by a subset of the receivers.</t>
<section anchor="separate-pc"><name>Multiple highest PC values</name> <section anchor="separate-pc"><name>Multiple Highest PC Values</name>
<t>Instead of a single highest PC value maintained for each neighbour, an <t>Instead of maintaining a single highest PC value for each neighbour, an
implementation of the procedure described in this section uses two values, implementation of the procedure described in this section uses two values:
the highest multicast value PCm and the highest non-multicast (unicast) the highest multicast value PCm and the highest non-multicast (unicast)
value PCu. More precisely, the (Index, PC) pair contained in the value PCu.</t>
<t>More precisely, the (Index, PC) pair contained in the
neighbour table (<relref target="RFC8967" section="3.2"/>) is replaced neighbour table (<relref target="RFC8967" section="3.2"/>) is replaced
by:</t> by a triple (Index, PCm, PCu), where:</t>
<ul> <ul>
<li>a triple (Index, PCm, PCu), where Index is an arbitrary string of 0 to <li>Index is an arbitrary string of 0 to
32 octets, and PCm and PCu are 32-bit (4-octet) integers.</li> 32 octets, and</li>
<li>PCm and PCu are 32-bit (4-octet) integers.</li>
</ul> </ul>
<t>When a challenge reply is successful, both highest PC values are updated <t>When a Challenge Reply is successful, both highest PC values are updated
to the value contained in the PC TLV from the packet containing the to the value contained in the PC TLV from the packet containing the
successful challenge. More precisely, the last sentence of the fourth successful challenge. More precisely, the last sentence of the fourth
bullet point of <relref target="RFC8967" section="4.3"/> is replaced bullet point of <relref target="RFC8967" section="4.3"/> is replaced
by:</t> as follows:</t>
<ul>
<li>If the packet contains a successful Challenge Reply, then the Index <!--[rfced] For the ease of the reader, we have added in the text from
contained in the PC TLV MUST be stored in the Index field of the neighbour RFC 8967 that is being updated by adopting an Old/New format that
we frequently see in RFCs. Please let us know any
objections. -->
<t>OLD:</t>
<blockquote>
<t>The preparse phase above yields two pieces of data: the PC and Index from t
he first PC TLV, and a bit indicating whether the packet contains a successful C
hallenge Reply. If the packet does not contain a PC TLV, the packet <bcp14>MUST<
/bcp14> 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 <bcp1
4>MUST</bcp14> be stored in the neighbour table entry corresponding to the sende
r (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 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 case), the PC contained in the TLV <bcp14>MUST</bcp14> be stored in both the PCm
PCu fields of the neighbour table entry, and the packet is accepted.</li> and
</ul> PCu fields of the neighbour table entry, and the packet is accepted.</t>
</blockquote>
<t>When a packet that does not contain a successful challenge reply is <t>When a packet that does not contain a successful Challenge Reply is
received, the PC value that it contains is compared to either the PCu or 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 the PCm field of the corresponding neighbour entry, depending on whether
the packet was sent to a muticast address or not. If the comparison is or not the packet was sent to a multicast address. If the comparison is
successful, then the same value (PCm or PCu) is updated. More precisely, successful, then the same value (PCm or PCu) is updated. More precisely,
the last bullet point of <relref target="RFC8967" section="4.3"/> is the last bullet point of <relref target="RFC8967" section="4.3"/> is
replaced by:</t> replaced as follows:</t>
<ul> <t>OLD:</t>
<li>At this stage, the packet contains no successful challenge reply and <blockquote>
<t>At this stage, the packet contains no successful Challenge Reply, and the I
ndex 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 c
ontained 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 is sent in this case, since the mismatch migh
t be caused by harmless packet reordering on the link). Otherwise, the PC contai
ned in the neighbour table entry is set to the received PC, and the packet is ac
cepted.</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 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 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 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 the IP 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 received PC is smaller than or equal to the value contained in the neighbour
table, the packet MUST be dropped and processing stops (no challenge is table, the packet <bcp14>MUST</bcp14> be dropped and processing stops. Note that
no challenge is
sent in this case, since the mismatch might be caused by harmless packet 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 reordering on the link. Otherwise, the PCm (if the packet was sent to
a multicast address) or the PCu (otherwise) field contained in the a multicast address) or the PCu (otherwise) field contained in the
neighbour table entry is set to the received PC, and the packet is neighbour table entry is set to the received PC, and the packet is
accepted.</li> accepted.</t></blockquote>
</ul>
<section><name>Generalisations</name> <section><name>Generalisations</name>
<t>Modern networking hardware tends to maintain more than just two queues, <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 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 just 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 distinct last PC values for packets received with different values of the
Type of Service (ToS) field, or with different IEEE 802.11 <xref Type of Service (TOS) field, or with different IEEE 802.11 access categories. H
target="IEEE80211"/> access categories. However, choosing a highest PC owever, choosing the highest PC
field by consulting a value that is not protected by the MAC (<relref field by consulting a value that is not protected by the Message Authentication
Code (MAC) (<relref
target="RFC8967" section="4.1"/>) would no longer protect against replay. target="RFC8967" section="4.1"/>) would no longer protect against replay.
<!--[rfced] In the following text, are destination address and port
number combined as one idea or should the list contain 3 items?
Original:
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,...
Perhaps:
In effect, this means that only the destination address, port
number, and data stored in the packet body may be used for choosing
the highest PC value,...
-->
In effect, this means that only the destination address and port number 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 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 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 addition to the source address and port number, which are already used
when choosing the neighbour table entry and therefore provide no when choosing the neighbour table entry and therefore provide no
additional information). Since Babel implementations do not usually send additional information). Since Babel implementations do not usually send
packets with differing ToS values or IEEE 802.11 access categories, this packets with differing TOS values or IEEE 802.11 access categories, this
is unlikely to be an issue in practice.</t> is unlikely to be an issue in practice.</t>
<t>The following example shows why it would be unsafe to select the highest <t>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 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, 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 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 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 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 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 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.</t> T2, which is still equal to 42, and accept the replayed packet.</t>
</section> </section>
</section> </section>
<section anchor="window"><name>Window-based validation</name> <section anchor="window"><name>Window-Based Validation</name>
<t>Window-based validation is similar to what is described in <relref <t>Window-based validation is similar to what is described in <relref
target="RFC4303" section="3.4.3"/>. When using window-based validation, target="RFC4303" section="3.4.3"/>. When using window-based validation,
in addition to retaining within its neighbour table the highest PC value in addition to retaining within its neighbour table the highest PC value
PCh seen from every neighbour, an implementation maintains a fixed-size PCh seen from every neighbour, an implementation maintains a fixed-size
window of booleans corresponding to PC values directly below PCh. More window of booleans corresponding to PC values directly below PCh. More
precisely, the (Index, PC) pair contained in the neighbour table (<relref precisely, the (Index, PC) pair contained in the neighbour table (<relref
target="RFC8967" section="3.2"/>) is replaced by:</t> 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 <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 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> of booleans of size S (the default value S=128 is <bcp14>RECOMMENDED</bcp14>).</ li>
</ul> </ul>
<!--[rfced] Please confirm that the edits to the following sentence
maintain your intended meaning.
Original:
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.
Current:
Shifting the window
to the left by an integer amount k is defined as moving all values:
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>The window is a vector of S boolean values numbered from 0 (the "left <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 edge" of the window) up to S-1 (the "right edge"). The boolean associated
with the index i indicates whether a packet with PC value (PCh - (S-1) + i) 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 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 amount k is defined as moving all values: the value previously at
index n is now at index (n - k); k values are discarded at the left edge, 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> 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> <t>Whenever a packet is received, the receiver computes its <em>index</em>
i = (PC - PCh + S - 1). It then proceeds as follows:</t> 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, <li>If the index i is negative, the packet is considered too old,
and MUST be discarded.</li> and it <bcp14>MUST</bcp14> be discarded.</li>
<li>If the index i is non-negative and strictly less than the <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 this window size S, the window value at the index is checked. If this
value is already set, the received PC has been seen before and the value is already set, the received PC has been seen before and the
packet MUST be discarded. Otherwise, the corresponding window value is packet <bcp14>MUST</bcp14> be discarded. Otherwise, the corresponding window
marked as set, and the packet is accepted.</li> 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 <li>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 is strictly larger than PCh), the window <bcp14>MUST</bcp14> be shifted to the
(i - S + 1) values (or, equivalently, by the difference PC - PCh) and left by
the highest PC value PCh MUST be set to the received PC. The value at (i - S + 1) values (or, equivalently, by the difference PC - PCh), and
the right of the window (the value with index S - 1) MUST be set, and the highest PC value PCh <bcp14>MUST</bcp14> be set to the received PC. The v
alue at
the right of the window (the value with index S - 1) <bcp14>MUST</bcp14> be se
t, and
the packet is accepted.</li> the packet is accepted.</li>
</ol> </ol>
<t>When receiving a successful Challenge Reply, the remembered highest PC <t>When receiving a successful Challenge Reply, the remembered highest PC
value PCh MUST be set to the value received in the challenge reply, and value PCh <bcp14>MUST</bcp14> be set to the value received in the Challenge Repl
all of the values in the window MUST be reset except the value at index y, and
S - 1, which MUST be set.</t> all of the values in the window <bcp14>MUST</bcp14> be reset except the value at
index
S - 1, which <bcp14>MUST</bcp14> be set.</t>
</section> </section>
<section anchor="combining"><name>Combining the two techniques</name> <section anchor="combining"><name>Combining the Two Techniques</name>
<t>The two techniques described above serve complementary purposes: <t>The two techniques described above serve complementary purposes:</t>
splitting the state allows multicast packets to be reordered with respect <ul>
to unicast ones by an arbitrary number of PC values, while the <li>splitting the state allows multicast packets to be reordered with respect
window-based technique allows arbitrary packets to be reordered but only to unicast ones by an arbitrary number of PC values, and</li>
by a bounded number of PC values. Thus, they can profitably be combined.</t> <li>the window-based technique allows arbitrary packets to be reordered but on
ly
by a bounded number of PC values.</li></ul><t> Thus, they can profitably be comb
ined.</t>
<t>An implementation that uses both techniques MUST maintain, for every <t>An implementation that uses both techniques <bcp14>MUST</bcp14> maintain, for
entry of the neighbour table, two distinct windows, one for multicast and every
one for unicast packets. When a successful challenge reply is received, entry of the neighbour table, two distinct windows: one for multicast and
both windows MUST be reset. When a packet that does not contain one for unicast packets. When a successful Challenge Reply is received,
a challenge reply is received, then if the packet's destination address is both windows <bcp14>MUST</bcp14> be reset. When a packet that does not contain
a multicast address, the multicast window MUST be consulted and possibly a Challenge Reply is received, if the packet's destination address is
updated, as described in <xref target="window"/>; otherwise, the unicast a multicast address, the multicast window <bcp14>MUST</bcp14> be consulted and p
window MUST be consulted and possibly updated.</t> ossibly
updated, as described in <xref target="window"/>. Otherwise, the unicast
window <bcp14>MUST</bcp14> be consulted and possibly updated.</t>
</section> </section>
</section> </section>
<section><name>Security considerations</name> <section><name>Security Considerations</name>
<t>The procedures described in this document do not change the security <t>The procedures described in this document do not change the security
properties described in Section 1.2 of RFC 8967. In particular, the properties described in <xref target="RFC8967" sectionFormat="of"
choice between the multicast and the unicast packet counter is done by section="1.2"/>. In particular, the choice between the multicast and the
examining a packet's destination IP address, which is included in the unicast packet counter is made by examining a packet's destination IP address,
pseudo-header and therefore participates in MAC computation; hence, an which is included in the pseudo-header and therefore participates in MAC
attacker cannot change the destination address without invalidating the computation. Hence, an attacker cannot change the destination address without
MAC, and therefore cannot replay a unicast packet as a multicast one or invalidating the MAC; therefore, it cannot replay a unicast packet as a
vice versa.</t> multicast one or vice versa.</t>
<t>While these procedures do slightly increase the amount of per-neighbour <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 state maintained by each node, this increase is marginal (between 4 and 36
octets per neighbour, depending on implementation choices), and should not octets per neighbour, depending on implementation choices), and should not
significantly impact the ability of nodes to survive denial-of-service significantly impact the ability of nodes to survive denial-of-service
attacks.</t> attacks.</t>
</section> </section>
<section title="IANA Considerations"> <section title="IANA Considerations">
<t>This document requires no IANA actions.</t> <t>This document 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> </section>
</middle> </middle>
<back> <back>
<references><name>Normative references</name> <references><name>Normative References</name>
<reference anchor="RFC8967" target="https://www.rfc-editor.org/info/rfc8967"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8967.xml"
<front> />
<title>MAC Authentication for the Babel Routing Protocol</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
<author initials="C." surname="Dô" fullname="C. Dô"/> />
<author initials="W." surname="Kolodziejak" fullname="W. Kolodziejak"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<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> </references>
<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> <references><name>Informative References</name>
<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> <!-- [rfced] FYI, to match past RFCs, we updated the reference [IEEE80211] as
follows. Please let us know if there are any objections.
<references><name>Informative references</name> Original:
[IEEE80211]
"IEEE Standard for Information Technology —
Telecommunications and information exchange between
systems Local and metropolitan area networks — Specific
requirements — Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications.",
<https://ieeexplore.ieee.org/document/9363693>.
Current:
[IEEE80211]
IEEE, "IEEE Standard for Information Technology -
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks - Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications",
DOI 10.1109/IEEESTD.2021.9363693, IEEE Std 802.11-2020,
February 2021,
<https://ieeexplore.ieee.org/document/9363693>.
-->
<reference anchor="IEEE80211" target="https://ieeexplore.ieee.org/document/93636 93"> <reference anchor="IEEE80211" target="https://ieeexplore.ieee.org/document/93636 93">
<front> <front>
<title>IEEE Standard for Information Technology — Telecommunications and <title>IEEE Standard for Information Technology--Telecommunications and
information exchange between systems Local and metropolitan area Information Exchange between Systems - Local and Metropolitan Area
networks — Specific requirements — Part 11: Wireless LAN Medium Access Networks--Specific requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications.</title> Control (MAC) and Physical Layer (PHY) Specifications</title>
<author/> <author>
</front> <organization>IEEE</organization>
</reference> </author>
<date month="February" year="2021"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
<seriesInfo name="IEEE Std" value="802.11-2020"/>
</reference>
<reference anchor='RFC4303' target='https://www.rfc-editor.org/info/rfc4303'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"
<front> />
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials='S.' surname='Kent' fullname='S. Kent'/>
<date year='2005' month='December' />
</front>
<seriesInfo name='RFC' value='4303'/>
<seriesInfo name='DOI' value='10.17487/RFC4303'/>
</reference>
</references> </references>
<section title="Acknowledgments" numbered="false">
<!--[rfced] In the following, can we assume "that document" refers to
RFC 8967?
Original:
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.
Perhaps:
The authors are greatly indebted to Daniel Gröber, who first
identified the problem RFC 8967 aims to solve and first
suggested the solution described in Section 3.1.
-->
<t>The authors are greatly indebted to <contact fullname="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>
<!--[rfced] We had the following questions related to terminology use
throughout the document:
a) We see both "packet verification rules" and "packet validation
rules". May we make these consistently "packet verification rules"?
Please see b) below before prior to a decision.
b) Related to a) above, we see the following:
Packet Counter Verification
Packet Counter (PC) verification procedure
Are "packet verification rules" and "packet validation rules" really
"Packet Counter verification" rules? Should the latter form be used
throughout? (Or perhaps use "PC verification rules" after the
abbreviation is introduced?)
c) Please note that we have consistently capped "Challenge Reply" to
match its use in RFC 8967. Please review and confirm.
d) This document uses "index", "Index", and 1 instance of
"<em>index</em>". Please review and let us know if/how to update
these for uniformity.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 64 change blocks. 
168 lines changed or deleted 432 lines changed or added

This html diff was produced by rfcdiff 1.48.