Dear Prof. Huitema, Thank you for your review. I must, however, most respectfully disagree with your conclusions: the protocol is not vulnerable to the attacks that you describe. > 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. No, they cannot. If a packet originally sent to a unicast address is resent to a multicast address, this will be reflected in the pseudo-header (RFC 8967 Section 4.1). Since the pseudo-header participates in HMAC computation, this will cause the HMAC test to fail (RFC 8967 Section 4.3, first bullet point). As you rightly inferred, it would not be correct to generalise our approach to discriminating over a packet that is not covered by the HMAC. This is discussed in detail in Section 3.1.1. (Note also that the protocol discriminates on the destination address, which is included in the pseudo-header, not on the link-layer framing. I believe that we've made that clear, see for example Section 3.1, which says "if the packet was sent to a multicast address".) > The security considerations of RFC 8967 do not mention the possible attacks by > a compromised node. Please see the first paragraph of the security considerations, which discusses the limitations of the protocol, and recommends the use of Babel over DTLS in circumstances where these limitations are not acceptable. > This issue is not directly related to the current draft, Agreed. > 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? As mentioned above, in order for the receiver to treat the packet as a multicast packet, the destination address must be changed. Since the destination address is included in the pseudo-header, this will cause the HMAC check to fail. This is discussed in detail in Section 3.1.1. > 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. No, it will not. The HMAC check is performed as the very first step of the verification procedure, and the replayed packet will be dropped before any further processing. > 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. Perhaps. However, the data structures described are conceptual, and any algorithm that provides the same result is allowed. > The security considerations of RFC 8967 do not mention the possible attacks by > a compromised node. As mentioned above, please see the first paragraph of the Security Considerations, which clearly states the limitations of the algorithm and recommends the use of Babel over DTLS in circumstances where these limitations are not acceptable. With respectful regards, -- Juliusz Chroboczek -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
