Éric, The following edits are ready for submission. Confirm these are what you want in -13 and they'll go out.
-- Jeff > On Oct 17, 2024, at 2:29 AM, Eric Vyncke (evyncke) <[email protected]> wrote: > > Jeff and other authors, > > Thanks for your patience on this one. > > Except for the point below EVY2>, all is clear and good to go. Thank you, > Reshad, for the updated shepherd’s write-up. > > Please fix at least the EVY2> about the SHOULD (and think about my suggestion > for the security section), then I will move forward with the IETF last call [...] > > # Section 4.2 > > If only the largest MTU is probed and fails, then why not also trying smaller > MTU rather than being blind about the MTU ? This behavior is consistent with > section 4.4 but still a little weird to my eyes. > > From the other thread: > It's inconsistent with deployed BFD behavior. When you have multiple > clients, you go for the most restrictive set of parameters. > > EVY> did you mean “inconsistent” or “consistent” above ? > EVY> does it mean that if the largest-MTU client fails, then all clients fail > ? I.e., the link will be declared as down ? This seems quite drastic to me. > > Trying a less restrictive setting is inconsistent with existing BFD behaviors. > > Thus, your observation is correct, and it is drastic. This is intentional. > It is also a SHOULD and permits implementations that wish to try to > selectively negotiate to less strict set of parameters do so. A form of such > negotiation was raised by Xiao Min as part of discussing these MTU fetures > and could leverage BFD Poll sequences. > > That said, it was appropriate for us to make a base recommendation. > > EVY2> understood (even if too drastic to my taste though), but then be clear > about the drastic consequence when the SHOULD is ignored else my fellow ADs > will complain about a SHOULD used improperly (i.e., w/o enough explanations) Your fellow ADs can't decide to support weaker SHOULDs and often will insist on stronger MUSTs that they then admit they expect to be ignored. That said, we're at the part of the process where this is making the gatekeepers happy rather than supplying terse text.[1] I've added the following that will hopefully satisfy you: + sessions to the same endpoint. Failure to select the largest size will result in BFD + sessions going to the Up state and dependent applications not having their MTU + requirements satisfied. In other words, if you configure it this way, you'll have things breaking and wonder why. Answer, don't do that. > As noted in the other thread I don't think a pointer to the IEEE LAG > specification is helpful and would prefer to avoid adding it unless required. > > EVY2> Up to you even if I still wonder why my suggestion is refused. It is our experience from the BFD over LAG work that the addition of IEEE citations brings significant additional attention to documents often in unhelpful ways. Effectively, "sorry, what are you doing to our technology?" We're not doing anything to it, please don't bother us because we dared utter its name in public.[2] See also why this section is in here at all... it made the WG happy rather than specifically adding technical clarity to the mechanism. > > More generally, I do not understand why this section is relevant to Large > Packet BFD, i.e., it seels applicable to most BFD techniques. So why having > it in this I-D ? > > Answered in other thread. > > EVY2> suggest then adding “The above text also applies to most if not all BFD > techniques” Added: + <t> + <!-- This text added to make Eric Vyncke happy during AD review --> + The above text also applies to most, if not all, BFD techniques. + </t>. > EVY2> AFAIK, it is really mandatory in YANG model RFCs. So, it is a good > addition. Note that I didn't find it in the YANG boilerplate considerations.[3] Perhaps I missed it. It'd be good for the ADs to verify that it is indeed part of the public checklists. > > # Section 6 > > Could an on-path attacker selectively drop those Large Packets BFD to reduce > the overall link efficiency by dropping the MTU ? > > Answered in the other thread. > > EVY2> and the provided justification (thanks for it) should be added in the > section if only to avoid another comments This text added: + <t> + <!-- This text added to make Eric Vyncke happy --> + On-path attackers that can selectively drop BFD packets, including those with large + MTUs, can cause BFD sessions to go Down. + </t> IMO, the text is highly perverse. The entire purpose of BFD is to drop session in the presence of N lost BFD packets. If an attacker can do that at will, the feature is working as designed. As a consideration, it's a base protocol security discussion and doesn't belong in extension documents. In fact, it's covered in section 9 of RFC 5880: As BFD may be tied into the stability of the network infrastructure (such as routing protocols), the effects of an attack on a BFD session may be very serious: a link may be falsely declared to be down, or falsely declared to be up; in either case, the effect is denial of service. An attacker who is in complete control of the link between the systems can easily drop all BFD packets but forward everything else (causing the link to be falsely declared down), or forward only the BFD packets but nothing else (causing the link to be falsely declared up). This attack cannot be prevented by BFD. -- Jeff > > -- Jeff > > [1] https://www.rfc-editor.org/rfc/rfc1925 <https://www.rfc-editor.org/rfc/rfc1925>, Section 2.12. [2] https://en.wikipedia.org/wiki/Speak_of_the_devil <https://en.wikipedia.org/wiki/Speak_of_the_devil> [3] https://wiki.ietf.org/group/ops/yang-doctors-review <https://wiki.ietf.org/group/ops/yang-doctors-review>
