On Fri, Jun 7, 2024 at 4:12 PM Jeffrey Haas <jh...@pfrc.org> wrote:
> 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. > > [Joe] Thanks for the explanation. I missed the fact that there already is a limit imposed by the MTU of the interface. I think this is sufficient to avoid problems with excessively large packets. I don't think any change is needed and the document is ready. > 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 > > > >
