Hi Mališa,
Thank you for your review.
The effect of receiving the wrong O or R flags will mean the receiving host will trigger the wrong RFC4861 procedures. I added this text, hopefully it is sufficient:
For example, as specified in [RFC4861], the receiver of a NA message with
O not set will not update its existing cache entry for the IP->MAC,
hence the communication between the owner of the IP address and the
receiver of the NA message with the wrong O flag will fail.
Similarly, the receiver of a NA message with the wrong R flag, may
update its Default Router List incorrectly adding or removing an
entry.
Let me know if you have further comments.
Thanks.
Jorge
From: Mališa Vučinić via Datatracker <noreply@xxxxxxxx>
Date: Tuesday, September 1, 2020 at 12:59 PM
To: secdir@xxxxxxxx <secdir@xxxxxxxx>
Cc: bess@xxxxxxxx <bess@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, draft-ietf-bess-evpn-na-flags.all@xxxxxxxx <draft-ietf-bess-evpn-na-flags.all@xxxxxxxx>
Subject: Secdir last call review of draft-ietf-bess-evpn-na-flags-05
Reviewer: Mališa Vučinić
Review result: Has Nits
I 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
authors, document editors, and WG chairs should treat these comments just like
any other IETF Last Call comments.
The document specifies an extension to an Ethernet Virtual Private Network
(EVPN) MAC/IP advertisement by defining an EVPN Extended Community carrying
flags relevant to the ARP/ND resolution.
The abstract of the document does not include enough background context for it
to be useful to the general audience. Otherwise, the document is well written.
The security considerations section should be further elaborated. For instance,
the section includes a discussion on a possible misconfiguration of Router (R)
/Override (O) flags but the discussion is limited to the fact that the
misconfiguration of an IPv6/MAC binding on a given Provider Edge device (PE)
will propagate, through the means of IPv6 Neighbor Solicitation messages, to
other PEs in the same broadcast domain. I would like to understand better the
effect of each flag, i.e. what kind of behavior in the network can an attacker
cause by changing one of these flags on a particular device or in transit?
