[secdir] Secdir last call review of draft-ietf-babel-mac-relaxed-04

[Christian Huitema via Datatracker <[e-mail]>]

Reviewer: Christian Huitema
Review result: Not Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I think that this document is not ready.

In order to relax the packet counter checks used to detect duplicate messages,
the draft recommends doing separate checks for packets received in unicast and
multicast mode. However, the two modes use the same packet counter. Attackers
can replay in multicast mode packets send in unicast mode, and bypass the
proposed check. The draft cannot progress until this attack is mitigated.

The security considerations of RFC 8967 do not mention the possible attacks by
a compromised node. The HMAC checks will not prevent such nodes from
compromising other nodes. The attacks are hard to mitigate, but the Babel WG
should consider at least detecting them. This issue is not directly related to
the current draft, but they could be: a draft revisiting authentication
mechanisms seems like a good place to discuss the issue.

The Babel routing protocol [RFC8966] operates by exchanging "Babel packets"
over UDP. The packet format is defined as:

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Magic     |    Version    |        Body length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Packet Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|         Packet Trailer...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Both packet body and packet trailers contain sequences of TLVs. The
authentication mechanisms defined in RFC 8967 protect the packet body, but not
the packet trailer.

The authentication mechanism specified in RFC 8967 works by appending one of
several MAC TLV to the packet trailer. Each MAC is is computed over a
concatenation of a pseudo header and the packet header and packet body,
according to the MAC algorithm and key specified in the authentication context.
Each node in the Babel-routed network is programmed with a set of encryption
contexts, and append a series of MAC TLV to the packet, one for each context.
On reception, nodes compute the possible MAC TLVs based on all their encryption
contexts, and accept the packet only if they find a match between one of the
MAC TLVs computed by the receiver and one of the MAC TLVs attached to the
packet.

Authentication does not protect against replay attacks. RFC 8967 mitigates that
by requiring that the packet body includes an indexed packet counter TLV (PC
TLV), which will continually increase until the node starts picking a new
index. Per RFC 8967, nodes only accept a packet if the PC TLV is carrying a new
index, or if the counter is higher than previous values received from that
node. If the receiver has no knowledge of the PC TLV currently used by a node,
it sends a challenge to that node to get an authoritative value. This mechanism
will cause nodes to ignore packets delivered out-of-order. This was not thought
to be a big issue when RFC 8967 was published, but it turns out that out of
order delivery is quite frequent in some wireless networks. That's the problem
addressed by draft-ietf-babel-mac-relaxed.

For the Relaxed Packet Counter Verification, receivers are asked to remember
some of the PC-TLV that they have previously received, so they can determine
whether the nonce was already seen or not. They will accept packets if they are
sure that the nonce is new, even if the strict order comparison fails. The
draft proposes two mechanisms to do that: remembering separately the highest PC
TLV received with unicast and multicast packets; and, remembering a "window" of
previously received PC TLV.

Separating multicast and unicast packet counters make sense, because multicast
transmission can be much slower than unicast. In some scenarios, the PC TLV
order check might cause all multicast packets to be ignored. The draft proposes
that neighbors retain both two counters: the highest PCs received in unicast
and multicast mode.

The unicast/multicast separation seems reasonable, except for an obvious
attack: what if an adversary captures a unicast packet with a PC TLV largest
than the highest multicast PC TLV, and then replays it as a multicast packet?
The attack might succeed in getting the original packet processed twice; it
will also cause the receiver to increase the recorded multicast PC TLV for the
source, which will cause all the multicast packets with lower PC value to be
ignored. The unicast/multicast separation will not be safe, unless this attack
is mitigated. A potential defense would be to require senders to mark which
packets are sent in unicast and which in multicast, maybe adding a new
"transmission mode" TLV to the body; receivers could then drop packets received
using an unexpected transport. There may be other mitigations, but the draft
cannot go forward recommending this unicast/multicast without explaining this
attack in the security section and mandating mitigations.

The 'window" mitigation works by remembering which of the last N packets before
the highest PC have been received. The draft suggests an implementation in
which the receiver keeps just one boolean per packet. There are probably other
possible implementations, and it might be better to separate intent and
implementation. The intent is clear: remember which of the last N packets have
been received and use that to prevent duplicate processing. That should be
stated using normative language. the implementation with a rotating vector of
boolean is just an example; different nodes with different processing
constraints could implement it differently. For example, I might use a vector
of "highest PC per slot", with each spot corresponding to the PC modulo N. In
any case the window algorithm is sound. If the unicast/multicast attacks are
not easy to mitigate, it might be expedient to only specify the windows
mechanism.

The security considerations of RFC 8967 do not mention the possible attacks by
a compromised node. Algorithms like HMAC-SHA256 or keyed BLAKES2 are symmetric.
If a node is somehow compromised, it can start impersonating any other node. It
is not hard to imagine how spoofed packets could disrupt the network, as
discussed in the security considerations of RFC 8966. The attack can persist
until it is detected and the network administrator restarts the network using
new credentials. If the working group wants to improve the mechanisms of RFC
8967, it might want to address at least the spoofing detection problem. For
example, if there was some kind of acknowledgement mechanism indicating the
last PC TLV received from a remote node, nodes that are being spoofed could
detect the attack.