RFCs section 5881 (single-hop) mentions that TTL/Hop-Limit MUST be set to 255 and MUST be discarded if the value != 255:
5. TTL/Hop Limit Issues
If BFD authentication is not in use on a session, all BFD Control
packets for the session MUST be sent with a Time to Live (TTL) or Hop
Limit value of 255. All received BFD Control packets that are
demultiplexed to the session MUST be discarded if the received TTL or
Hop Limit is not equal to 255. A discussion of this mechanism can be
found in [GTSM].
If BFD authentication is in use on a session, all BFD Control packets
MUST be sent with a TTL or Hop Limit value of 255. All received BFD
Control packets that are demultiplexed to the session MAY be
discarded if the received TTL or Hop Limit is not equal to 255. If
the TTL/Hop Limit check is made, it MAY be done before any
cryptographic authentication takes place if this will avoid
unnecessary calculation that would be detrimental to the receiving
system.
In the context of this section, "authentication in use" means that
the system is sending BFD Control packets with the Authentication bit
set and with the Authentication Section included and that all
unauthenticated packets demultiplexed to the session are discarded,
per the BFD base specification.
We don't do any such checks today, which we should consider doing.
Also of note: this requirement is obviously not present for Multi-Hop BFD (RFC 5883), but a configurable minimum TTL/Hop Limit would make sense as a coarse security mechanism akin to BGP TTL Security.
RFCs section 5881 (single-hop) mentions that TTL/Hop-Limit MUST be set to 255 and MUST be discarded if the value != 255:
We don't do any such checks today, which we should consider doing.
Also of note: this requirement is obviously not present for Multi-Hop BFD (RFC 5883), but a configurable minimum TTL/Hop Limit would make sense as a coarse security mechanism akin to BGP TTL Security.