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 ready, maybe with some nits. 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. In a previous review, I wrongly asserted that attackers could replay in multicast mode packets send in unicast mode, and bypass the proposed check. This is incorrect. The pseudo-header included in the HMAC computations includes the IP destination, which would be different for unicast and multicast packets. But it would be nice if that reasoning was written down in the draft. The security considerations of RFC 8967 do not mention the possible attacks by a compromised node -- they merely state that the proposed method only support symmetric algorithms, leaving the reader to infer possible consequences. I think it would be better to spell out the consequences, that compromise of any node could lead to hard-to-detect attacks on the whole network. If this is not an acceptable level of security, RFC 8967 suggests deploying the more robust protections based on DTLS, as specified in RFC 8968. But since this draft aims at improving RFC 8967, I wish that they first spell out the failure scenario, and possibly add suggestions for detecting compromise. 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 appends 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, but the previous review asked: 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? It turns out that this attack is not possible, because unicast and multicast packets can be reliably distinguished by examining the destination IP address, which is copied in the pseudo-header included in the computation of the MAC TLV. It would be very nice to add this remark in the draft, maybe in the security considerations, if only to avoid confusion by reviewers and implementers. The 'window" mitigation works by remembering which of the last N packets before the highest received 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. The security considerations of RFC 8967 do not explicitly mention the possible attacks by a compromised node. They merely state that "the scope of this protocol is limited" and that "it only supports symmetric keying", assuming that future readers will understand the implications. I think that it would be better to actually spell out these attacks, so network administrators can make informed choices between the methods of RFC 8967 and the more secure DTLS based methods of RFC 8968. The attacks through compromised node or compromised credential can persist until they are 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 detection problem. For example, if there was some kind of acknowledgement or echo mechanism indicating the last PC TLV received from a remote node, nodes that are being spoofed could probably detect the attack.