Skip to main content

Last Call Review of draft-ietf-bier-tether-05

Request Review of draft-ietf-bier-tether
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2024-02-29
Requested 2024-02-15
Authors Zhaohui (Jeffrey) Zhang , Nils Warnke , IJsbrand Wijnands , Daniel O. Awduche
I-D last updated 2024-02-29
Completed reviews Rtgdir Telechat review of -05 by Adrian Farrel
Secdir Last Call review of -05 by Wes Hardaker
Opsdir Last Call review of -05 by Dan Romascanu
Genart Last Call review of -04 by Joel M. Halpern (diff)
Assignment Reviewer Wes Hardaker
State Completed
Request Last Call review on draft-ietf-bier-tether by Security Area Directorate Assigned
Posted at
Reviewed revision 05
Result Has issues
Completed 2024-02-29
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

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

- 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