Reviewer: Wes Hardaker
Review result: Almost Ready

I 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 authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-lsr-ospf-bfd-strict-mode-07
Reviewer: Wes Hardaker
Review Date: 2024-02-22
IETF LC End Date: 2024-02-29

Summary: Almost Ready

Major Concerns: Unreasonable security considerations
Minor Concerns: Additional nits and comments

Security considerations:

Unfortunately just saying (paraphrased) "there are none beyond BIER
and extensions" is unlikely to be as helpful as it could be.  1. you
have not convinced me that it's true as you don't explain why the
situation is identical.  2. I would like to see text describing what
happens when the new extension is misused?  I'm not an expert here
(you are!) by my initial thoughts were you should explain that the
best an attacker could do would be to multiple a packet across more
links than intended, which actually may have a security issue since
you're now sending packets down a link that they won't supposed to go
down.  The two cases I'd hope to see spelled out at a minimum are: can
an attacker send traffic to a helper that shouldn't get it, and can an
attacker prevent traffic getting to a helper that should get to it.
The transport security should prevent this, but that should be stated
IMHO.

Nits and comments:

- First, the extensive use of examples in this document are fantastic
  and greatly helps the reader understand the problem space and
  specific deployment scenarios.  Thank you for including them.

- The BFR and BRER labels could use expansion somewhere for the
  uninitiated.

- I might have used a different acronym than "X" for discussing the
  BIER incapable router, but it works as is too.  To be more
  descriptive I might have just BIR or something just to be explicit.

- section 2 after Figure 3 in particular could use one more pass by a
  skilled author.  I found a number of the sentences hard to follow or
  had strange wording elements in them ("loop won't happen" without an
  article, "To allow multiple helpers to help the same non_FR...").

- I would probably expand TLV too, though it is a well understood
  acronym generally.

- section 3.1: I'd suggest "At step 2" -> "At step 2 in RFC8279
  section 6.9" just to be explicitly clear.

- section 3.1: "additional procedures are performed..."  additional to
  what?  Be explicit when you can.  Reference exactly what you're
  extending to reduce mistakes in interpretations.

- section 3.2: "There are three situations..."  and then you list only 2.






-- 
Wes Hardaker
USC/ISI