Hi Brian,
Thanks for your review and comments. Please see zzh> below.
Juniper Business Use Only
-----Original Message-----
From: Brian Weis via Datatracker <noreply@xxxxxxxx>
Sent: Friday, September 27, 2024 9:36 PM
To: secdir@xxxxxxxx
Cc: bier@xxxxxxxx; draft-ietf-bier-idr-extensions.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Secdir last call review of draft-ietf-bier-idr-extensions-12
[External Email. Be cautious of content]
Reviewer: Brian Weis
Review result: Has Nits
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.
Zzh> I added in the introduction section a reference to this operational consideration section:
... In addition,
this document specifies procedures to prevent the BIER attribute from
"leaking out" of a BIER domain (Section 7). <---- reference to the operational considerations
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.
Zzh> The security consideration section does mention the operational considerations:
This document introduces no new security considerations beyond those
already discussed in [RFC4271] and [RFC8279] and the operational
considerations (Section 7) of this document.
Zzh> It does not explicitly talk about leaking, though it should be expected that at the domain boundary one must take precautions as mentioned in the operational considerations.
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.
Zzh> BIER does not have policies that control on which interfaces certain multicast data may be sent. BIER is a "transport" technology - multicast traffic arriving at an ingress BIER router (BFIR) will be delivered to a set of egress BIER routers (BFERs) via the BIER domain. The BFIRs and BFERs run multicast "flow overlay" protocols, e.g., PIM/IGMP, for BFERs to determine if there are downstream receivers and then notify BFIRs so that BFIRs can signal further upstream using the flow overlay protocol to pull traffic and then deliver incoming multicast data to BFERs with a corresponding BitString. Once traffic arrives at the BFERs, the BFERs are responsible to deliver multicast payload according to the flow overlay signaling. BIER signaling extensions to ISIS/OSPF/BGP, or even the flow overlay protocols like PIM, don't control which interfaces should not be used for certain multicast data. The policy is separate from the protocols - for example, one may have policies to ignore certain PIM joins on certain interfaces, but that's not the job of the PIM protocol, and for this document (as well as BIER extensions for ISIS/OSPF), policy control is outside of the scope.
Zzh> Thanks!
Zzh> Jeffrey
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
