Éric, Done.
-- Jeff > On Nov 13, 2024, at 6:05 PM, Eric Vyncke (evyncke) <[email protected]> wrote: > > Jeff and other authors, <> > > Please submit a revised version with the below edits. I will then initiate > the IETF Last Call > > Regards > > -éric > From: Jeffrey Haas <[email protected]> > Date: Thursday, 17 October 2024 at 15:36 > To: Eric Vyncke (evyncke) <[email protected]> > Cc: [email protected] <[email protected]>, John Scudder <[email protected]>, > [email protected] <[email protected]>, Reshad Rahman <[email protected]> > Subject: Re: Alternate AD review of draft-ietf-bfd-large-packets-11 > > É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] > <mailto:[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>
