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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
