Zahed, On Mon, Jan 13, 2025 at 02:05:19PM +0100, Zaheduzzaman Sarker wrote: > On Wed, Jan 8, 2025 at 3:14 PM Jeffrey Haas <[email protected]> wrote: > > > On Jan 8, 2025, at 7:39 AM, Zaheduzzaman Sarker via Datatracker < > > [email protected]> wrote: > > The specification intentionally does not check the payload in the padding. > > But this specification is enforcing it with normative text.
No, Zahed. It enforces that the contents are set to a value. It currently says nothing about checking that value. Only the procedures from RFC 5880 apply. If you believe otherwise in the current text, please point out the section you think applies to receive procedures. A large packet doesn't permit fragmentation that can't be transmitted end to end due to MTU issues is dropped. That's sufficient for BFD's purposes. > > Implementation experience has showed that it interferes with line rate > > behaviors. The small CPUs attached the line cards basically end up burning > > precious resources doing memcmp. > > > > The Working Group and authors did discuss payloads that were non-zero and > > validated. For example, test patterns. > > > > The motivation to specify zeroed contents was: > > - Useful for security to avoid the usual "I've leaked stuff in my memory > > onto the wire and it has security impact". > > - Implementations effectively only need to buffer the very small BFD PDU > > as payload and can efficiently generate or drop the rest of the contents. > > The implementation thus can validate the usual IP stack checksums without > > having to keep the very large buffers around in line card "application" > > space. > > > > It would be useful to write these reasons in the specification as there are > security and computation complexities associated with it. As covered in prior threads, I'm happy to add the detail that zeroes are being written to avoid having random data exposed in the PDU. Similarly, I'm happy to add text clarifying the contents are not checked - effectively John's suggestion. I object to embedding the implementation detail as it's relevant to some environments on some platforms today. Doing otherwise is akin to writing "640KB of memory is enough for anyone!" > If the real intention is that the implementation just reads the BFD payload > and there is good motivation for putting Zeros then I would suggest writing > - the BFD endpoints/implementation MUST discard any non-zero values. @John > Scudder <[email protected]> had a better suggestion during the telechat. As noted, I'll use some form of the above. > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > One more comment - if the intention is to have this bfd in large packets > > to > > > discover the path MTU, why don't we say so in the abstract of this > > document. > > > > Discover is never mentioned in the document - that is not the purpose. > > BFD state machinery is inappropriate for that. > > > > Good that you said BFD state machinery is inappropriate here. However, > essentially we are trying to learn the PATH MTU here in a multihop BFD, > aren't we? This is a binary test: The Path MTU is sufficient for the application. From the text in 4.4: "BFD for Large Packets only ensures that the minimally acceptable MTU for the session is able to be used." "Learning" the Path MTU would involve probing the MTU without taking the BFD session down. We did discuss this use case for diganostic purposes, but the core value of this feature is that the end to end path is sufficient for the application protected by BFD. If the Path MTU is big enough, good. If it's not big enough, bad. For BFD to generally do any sort of probe, the intention would have to be generating packets that are expected to drop. Dropped packets beyond the configured "Detect Mult" value in RFC 5880 cause the session to drop. Session drops are signaled to one or more BFD clients and are used to drop slower protocols from their established states. -- Jeff
