Joseph, Thanks for the review. Unfortunately, I think your comments run contrary to the entire nature of the draft. :-)
> On Jun 7, 2024, at 10:43 AM, Joseph Salowey via Datatracker > <nore...@ietf.org> wrote: > The document is well written and fairly simple. Referencing the previous > security considerations does provide some good advice, but it seems that this > document perhaps adds some considerations about the size of BPDU packets. It > seems that it would be possible for excessively large packets could cause > problems for the sender or receiver. Perhaps add something to the security > considerations about: Implementations should consider this and set appropriate > upper bounds on amount of padding added to these messages and on the length of > received messages. The entire point of the feature is the user chooses the size of the PDU in order to test the path MTU. Thus, the PDU may be at most the max local interface MTU size on purpose. Similarly, implementations must be, in circumstances where the MTU is the size of the PDU, be willing to receive such PDUs which may be the local interface MTU BFD is received over. Certainly on the receive side of things, if the operator cares to limit the maximum size of the received PDU smaller than the interface MTU (which seems perverse, but perhaps the path MTU and the interface MTU are intentionally different), such a thing might be doable. However, such a limitation would need to be implemented at the appropriate higher encapsulation layer carrying the BFD PDU. For BFD over IP, this is carried in UDP. Thus, the limiting mechanism would be a firewall on IP+UDP packets to the relevant BFD port for a given packet size. This would be outside the scope of BFD as BFD has never made implementation recommendations relying on firewalls. Please note that fragmentation isn't an expected attack since the specification requires the don't fragment bit when using IPv4. It's finally worth noting that receive size limitations enforced at layers outside of BFD may negatively impact unidirectional PMTU detection. Dropped packets will cause the relevant BFD session to go down even if the PDU sent to probe the unidirectional PMTU from the sender had successfully made it through to the receiver. It becomes, "I will only let you detect MTU up to size X". -- Jeff
