Hi Magnus, Thanks for the review and comments. We will update the draft soon to address some of them. Please see some replies inline with <NS> and </NS>. > 1) Section 7.1 > The formulations around the mitigations are poorly worded. > a) First the lead in to the bullet list states that this is mandatory but it > fails to use and RFC 2119/8174 words. <NS> Will add a “Requirements” section to reference RFC 2119. </NS> > b) "Limit the feature to specific > interfaces, and to single-hop BFD with "TTL=255" > [RFC5082]." I would think that this sentence would rather state that one > MUST use the RFC 5082 security mechanism for the BFD traffic. What is > unclear to me from not having read RFC 5082 in detail is if this mechanism > works well for this traffic or gets additional traffic into problems due > to scoping which appear to be interface wide. Thus, are further > clarifications on usage needed? <NS> This sentence is just to state one of the key requirements of the ‘unsolicited-bfd’ that: - to enable the feature for specific interfaces of a device - only valid for single-hop BFD - to use the TTL=255 check describe in RFC-5082 Those are the key operational and protocol requirements due to the security consideration. Not much further clarification we can add on. </NS> > c) "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." > This mitigation usage is deployment dependent, thus better care in formulation > related to this is needed. This appears to be a MUST unless in this particular > situation and should be clearer. Also the actual support required for interop > appears a bit weak without having looked into RFC 5880 in detail. But only a > SHOULD support algorithm? <NS> Because ‘unsolicited-bfd’, like normal BFD, can be used in various environments, some in more secure and internal, others at less secure locations. Different types of authentication can be used and different security algorithm types can be used by network operators. This draft does not want to specify in general which algorithm must be used. It only points out in certain conditions, a more secure algorithm should be used. </NS> > > 2) Not being an expert in BFD and its control parts it appears that there are > no mechanism for terminating an ongoing BFD session as the passive player in > case of any overload. It is even unclear if there are any other mechanism than > refusing to respond to a new session for the passive entity when getting > unsolicitied BFD. So it would be good if the document could be more explicit if > there are any action the passive entity can do if ending up with to many BFD > sessions? I understand the goal here is to limit the number of potential peers > as well as ensuring that they are trusted entities even before any packets are > sent, but are there really no method to stop the session? <NS> Since it’s a ‘passive’ and no configuration is needed for this ‘unsolicited-bfd’ mechanism, it does not have an explicit way of terminating a particular ongoing session from protocol point of view. An analogy would be if a website does not use mTLS mechanism, only uses TLS, the protocol will not have an explicit way to terminate a HTTPs session. But if the device is overloaded due to the number of ‘unsolicited-bfd’ sessions on an interface, the operators can ‘Apply “policy” to allow BFD packets only from certain subnets or hosts’ (stated also in the Security Consideration section). For instance, if 10.1.0.0/16 ACL is too broad in this case, the operators can replay 10.1.5.0/24 to limit the source IP address further, or even 10.1.5.64/26, etc. This should enable them to reset the current sessions, and reduce the total ‘unsolicited-bfd’ sessions to the desired number if needed. </NS> > > 3) Section 7.2: > So this section lays out the "knobs" that are sensitive. But it appears to not > really put any requirement on that one actually protects. Is this how things > usually are done i YANG modules? > <NS> This is a general statement, in ‘unsolicited-bfd’ configure mechanism, there is no sensitive information. we may remove this section from the updated draft. </NS> > thanks. - Naiming > On Nov 14, 2022, at 05:18, Magnus Westerlund via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Magnus Westerlund > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@xxxxxxxx if you reply to or forward this review. > > I have a couple comments focused around how to deal with overload or attacks > using unsolicited BFD. > > 1) Section 7.1 > The formulations around the mitigations are poorly worded. > a) First the lead in to the bullet list states that this is mandatory but it > fails to use and RFC 2119/8174 words. b) "Limit the feature to specific > interfaces, and to single-hop BFD with "TTL=255" > [RFC5082]." I would think that this sentence would rather state that one > MUST use the RFC 5082 security mechanism for the BFD traffic. What is > unclear to me from not having read RFC 5082 in detail is if this mechanism > works well for this traffic or gets additional traffic into problems due > to scoping which appear to be interface wide. Thus, are further > clarifications on usage needed? > c) "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." > This mitigation usage is deployment dependent, thus better care in formulation > related to this is needed. This appears to be a MUST unless in this particular > situation and should be clearer. Also the actual support required for interop > appears a bit weak without having looked into RFC 5880 in detail. But only a > SHOULD support algorithm? > > 2) Not being an expert in BFD and its control parts it appears that there are > no mechanism for terminating an ongoing BFD session as the passive player in > case of any overload. It is even unclear if there are any other mechanism than > refusing to respond to a new session for the passive entity when getting > unsolicitied BFD. So it would be good if the document could be more explicit if > there are any action the passive entity can do if ending up with to many BFD > sessions? I understand the goal here is to limit the number of potential peers > as well as ensuring that they are trusted entities even before any packets are > sent, but are there really no method to stop the session? > > 3) Section 7.2: > So this section lays out the "knobs" that are sensitive. But it appears to not > really put any requirement on that one actually protects. Is this how things > usually are done i YANG modules? > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
