Hi Folks, There don’t appear to be any show-stoppers in Magnus’s review so I’ve gone ahead and requested to place this on the December 15 IESG agenda. However, please do follow up with Magnus and push a new version if appropriate.
Thanks, —John > On Nov 14, 2022, at 8:18 AM, Magnus Westerlund via Datatracker > <[email protected]> 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 > [email protected] 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 > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!FTlZvu0qnx4BA0J6JTpCo99WJecP6PLqRZicdoCLfHZ6Z3-Lt8xCug9m8alekRN2OhF1BxmydOm-$
