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

[Reshad Rahman <[e-mail]>]

 Roman, thank you for the review.
    On Wednesday, December 14, 2022, 12:00:39 PM EST, Roman Danyliw via Datatracker <[e-mail]> wrote:  
 
 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.

<RR> Added reference to RFC5082.
** 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?
<RR> Quotes have been removed.
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.”
<RR> That text has been removed from section 2 after considering other feedback.
-- “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.
<RR> BFD auth considerations in (new) section 7.2.

----------------------------------------------------------------------
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.”
<RR> Removed reference to SHA1 as per other feedback. Please see text in 7.2 in rev-13.
** 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
<RR> Added.
Regards,Reshad.