Skip to main content

Last Call Review of draft-ietf-bier-idr-extensions-12
review-ietf-bier-idr-extensions-12-secdir-lc-weis-2024-09-27-00

Request Review of draft-ietf-bier-idr-extensions
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2024-10-03
Requested 2024-09-19
Authors Xiaohu Xu , Mach Chen , Keyur Patel , IJsbrand Wijnands , Tony Przygienda , Zhaohui (Jeffrey) Zhang
I-D last updated 2024-09-27
Completed reviews Rtgdir Last Call review of -11 by Ketan Talaulikar (diff)
Secdir Last Call review of -12 by Brian Weis (diff)
Opsdir Last Call review of -12 by Tim Chown (diff)
Genart Last Call review of -12 by Behcet Sarikaya (diff)
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-ietf-bier-idr-extensions by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/_H8nVLnUovsjAco8hvStwCjxaII
Reviewed revision 12 (document currently at 14)
Result Has nits
Completed 2024-09-27
review-ietf-bier-idr-extensions-12-secdir-lc-weis-2024-09-27-00
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 Has Nits.

This document supports the new Bit Index Explicit Replication (BIER),
which is a new multicast forwarding architecture. It adds the ability
to pass BIER state through newly-defined BGP path attributes. As
they are wholly contained within BGP, there does not appear to be
any security considerations with the new path attributes themselves.

BIER is using the BGP path attributes to build multicast trees, as
opposed to using a dedicated multicast routing protocol to build
multicast trees.  As such, BGP needs to maintain a new set of policy
to determine to which peers (internal and external) to which the
BIER policy (e.g., which interfaces are allowed to include multicast
group members into the tree).  The Introduction mentions "this
document specifies procedures to prevent the BIER attribute from
"leaking out" of a BIER domain. However, there is no further explicit
mention of how leakage is prevented. I believe that the following
text from the "Operational Considerations" that is intended to
convey the control of leakage:

    "A boundary router of the AD that supports the BIER attribute MUST
   support a per-EBGP-session/group policy, that indicates whether
   the attribute is allowed and by default it is NOT allowed.  If
   it is not allowed, the BIER attribute MUST NOT be sent to any
   EBGP peer of the session/group."

If that is what is supposed to control "leakage", then as a minimum
this text should explicitly state this in order to support the
claim in the Introduction.

Additionally, I think Security Consideration should point out that
if the policy is not applied properly (i.e., a BGP administrator
violates the MUST and MUST NOT in the above quoted text), then
multicast data may be leaked out of interfaces which were not
intended to include multicast data group members, and leaking will
happen.

I find this document, which is managing the multicast forwarding,
to be silent on what is the policy for managing the multicast data.
For example, the fact that only data from specific multicast addresses
may be authorized by policy to transit a particular interface,
whether or not a grouping of related multicast data streams is
supported, etc.  RFC 8279 (BIER) seems to punt how the policy is
managed  to the routing protocol extension documents. While I
understand that the instantiation of this policy is expected to be
implementation-specific, it seems like some guidance as to what
kind of policy is necessary to support the BGP BIER extensions will
actually manage would be valuable for interoperability. If this
type of policy is already in another BIER document than it should
be referenced.