[bess] Secdir last call review of draft-ietf-bess-evpn-mh-split-horizon-09

Yaron Sheffer via Datatracker <noreply@ietf.org> Sun, 30 June 2024 16:17 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from [10.244.2.3] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id A9FDFC14F5F1; Sun, 30 Jun 2024 09:17:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yaron Sheffer via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.17.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171976427129.304681.11374299341736937769@dt-datatracker-5f88556585-g8gwj>
Date: Sun, 30 Jun 2024 09:17:51 -0700
Message-ID-Hash: G2ISQHB2GHOMAXIBXGU5R4CJUPVRFTIF
X-Message-ID-Hash: G2ISQHB2GHOMAXIBXGU5R4CJUPVRFTIF
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: bess@ietf.org, draft-ietf-bess-evpn-mh-split-horizon.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Yaron Sheffer <yaronf.ietf@gmail.com>
Subject: [bess] Secdir last call review of draft-ietf-bess-evpn-mh-split-horizon-09
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/tNU96fMCe-utVRbj64UnA1w2RTc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>

Reviewer: Yaron Sheffer
Review result: Has Nits

This document defines a way to explicitly share the multi-homing split horizon
procedures over BGP, for a large variety of NVO use cases. This reviewer is not
familiar with the EVPN ecosystem, and comments below may reflect my own
ignorance.

In general: the document is clear, and does not appear to create any novel
security risks.

2.1: the first two paragraphs are duplicates.

2.2: "A received A-D per ES route where Single-Active and SHT bits are
different from zero MUST be treat-as-withdraw" - IIUC, this is very fragile
behavior, where an incorrect flag results in the entire path being removed. Why
does this behavior make more sense than simply ignoring the SHT bits?

2.2: For the Geneve use case: is the value "10" always valid, or is it only
valid if the ESI-Label is present? The text is unclear.

4: "The security considerations relevant to multihoming" - is it clear to all
readers which security considerations these are? Are you referring to the
entirety of Sec. 19 of RFC7432?

4: "unauthorized changes to the SHT configuration by an attacker should not
cause traffic disruption" - when various kinds of misconfiguration are "treat
as withdraw", how does that NOT cause traffic disruption? I would assume that
when the route is withdrawn, eventually traffic is disrupted.

7: the Contributors section is empty.