Lars Eggert 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: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-bfd-unsolicited-11 CC @larseggert Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/2NcfuVBkWLD_CcQyTciwKOz2Xac). ## Discuss ### Section 7.1, paragraph 3 ``` The same security considerations and protection measures as those described in [RFC5880] and [RFC5881] apply to this document. In addition, with "unsolicited BFD" there is potential risk for excessive resource usage by BFD from "unexpected" remote systems. To mitigate such risks, the following measures are mandatory: * Limit the feature to specific interfaces, and to single-hop BFD with "TTL=255" [RFC5082]. * Apply "policy" to allow BFD packets only from certain subnets or hosts. * Deploy the feature only in certain "trustworthy" environment, e.g., at an IXP, or between a provider and its customers. * Use BFD authentication, see [RFC5880]. In some environments, e.g. when using an IXP, BFD authentication can not be used because of the lack of coordination into the operation of the two endpoints of the BFD session. In other environments, e.g. when BFD is used to track the next hop of static routes, it is possible to use BFD authentication: this comes with the extra cost of configuring matching key-chains at the two endpoints. If BFD authentication is used, the Meticulous Keyed SHA1 mechanism SHOULD be used. ``` BFD can be configured to send large volumes of traffic, and it sends it without congestion control. When a past IESG approved BFD for standardization in that form, it was exactly because both endpoints needed to be configured, which significantly reduces the possibility/impact of unilateral misconfiguration. I don't believe the suggestions above provide nearly the same level of protection. Also, if (all of?) these are mandatory, that needs to be made very clear, i.e., using RFC2119 terms here and elsewhere in the document (where it currently says these mechanisms are recommended...) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Boilerplate Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License". ### Grammar/style #### Section 1, paragraph 6 ``` to the widely deployed BFD itself. Thus we believe that this proposal is in ^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Thus". #### Section 4.2, paragraph 23 ``` xtra cost of configuring matching key-chains at the two endpoints. If BFD aut ^^^^^^^^^^ ``` This word is normally spelled as one. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
