Roman Danyliw's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 14 December 2022 17:00 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-bfd@ietf.org
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C94C14F725; Wed, 14 Dec 2022 09:00:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bfd-unsolicited@ietf.org, bfd-chairs@ietf.org, rtg-bfd@ietf.org, Jeffrey Haas <jhaas@pfrc.org>, jhaas@pfrc.org
Subject: Roman Danyliw's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 9.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <167103723541.48477.2301299940281758486@ietfa.amsl.com>
Date: Wed, 14 Dec 2022 09:00:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/bUz7LitpO0ybaeDRXEJ72EAqNpI>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2022 17:00:35 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-bfd-unsolicited-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 7.1

Limit the feature to specific interfaces, and to single-hop BFD
      with "TTL=255" [RFC5082].

Section 2.2 of RFC5082 says “set the TTL on the protocol packets to 255 (the
maximum possible for IP) and then reject any protocol packets that come in from
configured peers that do NOT have an inbound TTL of 255”. Guidance on dropping
the packets based on TTL in RFC5082 appears to be missing here.

** Section 7.1.  The following considerations are inconsistent:

-- “To mitigate such risks, the following measures are mandatory: … Apply
"policy" to allow BFD packets only from certain subnets or hosts.”

Editorially (not discuss but related), why is policy in quotes?

Requiring this check conflicts with the less rigorous SHOULD in Section 2: “The
source address of the BFD Control packet SHOULD be validated against expected
routing protocol peer addresses on that interface.”

-- “To mitigate such risks, the following measures are mandatory: … Use BFD
authentication, see [RFC5880].  In some environments, e.g. when using an IXP,
BFD authentication can not be used … If BFD authentication is used, the
Meticulous Keyed SHA1 mechanism SHOULD be used.”

The text first says using BFD authentication is mandatory, but then says it is
not possible in certain environments.  Later is states that “if BFD is used”,
but the text already said it was mandatory.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Derek Atkins for the SECDIR review.

** Section 7.1  Meticulous Keyed SHA1 is a stated as a SHOULD.  Is this
intended to express a preference over MD5?  If so, perhaps this needs to be
restated that “SHA1 MUST be used if it is supported.”

** Section 7.2

*  data nodes local-multiplier, desired-min-tx-interval, required-
      min-rx-interval and min-interval all impact the parameters of the
      unsolicited BFD IP single-hop sessions.

Please explicitly state the impact of write options on these parameters