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.