Ballot for draft-ietf-bfd-unsolicited
Discuss
Yes
No Objection
No Record
Summary: Has 5 DISCUSSes. Needs 6 more YES or NO OBJECTION positions to pass.
This document attempts to do two things: specify "unsolicited BFD" and define a YANG model for its management. I am happy to include both in the same document, but the specification of the protocol mechanisms falls short and results in a document that lacks clarity. While YANG is the preferred management mechanism, it should be possible to implement and manage the feature without the model. Most of my concerns are from Section 2 (line numbers from idnits): 154 Passive unsolicited BFD support MUST be disabled by default, and MUST 155 require explicit configuration to be enabled. On the passive side, 156 the desired BFD parameters SHOULD be configurable. The passive side 157 MAY also choose to use the parameters that the active side uses in 158 its BFD Control packets. The "My Discriminator", however, MUST be 159 chosen to allow multiple unsolicited BFD sessions. (A) "the desired BFD parameters SHOULD be configurable" Which parameters are those? The YANG model uses bfd-types:base-cfg-parms, which only includes a basic set. The point here is that this document's specification part is incomplete because it doesn't specify which parameters "SHOULD be configurable". (B) The YANG model offers global and per-interface configuration options. The specification doesn't discuss hierarchical configuration or whether one type should take precedence over the other. [Related to Rob's DISCUSS.] This point was discussed on the mailing list, where it was pointed out that per-interface configuration should override global configuration [1], but that discussion is not reflected in the document. [1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/GI_eNtxcEeh2_vTl9zfq7K6V1X4 171 When the passive side receives an incoming BFD Control packet on a 172 numbered interfaces, the source address of that packet MUST belong to 173 the subnet of the interface on which the BFD packet is received. The 174 source address of the BFD Control packet SHOULD be validated against 175 expected routing protocol peer addresses on that interface. (C) "SHOULD be validated" What does validating the source address "against expected routing protocol peer addresses on that interface" entail? Is it just a comparison? Please be explicit on what the normative behavior should be. When is it ok to not validate? Why is this behavior recommended and not required? If the validation is performed, is there an expected action if the source address does not correspond to an "expected routing protocol peer addresses on that interface"? Where does this "expected" list come from? On a LAN, it seems like any address would be valid since a router doesn't know the list of IGP neighbors beforehand. 177 The passive side MUST then start sending BFD Control packets and 178 perform the necessary procedure for bringing up, maintaining and 179 tearing down the BFD session. If the BFD session fails to get 180 established within certain specified time, or if an established BFD 181 session goes down, the passive side SHOULD stop sending BFD Control 182 packets and MAY delete the BFD session created until BFD Control 183 packets are initiated by the active side again. (D) "If the BFD session fails to get established within certain specified time..." [nit] s/within certain specified time/within a certain specified time Where does a "certain specified time" come from? Is it configurable? Does it correspond to any of the state variables in rfc5880? (E) "SHOULD stop sending BFD Control packets" When is it ok not to stop sending BFD control packets? Why would the node continue sending packets if the session is not established (or goes down)? Why is this behavior recommended and not required? 185 When an Unsolicited BFD session goes down, an implementation MAY 186 retain the session state for a period of time. Retaining this state 187 can be useful for operational purposes. (F) Not exactly a contradiction, but confusing normative statements (between this paragraph and the one before): "MAY delete" vs "MAY retain" for the same event ("BFD session goes down").
(0) I support Rob's and Lars' DISCUSS positions. (1) The Introduction makes several claims that must be developed further or eliminated to avoid further confusion. (1a) 131 The procedure described in this document could be applied to BFD for 132 Multihop paths [RFC5883]. However, because of security risks, this 133 document applies only to BFD for single IP hops [RFC5881]. At first glance, I didn't see anything in rfc5883 that would prevent a node in the passive role from following this specification. What am I missing? Aren't the security risks already addressed in rfc5883? (1b) 135 Compared to the "Seamless BFD" [RFC7880], this proposal involves only 136 minor procedural enhancements to the widely deployed BFD itself. 137 Thus we believe that this proposal is inherently simpler in the 138 protocol itself and deployment. As an example, it does not require 139 the exchange of BFD discriminators over an out-of-band channel before 140 BFD session bring-up. Given that this proposal claims to be better (or at least simpler) than S-BFD, what should an operator consider when deciding which to use? Are they covering similar use cases? If this is so much better, why is rfc7880 not deprecated? (1c) 142 When BGP Add-Path [RFC7911] is deployed at an IXP using a Route 143 Server, multiple BGP paths (when they exist) can be made available to 144 the clients of the Route Server as described in [RFC7947]. The 145 "unsolicited BFD" can be used in BGP route selection by these clients 146 to eliminate paths with "inaccessible nexthops". I guess that this part ("inaccessible nexthops") refers to "unresolvable routes" (from §9.1.2.1/rfc4271). Is that the correct assumption? First, please be consistent with the terminology. The text above says that ""unsolicited BFD" can be used in BGP route selection". Where is the interaction of BFD (in general -- not just unsolicited BFD) and BGP specified? (2) I am confused by the indication that this document Updates rfc9314 because no change is proposed to that RFC. Instead, the YANG model augments the model in rfc9314 with optional (to the base BFD) functionality. In my opinion, this is different than a formal Update, which is why rfc5880/rfc5881 are not tagged as being Updated either. [Because the use of the Updates tag is not clearly defined, then I'm not making this comment part of my DISCUSS.] (3) The "BFD Protocol Security Considerations" (Section 7.1) also needs work: 458 The same security considerations and protection measures as those 459 described in [RFC5880] and [RFC5881] apply to this document. In 460 addition, with "unsolicited BFD" there is potential risk for 461 excessive resource usage by BFD from "unexpected" remote systems. To 462 mitigate such risks, the following measures are mandatory: [minor] For clarity, consider using rfc2119 language above: s/mandatory/REQUIRED Note that the last two bullets are conditional statements, which may not be aligned with the intent of making the measures mandatory. 464 * Limit the feature to specific interfaces, and to single-hop BFD 465 with "TTL=255" [RFC5082]. GTSM is already required in rfc5880/rfc5881. Does it need to be required again? 466 * Apply "policy" to allow BFD packets only from certain subnets or 467 hosts. [nit] s/allow BFD packets/process BFD packets Given the statement in the Introduction about this document applying only to single IP hops, it seems that "certain subnets" are unnecessary as all the addresses on connected interfaces should fall on the same subnet. 468 * Deploy the feature only in certain "trustworthy" environment, 469 e.g., at an IXP, or between a provider and its customers. If this measure is mandatory, please expand on what a ""trustworthy" environment" is. 470 * Use BFD authentication, see [RFC5880]. In some environments, e.g. 471 when using an IXP, BFD authentication can not be used because of 472 the lack of coordination into the operation of the two endpoints 473 of the BFD session. In other environments, e.g. when BFD is used 474 to track the next hop of static routes, it is possible to use BFD 475 authentication: this comes with the extra cost of configuring 476 matching key-chains at the two endpoints. If BFD authentication 477 is used, the Meticulous Keyed SHA1 mechanism SHOULD be used.
# 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...)
## 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
Hi, Thanks for this document. Please see my comments below for more details, but I'm balloting discuss on 3 points: (1) The document is somewhat unclear as to whether the configuration is applied hierarchically (I presume that it is, if not then my second discuss point is not valid and can be ignored). (2) As specified, I don't think that the hierarchical configuration will work, because the interface level leaf "defaults" will override an explicit value configured globally. I.e., logically, the interface level leaf, if in scope, will always have a value. (3) The document should provide an instance-data example in the appendix to illustrate the use of this configuration. Regards, Rob
Moderate level comments:
(1) p 3, sec 2. Procedures for Unsolicited BFD
When the passive side receives a BFD Control packet from the active
side with 0 as "Your Discriminator" and does not find an existing BFD
session, the passive side MAY create a matching BFD session toward
the active side, if permitted by local configuration and policy.
I'm surprised that this is only a MAY and not a SHOULD or MUST. I.e., if the local configuration & policy allows passive BFD sessions why would they not be created?
(2) p 4, sec 4.1. Unsolicited BFD Hierarchy
* Globally, i.e. for all interfaces. This requires support for the
"unsolicited-params-global" feature.
* For specific interfaces. This requires support for the
"unsolicited-params-per-interface" feature.
From this description, it is unclear to me whether the features enabling global or per-interface configuration are meant to be an either/or (in which case, the constraint could probably be expressed in the features), or whether a server is allowed to support configuration both globally and override the global configuration with interface specific configuration. My subsequent discuss comments assume the latter. Either way, it would be helpful for this text in this section (and probably the YANG module) to be a bit more explicit on this regard.
(3) p 8, sec 4.2. Unsolicited BFD Module
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:interfaces" {
if-feature bfd-unsol:unsolicited-params-per-interface;
description
"Augmentation for BFD unsolicited on IP single-hop interface";
container unsolicited {
description
"BFD IP single-hop interface unsolicited top level
container";
leaf enabled {
type boolean;
default false;
I'm not sure that you want a default value specified in the YANG here since this would have precedence over any explicitly configured global default value.
(4) p 8, sec 4.2. Unsolicited BFD Module
description
"BFD unsolicited enabled on this interface.";
}
uses bfd-types:base-cfg-parms;
You have the same issue here as above, in that the default values directly associated with the leaves in this grouping will always take precedence over any configured global value. I.e., the configuration, if properly implemented cannot be hierarchical. The pragmatic solution is to copy the used grouping inline here and delete the default statements. This has the advantage that the descriptions can also make the hierarchical behavior of the configuration explicit.
(5) p 9, sec 4.2. Unsolicited BFD Module
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:sessions/bfd-ip-sh:session" {
description
"Augmentation for BFD unsolicited on IP single-hop session";
leaf role {
type bfd-unsol:role;
config false;
description
"Role of local system during BFD session initialization.";
}
}
}
<CODE ENDS>
Please add an instance data example to an appendix to illustrate the use of this YANG model. This helps readers and can further emphasize the hierarchical nature of the configuration.
Minor level comments:
(6) p 3, sec 2. Procedures for Unsolicited BFD
Passive unsolicited BFD support MUST be disabled by default, and MUST
require explicit configuration to be enabled. On the passive side,
the desired BFD parameters SHOULD be configurable. The passive side
MAY also choose to use the parameters that the active side uses in
its BFD Control packets. The "My Discriminator", however, MUST be
chosen to allow multiple unsolicited BFD sessions.
Rather then configured values on the passive side, did the authors consider setting minimum configuration limits? E.g., rather than define desired send/receive limits, instead, configure lower bounds on what the minimum tx interval may be (to prevent DDOS attacks).
Nit level comments:
(7) p 3, sec 2. Procedures for Unsolicited BFD
The passive side MUST then start sending BFD Control packets and
perform the necessary procedure for bringing up, maintaining and
tearing down the BFD session. If the BFD session fails to get
established within certain specified time, or if an established BFD
session goes down, the passive side SHOULD stop sending BFD Control
packets and MAY delete the BFD session created until BFD Control
packets are initiated by the active side again.
Nit, within certain specified => within a specified
(8) p 6, sec 4.2. Unsolicited BFD Module
Copyright (c) 2021 IETF Trust and the persons
identified as authors of the code. All rights reserved.
This copyright statement will need to be fixed.
** 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.
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
Thanks for working on this specification. Thanks to Magnus Westerlund for the TSVART review, based on that review and my own read, I am supporting both Lars's and Roman's discuss. On top of that, as this document claims - "with "unsolicited BFD" there is potential risk for excessive resource usage by BFD from "unexpected" remote systems". This translates to me as potential injection of huge amount of traffic which is lacking a self-regulation mechanism in this specification. To large degrees the traffic volume could have random effects on the routing plane and what links are considered up etc. We can hide all these by saying "Deploy the feature only in certain "trustworthy" environment"", then I am completely missing the definition of "trustworthy" environment". I would like to discuss that.
Additional comments - * This document also says - "When an Unsolicited BFD session goes down, an implementation MAY retain the session state for a period of time. Retaining this state can be useful for operational purposes." I am missing any discussion on the reduced functionality or any indication if the selected period time has any advantages or disadvantages. To be honest, without proper discussion or indication of some default values, I would remove the entire sentence or if this is just an additional implementation advice, I would drop the normative MAY.
# Internet AD comments for draft-ietf-bfd-unsolicited-11 CC @ekline ## Nits ### S2 * "on a numbered interfaces" -> "on a numbered interface" perhaps?
For Section 5, it is common (but not mandatory) to put each IANA action in its own subsection. The SHOULD at the top of Section 2 is peculiar. It indicates you would only make this non-configurable in an implementation in some unusual circumstances. What's an example?