Brian,
> On Dec 17, 2024, at 10:56 AM, Brian Trammell via Datatracker > <[email protected]> wrote: > > Reviewer: Brian Trammell > Review result: Ready with Issues [...] > This seems like a fairly straightforward extension to BFD that adds the > ability > to make loopback packet larger in order to check bidirectional forwarding MTU. > I have no particular transport concerns with this extension in isolation. > > I'm not sure about the statement in the security considerations section that > "[t]his document does not change the underlying security considerations of the > BFD protocol or its encapsulations." Yes, it's not the 90s anymore, but AIUI > the concept does involve changing packet sizes across potentially multiple > encapsulation layers where there might be lurking assumptions about packet > lengths and buffer size, and buffer size misalignments are still an easy place > to find vulnerabilities. Would a statement to the effect that implementors of > this specification should take care with packet sizes being dynamic where > prior > to this extension they were not be warranted in the security considerations > section? The functionality described here is intended to pad a BFD PDU at the layer appropriate to the BFD encapsulation type in question. For IP types, this is UDP. So, you're just making a large UDP packet and are not otherwise thrashing through the various layers in the OSI stack under that. RFC 5884 BFD for MPLS similarly uses UDP encapsulation so the consideration remains the same. RFC 5885 permits both an IP/UDP encapsulation for pseudowires, but also a raw mode as well. BFD large is applicable easily for the IP/UDP case. Other options for padding for the VCCV control channel would need separate exploration. RFC 7130 Micro BFD for Ethernet LAGs similarly uses IP/UDP. Hopefully the above helps put your concerns to rest that the expected use here is simply a large UDP PDU for the covered cases rather than trying to play the OSI layer cake like an accordion. -- Jeff
