Last Call Review of draft-ietf-bier-evpn-13
review-ietf-bier-evpn-13-secdir-lc-sethi-2024-01-01-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.

This document defines procedures for forwarding broadcast, unknown unicast, and
multicast (BUM) traffic of Ethernet VPNs (EVPN) using Bit Index Explicit
Replication (BIER).

I am not at all familiar with this area and found the document somewhat
difficult to parse and comprehend. However, that is not necessarily a problem
since I am not the target audience in any case.

Some nits from my limited understanding:

The introduction mentions P-tunnels but it is explained a little later in
section 1.1.

I am not sure how should I interpret "As such, this document is also very much
aligned with [RFC8556]." What is RFC8556 and in what sense is the current draft
aligned?

Perhaps a reason or justification for this reuse could be helpful: "The same
codepoint 0x0B that IANA has assigned for BIER for MVPN [RFC8556] is used for
EVPN as well."

Several acronyms such as NLRI,mLDP P2MP NVGRE, GENEVE, BD, VNI/VSID are used
without expanding them on first use and without any definition in the
terminology section?

The document is missing the boiler plate text and reference to BCP 14 [RFC2119]
[RFC8174].

Considering BCP 14, how should one interpret the phrase "they do NOT apply to
EVPN"? Perhaps SHALL NOT or SHOULD NOT?

The security considerations section simply provides references to [RFC7432] and
[RFC8556] for security implications. I guess that is okay, but I noticed that
[RFC8556] further references [RFC8279] and [RFC8296] for security
considerations. Perhaps that is acceptable. One could consider stating that the
security of this solution is based on the full trust of the complete end-to-end
BIER network. There is no cryptography to ensure that a packet is not
manipulated enroute and properties such as integrity confidentiality of the
traffic is ensured at higher layers?