rfc9467.original   rfc9467.txt 
Network Working Group J. Chroboczek Internet Engineering Task Force (IETF) J. Chroboczek
Internet-Draft IRIF, University of Paris-Cité Request for Comments: 9467 IRIF, University of Paris-Cité
Updates: 8967 (if approved) T. Høiland-Jørgensen Updates: 8967 T. Høiland-Jørgensen
Intended status: Standards Track Red Hat Category: Standards Track Red Hat
Expires: 14 December 2023 12 June 2023 ISSN: 2070-1721 January 2024
Relaxed Packet Counter Verification for Babel MAC Authentication Relaxed Packet Counter Verification for Babel MAC Authentication
draft-ietf-babel-mac-relaxed-05
Abstract Abstract
This document relaxes packet verification rules defined in the Babel This document relaxes the packet verification rules defined in "MAC
MAC Authentication protocol in order to make it more robust in the Authentication for the Babel Routing Protocol" (RFC 8967) in order to
presence of packet reordering. This document updates RFC 8967 by make the protocol more robust in the presence of packet reordering.
relaxing the packet validation rules defined therein. This document updates RFC 8967.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 14 December 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9467.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements
3. Relaxing PC validation . . . . . . . . . . . . . . . . . . . 3 3. Relaxing PC Verification
3.1. Multiple highest PC values . . . . . . . . . . . . . . . 3 3.1. Multiple Highest PC Values
3.1.1. Generalisations . . . . . . . . . . . . . . . . . . . 4 3.1.1. Generalisations
3.2. Window-based validation . . . . . . . . . . . . . . . . . 5 3.2. Window-Based Verification
3.3. Combining the two techniques . . . . . . . . . . . . . . 6 3.3. Combining the Two Techniques
4. Security considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. Normative References
7. Normative references . . . . . . . . . . . . . . . . . . . . 7 7. Informative References
8. Informative references . . . . . . . . . . . . . . . . . . . 7 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses
1. Introduction 1. Introduction
The design of the Babel MAC authentication mechanism [RFC8967] The design of the Babel MAC authentication mechanism [RFC8967]
assumes that packet reordering is an exceptional occurrence, and the assumes that packet reordering is an exceptional occurrence, and the
protocol drops any packets that arrive out-of-order. The assumption protocol drops any packets that arrive out-of-order. The assumption
that packets are not routinely reordered is generally correct on that packets are not routinely reordered is generally correct on
wired links, but turns out to be incorrect on some kinds of wireless wired links, but turns out to be incorrect on some kinds of wireless
links. links.
In particular, IEEE 802.11 (Wi-Fi) [IEEE80211] defines a number of In particular, IEEE 802.11 (Wi-Fi) [IEEE80211] defines a number of
power-saving modes that allow stations (mobile nodes) to switch their power-saving modes that allow stations (mobile nodes) to switch their
radio off for extended periods of time, ranging in the hundreds of radio off for extended periods of time, ranging in the hundreds of
milliseconds. The access point (network switch) buffers all milliseconds. The access point (network switch) buffers all
multicast packets, and only sends them out after the power-saving multicast packets and only sends them out after the power-saving
interval ends. The result is that multicast packets are delayed by interval ends. The result is that multicast packets are delayed by
up to a few hundred milliseconds with respect to unicast packets, up to a few hundred milliseconds with respect to unicast packets,
which, under some traffic patterns, causes the Packet Counter (PC) which, under some traffic patterns, causes the Packet Counter (PC)
verification procedure in RFC 8967 to systematically fail for verification procedure in RFC 8967 to systematically fail for
multicast packets. multicast packets.
This document defines two distinct ways to relax the PC validation: 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 * 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 verification
rules defined therein. It does not change the security properties of rules defined therein. It does not change the security properties of
the protocol. the protocol.
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Relaxing PC validation 3. Relaxing PC Verification
The Babel MAC authentication mechanism prevents replay by decorating The Babel MAC authentication mechanism prevents replay by decorating
every sent packet with a strictly increasing value, the Packet every sent packet with a strictly increasing value, the Packet
Counter (PC). Notwithstanding the name, the PC does not actually Counter (PC). Notwithstanding the name, the PC does not actually
count packets: a sender is permitted to increment the PC by more than count packets: a sender is permitted to increment the PC by more than
one between two packets. one between two successively transmitted packets.
A receiver maintains the highest PC received from each neighbour. A receiver maintains the highest PC received from each neighbour.
When a new packet is received, the receiver compares the PC contained 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 in the packet with the highest received PC:
smaller or equal, the packet is discarded; otherwise, the packet is
accepted, and the highest PC value for that neighbour is updated. * if the new value is smaller or equal, then 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 Note that there does not exist a one-to-one correspondence between
sender states and receiver states: multiple receiver states track a sender states and receiver states: multiple receiver states track a
single sender state. The receiver states corresponding to single single sender state. The receiver states corresponding to a single
sender state are not necessarily identical, since only a subset of sender state are not necessarily identical, since only a subset of
receiver states are updated when a packet is sent to a unicast 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 address or when a multicast packet is received by a subset of the
receivers. receivers.
3.1. Multiple highest PC values 3.1. Multiple Highest PC Values
Instead of a single highest PC value maintained for each neighbour, Instead of maintaining a single highest PC value for each neighbour,
an implementation of the procedure described in this section uses two an implementation of the procedure described in this section uses two
values, the highest multicast value PCm and the highest non-multicast values: the highest multicast value PCm and the highest non-multicast
(unicast) value PCu. More precisely, the (Index, PC) pair contained (unicast) value PCu. More precisely, the (Index, PC) pair contained
in the neighbour table (Section 3.2 of [RFC8967]) is replaced by: in the neighbour table (Section 3.2 of [RFC8967]) is replaced by a
triple (Index, PCm, PCu), where:
* a triple (Index, PCm, PCu), where Index is an arbitrary string of * Index is an arbitrary string of 0 to 32 octets, and
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 * 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 the PC TLV from the packet updated to the value contained in the PC TLV from the packet
containing the successful challenge. More precisely, the last containing the successful challenge. More precisely, the last
sentence of the fourth bullet point of Section 4.3 of [RFC8967] is sentence of the fourth bullet point of Section 4.3 of [RFC8967] is
replaced by: replaced as follows:
* If the packet contains a successful Challenge Reply, then the OLD:
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 is | 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 is
received, the PC value that it contains is compared to either the PCu received, the PC value that it contains is compared to either the PCu
or the PCm field of the corresponding neighbour entry, depending on or the PCm field of the corresponding neighbour entry, depending on
whether the packet was sent to a muticast address or not. If the whether or not the packet was sent to a multicast address. If the
comparison is successful, then the same value (PCm or PCu) is comparison is successful, then the same value (PCm or PCu) is
updated. More precisely, the last bullet point of Section 4.3 of updated. More precisely, the last bullet point of Section 4.3 of
[RFC8967] is replaced by: [RFC8967] is replaced as follows:
* At this stage, the packet contains no successful challenge reply OLD:
and the Index contained in the PC TLV is equal to the Index in the
neighbour table entry corresponding to the sender. The receiver | At this stage, the packet contains no successful Challenge Reply,
compares the received PC with either the PCm field (if the packet | and the Index contained in the PC TLV is equal to the Index in the
was sent to a multicast IP address) or the PCu field (otherwise) | neighbour table entry corresponding to the sender. The receiver
in the neighbour table; if the received PC is smaller or equal | compares the received PC with the PC contained in the neighbour
than the value contained in the neighbour table, the packet MUST | table; if the received PC is smaller or equal than the PC
be dropped and processing stops (no challenge is sent in this | contained in the neighbour table, the packet MUST be dropped and
case, since the mismatch might be caused by harmless packet | processing stops (no challenge is sent in this case, since the
reordering on the link). Otherwise, the PCm (if the packet was | mismatch might be caused by harmless packet reordering on the
sent to a multicast address) or the PCu (otherwise) field | link). Otherwise, the PC contained in the neighbour table entry
contained in the neighbour table entry is set to the received PC, | is set to the received PC, and the packet is accepted.
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 the received PC is smaller than or
| equal to the value contained in the neighbour table, the packet
| MUST be dropped and processing stops. Note that 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 3.1.1. Generalisations
Modern networking hardware tends to maintain more than just two Modern networking hardware tends to maintain more than just two
queues, and it might be tempting to generalise the approach taken to 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 more than just the two last PC values. For example, one might be
to use distinct last PC values for packets received with different tempted to use distinct last PC values for packets received with
values of the Type of Service (ToS) field, or with different IEEE different values of the Type of Service (TOS) field, or with
802.11 [IEEE80211] access categories. However, choosing a highest PC different IEEE 802.11 access categories. However, choosing a highest
field by consulting a value that is not protected by the MAC PC field by consulting a value that is not protected by the Message
(Section 4.1 of [RFC8967]) would no longer protect against replay. Authentication Code (MAC) (Section 4.1 of [RFC8967]) would no longer
In effect, this means that only the destination address and port protect against replay. In effect, this means that only the
number and data stored in the packet body may be used for choosing destination address and port number as well as the data stored in the
the highest PC value, since these are the only fields that are packet body may be used for choosing the highest PC value, since
protected by the MAC (in addition to the source address and port these are the only fields that are protected by the MAC (in addition
number, which are already used when choosing the neighbour table to the source address and port number, which are already used when
entry and therefore provide no additional information). Since Babel choosing the neighbour table entry and therefore provide no
implementations do not usually send packets with differing ToS values additional information). Since Babel implementations do not usually
or IEEE 802.11 access categories, this is unlikely to be an issue in send packets with differing TOS values or IEEE 802.11 access
practice. categories, this is unlikely to be an issue in practice.
The following example shows why it would be unsafe to select the 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 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 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 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 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 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 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 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 would consult the highest PC value associated with T2, which is still
equal to 42, and accept the replayed packet. equal to 42, and accept the replayed packet.
3.2. Window-based validation 3.2. Window-Based Verification
Window-based validation is similar to what is described in Window-based verification is similar to what is described in
Section 3.4.3 of [RFC4303]. When using window-based validation, in Section 3.4.3 of [RFC4303]. When using window-based verification, in
addition to retaining within its neighbour table the highest PC value addition to retaining within its neighbour table the highest PC value
PCh seen from every neighbour, an implementation maintains a fixed- PCh seen from every neighbour, an implementation maintains a fixed-
size window of booleans corresponding to PC values directly below size window of booleans corresponding to PC values directly below
PCh. More precisely, the (Index, PC) pair contained in the neighbour PCh. More precisely, the (Index, PC) pair contained in the neighbour
table (Section 3.2 of [RFC8967]) is replaced by: table (Section 3.2 of [RFC8967]) is replaced by:
* a triple (Index, PCh, Window), where Index is an arbitrary string * 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 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 is a vector of booleans of size S (the default value S=128 is
RECOMMENDED). RECOMMENDED).
The window is a vector of S boolean values numbered from 0 (the "left 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 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 associated with the index i indicates whether a packet with a PC
(PCh - (S-1) + i) has been seen before. Shifting the window to the value of (PCh - (S-1) + i) has been seen before. Shifting the window
left by an integer amount k is defined as moving all values so that to the left by an integer amount k is defined as moving all values so
the value previously at index n is now at index (n - k); k values are that the value previously at index n is now at index (n - k); k
discarded at the left edge, and k new unset values are inserted at values are discarded at the left edge, and k new unset values are
the right edge. inserted at the right edge.
Whenever a packet is received, the receiver computes its _index_ i = Whenever a packet is received, the receiver computes its index i =
(PC - PCh + S - 1). It then proceeds as follows: (PC - PCh + S - 1). It then proceeds as follows:
1. If the index i is negative, the packet is considered too old, and 1. If the index i is negative, the packet is considered too old, and
MUST be discarded. it MUST be discarded.
2. If the index i is non-negative and strictly less than the window 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 this value 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 is already set, the received PC has been seen before and the
packet MUST be discarded. Otherwise, the corresponding window packet MUST be discarded. Otherwise, the corresponding window
value is marked as set, and the packet is accepted. 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 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 strictly larger than PCh), the window MUST be shifted to the left
by (i - S + 1) values (or, equivalently, by the difference PC - by (i - S + 1) values (or, equivalently, by the difference PC -
PCh) and the highest PC value PCh MUST be set to the received PC. PCh), and the highest PC value PCh MUST be set to the received
The value at the right of the window (the value with index S - 1) PC. The value at the right of the window (the value with index S
MUST be set, and the packet is accepted. - 1) MUST be set, and the packet is accepted.
When receiving a successful Challenge Reply, the remembered highest When receiving a successful Challenge Reply, the remembered highest
PC value PCh MUST be set to the value received in the challenge PC value PCh MUST be set to the value received in the Challenge
reply, and all of the values in the window MUST be reset except the Reply, and all of the values in the window MUST be reset except the
value at index S - 1, which MUST be set. value at index S - 1, which MUST be set.
3.3. Combining the two techniques 3.3. Combining the Two Techniques
The two techniques described above serve complementary purposes: 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 * splitting the state allows multicast packets to be reordered with
the window-based technique allows arbitrary packets to be reordered respect to unicast ones by an arbitrary number of PC values, while
but only by a bounded number of PC values. Thus, they can profitably
be combined. * 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 An implementation that uses both techniques MUST maintain, for every
entry of the neighbour table, two distinct windows, one for multicast entry of the neighbour table, two distinct windows, one for multicast
and one for unicast packets. When a successful challenge reply is and one for unicast packets. When a successful Challenge Reply is
received, both windows MUST be reset. When a packet that does not received, both windows MUST be reset. When a packet that does not
contain a challenge reply is received, then if the packet's contain a Challenge Reply is received, if the packet's destination
destination address is a multicast address, the multicast window MUST address is a multicast address, the multicast window MUST be
be consulted and possibly updated, as described in Section 3.2; consulted and possibly updated, as described in Section 3.2.
otherwise, the unicast window MUST be consulted and possibly updated. Otherwise, the unicast window MUST be consulted and possibly updated.
4. Security considerations 4. Security Considerations
The procedures described in this document do not change the security 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 Section 1.2 of [RFC8967]. In particular, the
choice between the multicast and the unicast packet counter is done choice between the multicast and the unicast packet counter is made
by examining a packet's destination IP address, which is included in by examining a packet's destination IP address, which is included in
the pseudo-header and therefore participates in MAC computation; the pseudo-header and therefore participates in MAC computation.
hence, an attacker cannot change the destination address without Hence, an attacker cannot change the destination address without
invalidating the MAC, and therefore cannot replay a unicast packet as invalidating the MAC, and therefore cannot replay a unicast packet as
a multicast one or vice versa. a multicast one or vice versa.
While these procedures do slightly increase the amount of per- While these procedures do slightly increase the amount of per-
neighbour state maintained by each node, this increase is marginal neighbour state maintained by each node, this increase is marginal
(between 4 and 36 octets per neighbour, depending on implementation (between 4 and 36 octets per neighbour, depending on implementation
choices), and should not significantly impact the ability of nodes to choices), and should not significantly impact the ability of nodes to
survive denial-of-service attacks. survive denial-of-service attacks.
5. IANA Considerations 5. IANA Considerations
This document requires no IANA actions. This document 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 6. Normative References
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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, 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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8. Informative 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>.
7. Informative References
[IEEE80211] [IEEE80211]
"IEEE Standard for Information Technology — IEEE, "IEEE Standard for Information Technology--
Telecommunications and information exchange between Telecommunications and Information Exchange between
systems Local and metropolitan area networks — Specific Systems - Local and Metropolitan Area Networks--Specific
requirements — Part 11: Wireless LAN Medium Access Control requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications.", (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>. <https://ieeexplore.ieee.org/document/9363693>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
Acknowledgments
The authors are greatly indebted to Daniel Gröber, who first
identified the problem that this document aims to solve and first
suggested the solution described in Section 3.1.
Authors' Addresses Authors' Addresses
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Cité IRIF, University of Paris-Cité
Case 7014 Case 7014
75205 Paris CEDEX 13 75205 Paris CEDEX 13
France France
Email: jch@irif.fr Email: jch@irif.fr
Toke Høiland-Jørgensen Toke Høiland-Jørgensen
Red Hat Red Hat
Email: toke@toke.dk Email: toke@toke.dk
 End of changes. 56 change blocks. 
167 lines changed or deleted 204 lines changed or added

This html diff was produced by rfcdiff 1.48.