Internet DRAFT - draft-chroboczek-babel-mac-relaxed
draft-chroboczek-babel-mac-relaxed
Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris-Cité
Updates: 8967 (if approved) 12 May 2022
Intended status: Standards Track
Expires: 13 November 2022
Relaxed Packet Counter Verification for Babel MAC Authentication
draft-chroboczek-babel-mac-relaxed-00
Abstract
This document relaxes packet verification rules defined in the Babel
MAC Authentication protocol in order to make it more robust in the
presence of packet reordering.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 November 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Chroboczek Expires 13 November 2022 [Page 1]
Internet-Draft Babel-MAC Relaxed PC May 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 2
3. Relaxing PC validation . . . . . . . . . . . . . . . . . . . 3
3.1. Multiple last PC values . . . . . . . . . . . . . . . . . 3
3.1.1. Generalisations . . . . . . . . . . . . . . . . . . . 4
3.2. Window-based validation . . . . . . . . . . . . . . . . . 5
3.3. Combining the two techniques . . . . . . . . . . . . . . 5
4. Security considerations . . . . . . . . . . . . . . . . . . . 5
5. Normative references . . . . . . . . . . . . . . . . . . . . 5
6. Informative references . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The design of the Babel MAC authentication mechanism [RFC8967]
assumes that packet reordering is an exceptional occurrence, and the
protocol drops any packets that arrive out-of-order. This assumption
is generally correct on wired links, but turns out to be incorrect on
some kinds of wireless links.
In particular, IEEE 802.11 (WiFi) defines a number of power-saving
modes that allow stations (mobile nodes) to switch their radio off
for extended periods of time, ranging in the hundreds of
milliseconds. The access point (network switch) buffers all
multicast packets, and only sends them out after the power-saving
interval ends. The result is that multicast packets are delayed by
up to a few hundred milliseconds with respect to unicast packets,
which, under some traffic patterns, causes the PC verification
procedure in RFC 8967 to systematically fail for multicast packets.
This document defines two ways to relax the PC validation: using two
separate receiver-side states, one for unicast and one for multicast
packets (Section 3.1), and using a window of previously received PC
values (Section 3.2). Usage of the former is RECOMMENDED, while
usage of the latter is OPTIONAL. The two MAY be used simultaneously
(Section 3.3). This document updates RFC 8967.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Chroboczek Expires 13 November 2022 [Page 2]
Internet-Draft Babel-MAC Relaxed PC May 2022
3. Relaxing PC validation
The Babel MAC authentication mechanism prevents replay by decorating
every sent packet with a strictly increasing value, the Packet
Counter (PC). Notwithstanding the name, the PC does not actually
count packets: it is permitted for a sender to increment the PC by
more than one between two packets.
A receiver maintains the last PC received from each neighbour. When
a new packet is received, the receiver compares the PC contained in
the packet with the last received PC; if the new value is smaller or
equal, the packet is discarded; otherwise, the packet is accepted,
and the last PC value for that neighbour is updated.
Note that there does not exist a one-to-one correspondence between
sender states and receiver states: multiple receiver states track a
single sender state. The receiver states corresponding to single
sender state are not necessarily identical, since only a subset of
receiver states are updated when a packet is sent to a unicast
address or when a multicast packet is received by a subset of the
receivers.
3.1. Multiple last PC values
Instead of a single last PC value maintained for each neighbour, an
implementation of the procedure described in this section uses two
values, the last unicast PC and the last multicast PC. More
precisely, the (Index, PC) pair contained in the Neighbour
Table (Section 3.2 of [RFC8967]) is replaced by:
* a triple (Index, PCm, PCu), where Index is an arbitrary string of
0 to 32 octets, and PCm and PCu are 32-bit (4-octet) integers.
When a challenge reply is successful, both last PC values are updated
to the value contained in PC TLV from the packet containing the
successful challenge. More precisely, the last sentence of the
fourth bullet point of Section 4.3 of [RFC8967] is replaced by:
* If the packet contains a successful Challenge Reply, then the
Index contained in the PC TLV MUST be stored in the Index field of
the Neighbour Table entry corresponding to the sender packet is
accepted, and the PC contained in the TLV MUST be stored in both
the PCm and PCu fields of the Neighbour Table entry.
When a packet that does not contain a successful challenge reply is
received, then the PC value it contains is compared to either the PCm
or the PCu field of the corresponding neighbour entry, depending on
whether the packet was sent to a unicast or a multicast address. If
Chroboczek Expires 13 November 2022 [Page 3]
Internet-Draft Babel-MAC Relaxed PC May 2022
the comparison is successful, then the same value (PCm or PCu) is
updated. More precisely, the last bullet point of Section 4.3 of
[RFC8967] is replaced by:
* At this stage, the packet contains no successful challenge reply
and the Index contained in the PC TLV is equal to the Index in the
Neighbour Table entry corresponding to the sender. The receiver
compares the received PC with either PCm field (if the packet was
sent to a multicast address) or the PCu field (otherwise) in the
Neighbour Table; if the received PC is smaller or equal than the
value contained in the Neighbour Table, the packet MUST be dropped
and processing stops (no challenge is sent in this case, since the
mismatch might be caused by harmless packet reordering on the
link). Otherwise, the PCm (if the packet was sent to a multicast
address) or the PCu (otherwise) field contained in the Neighbour
Table entry is set to the received PC, and the packet is accepted.
3.1.1. Generalisations
Modern networking hardware tends to maintain more than just two
queues, and it might be tempting to generalise the approach taken to
more than just two last PC values. For example, one might be tempted
to use distinct last PC values for packets received with different
values of the Type of Service (ToS) field, or with different IEEE
802.11e access categories. However, chosing a last PC field by
consulting a value that is not protected by the MAC (Section 4.1 of
[RFC8967]) would no longer protect against replay. In practice, this
means that only the destination address and port number and data
stored in the packet body may be used for choosing the last PC value,
since these are the only fields that are protected by the MAC (in
addition to the source address and porte number, which are already
used when choosing the Neighbour Table entry and therefore provide no
additional information).
The following example shows why it would be unsafe to select the last
PC depending on the ToS field. Suppose that a node B were to
maintain distinct last PC values for different values T1 and T2 of
the ToS field, and that initially all of the last PC fields at B have
value 42. Suppose now that a node A sends a packet P1 with ToS equal
to T1 and PC equal to 43; when B receives the packet, it sets the
last PC value associated with ToS T1 to 43. If an attacker were now
to send an exact copy of P1 but with ToS equal to T2, B would consult
the last PC value associated with T2, which is still equal to 42, and
accept the replayed packet.
Chroboczek Expires 13 November 2022 [Page 4]
Internet-Draft Babel-MAC Relaxed PC May 2022
3.2. Window-based validation
Use a window in the style of Section 3.4.3 of [RFC4303].
3.3. Combining the two techniques
The two techniques defined above serve complementar purposes:
splitting the state allows multicast packets to be reordered with
respect to unicast ones by an arbitrary number of PC values, while
the window-based technique allows arbitrary packets to be reordered
but only by a bounded number of PC values. Thus, they can profitably
be combined.
An implementation of both techniques MUST maintain, for every entry
of the Neighbour table, two distinct windows, one for multicast and
one for unicast packets. When a successful challenge reply is
received, both windows MUST be reset. When a packet that does not
contain a challenge reply is received, then if the packet's
destination address is a multicast address, the multicast window MUST
be consulted and possibly updated, as described in Section 3.2;
otherwise, the unicast window MUST be consluted and possibly updated.
4. Security considerations
If implemented correctly, the procedures described in this document
do not change the security properties described in Section 1.2 of RFC
8967. While they do slightly increase the amount of per-neighbour
state maintained by each node, this increase is marginal (between 4
and 32 octets, depending on implementation choices), and should not
significantly impact the ability of nodes to survive denial-of-
service attacks.
5. Normative references
[RFC8967] Dô, C., Kolodziejak, W., and J. Chroboczek, "MAC
Authentication for the Babel Routing Protocol", RFC 8967,
DOI 10.17487/RFC8967, January 2021,
<https://www.rfc-editor.org/info/rfc8967>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Chroboczek Expires 13 November 2022 [Page 5]
Internet-Draft Babel-MAC Relaxed PC May 2022
6. Informative references
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
Author's Address
Juliusz Chroboczek
IRIF, University of Paris-Cité
Case 7014
75205 Paris CEDEX 13
France
Email: jch@irif.fr
Chroboczek Expires 13 November 2022 [Page 6]
