Re: [babel] Secdir last call review of draft-ietf-babel-mac-relaxed-04
Juliusz Chroboczek <jch@irif.fr> Sun, 09 April 2023 11:51 UTC
Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC63FC15C2B6; Sun, 9 Apr 2023 04:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=irif.fr
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TT98vCLssJt; Sun, 9 Apr 2023 04:51:36 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A3BC15C2B5; Sun, 9 Apr 2023 04:51:29 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 339BpM9x030105; Sun, 9 Apr 2023 13:51:22 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DC69A4866B; Sun, 9 Apr 2023 13:51:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-type:content-type:mime-version:user-agent:references :in-reply-to:subject:subject:from:from:message-id:date:date :received:received; s=dkim-irif; t=1681041079; x=1681905080; bh= b7vkxEdkGBl6NHHDNphE+U71ZTHSwOPk9XKh/+Rn0G0=; b=bFq0Ew0mDVDryena Gm+todL6Bx6xV664ZZL1NdMsaNCLwBTrJT8ywh1SOdk17BFulp3pZS8zZvLwX6U9 tKNZd+EV2vn7ZrVFZimU0S8Z/EEK0Tw/cbk6HwcLrV2HhzMeK7xivU1DXg9OJrk5 k1UPjg9WP3mULKyR4qb7b3yI93jDkO0i/B533bp9DYLRyvrnXB7FsatgKUoBv5oQ HLt7yclylIUNW4M2nrh+1t6Du8F6r7glAAF47wc8v3smzWrINSNznQccKxmCX6fj jVraWWkJR961uHlWHgWoN47DV8A+bnNhiOfR9Nx20RZGtdNsZ5iZ4KwsYu0YpQrt eQ++dg==
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id isvHeKsYaqej; Sun, 9 Apr 2023 13:51:19 +0200 (CEST)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 567614874E; Sun, 9 Apr 2023 13:51:17 +0200 (CEST)
Date: Sun, 09 Apr 2023 13:51:17 +0200
Message-ID: <87ttxpw9xm.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Christian Huitema <huitema@huitema.net>
Cc: secdir@ietf.org, babel@ietf.org, draft-ietf-babel-mac-relaxed.all@ietf.org, last-call@ietf.org
In-Reply-To: <168099657635.12409.14929217899829415993@ietfa.amsl.com>
References: <168099657635.12409.14929217899829415993@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 09 Apr 2023 13:51:22 +0200 (CEST)
X-Miltered: at korolev with ID 6432A6BA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 6432A6BA.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 6432A6BA.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/4PW5porovusjimS0NkMzGiCrHAQ>
Subject: Re: [babel] Secdir last call review of draft-ietf-babel-mac-relaxed-04
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Apr 2023 11:51:40 -0000
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
- [babel] Secdir last call review of draft-ietf-bab… Christian Huitema via Datatracker
- Re: [babel] Secdir last call review of draft-ietf… Juliusz Chroboczek
- Re: [babel] [Last-Call] Secdir last call review o… Christian Huitema
- Re: [babel] [Last-Call] Secdir last call review o… Juliusz Chroboczek