[secdir] secdir review of draft-ietf-bier-tether
Wes Hardaker <wjhns1@hardakers.net> Thu, 29 February 2024 03:03 UTC
Return-Path: <wjhns1@hardakers.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998B4C14F5EB; Wed, 28 Feb 2024 19:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
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 uS0ARPDkQD2N; Wed, 28 Feb 2024 19:03:10 -0800 (PST)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABBFC151066; Wed, 28 Feb 2024 19:03:10 -0800 (PST)
Received: from localhost (unknown [50.226.84.130]) by mail.hardakers.net (Postfix) with ESMTPA id ABA4220DE8; Wed, 28 Feb 2024 19:03:09 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net ABA4220DE8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1709175789; bh=BFiSOFYC2ulxJbqNh3l/YLjd3SkgWcD9k3yGXRC8V4M=; h=From:To:Subject:Date:From; b=IU6757SmTnY9rU5Vb7jN18hAqudrGF8CEj+FKa3ki6+2vF7cPJc2FIwuEBUAYB8e3 4I29bCf+B/3y2E8sDNcCbhxlI0XygsUSDct39771AU51uHCOgmvMhKZPY7K4IaEpxp HUTYDBX99D7AgO0kdRCUi5tww8ny1NIKSDhcKyn4=
From: Wes Hardaker <wjhns1@hardakers.net>
To: draft-ietf-bier-tether.all@ietf.org, iesg@ietf.org, last-call@ietf.org, secdir@ietf.org
Date: Wed, 28 Feb 2024 19:03:09 -0800
Message-ID: <ybl7ciom0pe.fsf@wx.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_IeplQLsjpNxCmQnd4DYMtocB8g>
Subject: [secdir] secdir review of draft-ietf-bier-tether
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Feb 2024 03:03:15 -0000
Reviewer: Wes Hardaker Review result: Almost Ready I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-lsr-ospf-bfd-strict-mode-07 Reviewer: Wes Hardaker Review Date: 2024-02-22 IETF LC End Date: 2024-02-29 Summary: Almost Ready Major Concerns: Unreasonable security considerations Minor Concerns: Additional nits and comments Security considerations: Unfortunately just saying (paraphrased) "there are none beyond BIER and extensions" is unlikely to be as helpful as it could be. 1. you have not convinced me that it's true as you don't explain why the situation is identical. 2. I would like to see text describing what happens when the new extension is misused? I'm not an expert here (you are!) by my initial thoughts were you should explain that the best an attacker could do would be to multiple a packet across more links than intended, which actually may have a security issue since you're now sending packets down a link that they won't supposed to go down. The two cases I'd hope to see spelled out at a minimum are: can an attacker send traffic to a helper that shouldn't get it, and can an attacker prevent traffic getting to a helper that should get to it. The transport security should prevent this, but that should be stated IMHO. Nits and comments: - First, the extensive use of examples in this document are fantastic and greatly helps the reader understand the problem space and specific deployment scenarios. Thank you for including them. - The BFR and BRER labels could use expansion somewhere for the uninitiated. - I might have used a different acronym than "X" for discussing the BIER incapable router, but it works as is too. To be more descriptive I might have just BIR or something just to be explicit. - section 2 after Figure 3 in particular could use one more pass by a skilled author. I found a number of the sentences hard to follow or had strange wording elements in them ("loop won't happen" without an article, "To allow multiple helpers to help the same non_FR..."). - I would probably expand TLV too, though it is a well understood acronym generally. - section 3.1: I'd suggest "At step 2" -> "At step 2 in RFC8279 section 6.9" just to be explicitly clear. - section 3.1: "additional procedures are performed..." additional to what? Be explicit when you can. Reference exactly what you're extending to reduce mistakes in interpretations. - section 3.2: "There are three situations..." and then you list only 2. -- Wes Hardaker USC/ISI
- [secdir] secdir review of draft-ietf-bier-tether Wes Hardaker