Re: [Last-Call] Secdir last call review of draft-ietf-bier-evpn-13

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Mohit,

Thank you very much for your comments. I posted revision -014.
Please see zzh> below.


Juniper Business Use Only
-----Original Message-----
From: Mohit Sethi via Datatracker <[e-mail]>
Sent: Monday, January 1, 2024 2:39 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Secdir last call review of draft-ietf-bier-evpn-13

[External Email. Be cautious of content]


Reviewer: Mohit Sethi
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.

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.

Zzh> I changed it to "provider tunnels".

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?

Zzh> I added " that specifies MVPN with BIER" after "... with [RFC8556]".

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."

Zzh> It's beyond that code point. The paragraph also says:

   For terseness, some background,
   terms and concepts are not repeated here.  Additionally, some text is
   borrowed verbatim from [RFC8556].

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?

Zzh> BD was already expanded, though now I changed it to the more correct "Broadcast Domain".
Zzh> I expanded NLRI.
Zzh> VXLAN/NVGRE/GENEVE are first mentioned in the following context with relevant RFC references:

      For EVPN-VXLAN/NVGRE/GENEVE [RFC8365]
      [RFC7348] [RFC7637] [RFC8926], this field is a 24-bit VNI/VSID of
      global significance.

Zzh> While I can expand them to Virtual Extensible LAN (VXLAN),  Network Virtualization using Generic Routing Encapsulation (NVGRE), and Generic Network Virtualization Encapsulation (GENEVE), I am not sure if that does add value besides adding clutters?

Zzh> Nonetheless, I added them and RSVP/mLDP-P2MP to the terminology section.

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

Zzh> Strange. I do see it in https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/?

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?

Zzh> RFC7432 has the following:

   *Users of VPN services* are expected to take appropriate
   precautions (such as encryption) to protect the data exchanged over
   a VPN.

Zzh> There is no difference whether BIER or some other kinds of tunnels are used. W/o end-to-end encryption, the security is based on the full trust of the complete *provider* network, which the BIER network is part of. Therefore, if it's ok with you I'd rather not saying more besides referring to RFC7432 and RFC8556 (which refers to RFC8279 and RFC8296).

Zzh> Thanks!
Zzh> Jeffrey