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.
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.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
