Early Review of draft-ietf-idr-bgp-bfd-strict-mode-19
review-ietf-idr-bgp-bfd-strict-mode-19-secdir-early-migault-2026-10-01-00

Hi,

I have reviewed this document as part of the Security Directorate's ongoing 
effort to review all IETF documents being processed by the IESG. These 
comments were written primarily for the benefit of the Security Area 
Directors. Document editors and WG chairs should treat these comments just 
like any other last-call comments.

The summary of the review is Ready with issues.


With that caveat, my understanding of the mechanism is as follows. This 
document makes a BFD session a precondition for a BGP session: in strict-mode,
BGP is not permitted to reach the Established state until the associated BFD 
session is Up, and a subsequent BFD failure tears the BGP session down. As a 
result, the security of the BGP session becomes tied to two things — the 
negotiation of strict-mode itself (the capability exchange), and the 
establishment and continued stability of the BFD session. These are where the 
security considerations seem to me to concentrate.


In strict-mode, BFD's establishment and continued stability become 
preconditions for BGP. BFD's own protections are limited: its authentication (
RFC 5880) relies on deprecated algorithms (MD5, SHA-1) and is optional, so 
forged or replayed BfdDown/BfdUp packets are plausible against on-path 
attackers; its common path-based defense (GTSM, RFC 5082) is non-cryptographic
and only filters off-path attackers. Separately, the strict-mode capability 
itself can be stripped from the BGP OPEN unless the BGP session is integrity-
protected (TCP-AO, RFC 5925), silently disabling the feature. But the dominant
and hardest-to-mitigate threat is simple availability attack (DoS/DDoS): 
because authentication cannot prevent packet suppression, an attacker who 
drops or congests BFD traffic can block BGP establishment or, worse, tear down
an already-established, traffic-carrying BGP session — and can do so 
repeatedly to force sustained routing churn.

Relative to this, the current Security Considerations section (Section 12) 
appears to me to be missing the following:

1. The capability-negotiation attack is not mentioned at all. Strict-mode
only engages when both peers advertise the capability. An on-path attacker
who strips the capability from the OPEN message can silently disable the 
protection. There is no recommendation to integrity-protect the BGP session
(e.g., TCP-AO, RFC 5925) to prevent this downgrade.

2. The draft recommends "a BFD Authentication mechanism, some of which are
defined in RFC 5880,". However it should be mentioned that those mechanisms
rely on deprecated algorithms (MD5, SHA-1), exposing to replay attack. Note
also that I suspect authentication not being activated in practice. We 
probably need to point to a replay-resistant mode (e.g., meticulous keyed) or
point to stronger/newer BFD authentication work.

3. The off-path vs. on-path distinction is absent. My understanding is that 
neither GTSM nor BFD authentication defends against an on-path attacker 
who can suppress packets.

4. The current DoS sentence correctly notes that preventing or interrupting
BFD denies BGP. This makes BDG very sensitive to dropping/congesting BFD 
traffic and that authentication has in itself little effect.