|
Hi Jean-Michel, Thank you very much for the thorough review and my apologies for the delay in my reply. Please see my comments in-line with [jorge]. Thank you. Jorge
From: Jean-Michel Combes via Datatracker <noreply@xxxxxxxx>
Reviewer: Jean-Michel Combes
*/ [jorge] let me try to clarify since I agree this is important. In your example, both CEs are on the same L2 link. Suppose you have two CEs connected to an EVPN BD (as in the document)
CE1----PE1---evpn---PE2---CE2
In EVPN terminology we say CE1 and CE2 are in the same Broadcast Domain (BD, a broadcast from one CE will reach the other CE without any modification on the frame) and they belong to the same subnet. What that means is that CE1 needs to resolve CE2’s IP
address (via ARP/ND) and once it does, CE1 sends a unicast frame to CE2 and neither PE1 nor PE2 change the MAC SA or MAC DA of that frame. Frames between CE1 and CE2 will have the same behavior as if they were connected to the same L2 switch or L2 link. Does
this help?
*/
*/ [jorge] RFC4349 seems to be “High-Level Data Link Control (HDLC) Frames
over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)” – not sure what the link is with proxy-ND, is this the RFC you intended to refer to? Sorry if I am missing something.
About RFC6957, thanks for pointing that out. However, the scenario is different IMHO – RFC6957 refers to a point-to-multipoint topologies with a split-horizon forwarding, where the ‘CEs’ have no direct communication within the same L2 link. That is not the
same as in an EVPN BD, where the CEs have direct communication at L2. Please let me know if that makes sense.
*/
/* [jorge] good catch! Removed. Thanks! */
/* [jorge] I should probably clarify that the PEs doing proxy-ARP/ND do not have any assigned IPv6 address of their own in the BD. I agree with you that CEs connected to the PEs must do DAD, and PEs doing proxy-ND will reply to the DAD messages. If all the
CEs attached to the same BD have static entries on the PEs, ND flooding *among* PEs should be practically suppressed. I included the phrase “among PEs” to avoid confusion, let me know if that helps please:
“As PE3 learns more and more host entries in the Proxy-ARP/ND table, the flooding of ARP Request messages
among PEs is reduced and in some cases it can even be suppressed. In a network where most of the participant CEs are not moving between PEs and they advertise their presence with GARPs or unsolicited NA messages,
the ARP/ND flooding among PEs, as well as the unknown unicast flooding, can practically be suppressed. In an EVPN-based IXP network, where all the entries are Static,
the ARP/ND flooding among PEs is in fact totally suppressed.“
*/
/* [jorge] I agree, I changed it to:
“A Proxy-ARP/ND implementation MUST at least support the Learning, Reply and Maintenance sub-functions. The following sections describe each individual sub-function.”
*/
/* [jorge] I added the following, let me know if it addresses your questions please: The following considerations should be taken into account, assuming that the ARP Request/NS lookup hits a Proxy-ARP/ND entry IP1->MAC1: a. When replying to ARP Request or NS messages: - the PE SHOULD use the Proxy-ARP/ND entry MAC address MAC1 as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC FIB of potential layer-2 switches sitting between the PE and the CE requesting the Address Resolution. - for an ARP reply, the PE MUST use the Proxy-ARP entry IP1 and MAC1 addresses in the Sender Protocol Address and Hardware Address fields, respectively. - for an NA message in response to an address resolution NS or DAD NS, the PE MUST use IP1 as the IP SA and Target Address. M1 MUST be used as the Target Link Local Address.
*/
/* [jorge] good point, thanks, I added this: “Irrespective of the enabled option, if there is no successful Proxy-
ARP/ND lookup, the unknown ARP-Request/NS will be flooded in the
context of the BD, as per Section 3.6.”
*/
/* [jorge] following up on my response to your comment, the DAD messages from the CE will be replied by the proxy-ND function on the connected PE if there is a hit. Otherwise it should be flooded. The above case for IXPs with all static entries is an exception
that assumes there is always a successful lookup on the proxy-ND table, hence flooding could be avoided. I also added a sentence for the next paragraph: The flooding may also be suppressed completely in IXP networks with
dynamic Proxy-ARP/ND entries assuming that all the CEs are directly
connected to the PEs and they all advertise their presence with a
GARP/unsolicited-NA when they connect to the network. If any of
those two assumptions is not true and any of the PEs may not learn
all the local Proxy-ARP/ND entries, flooding of the ARP/NS/NA
messages from the local PE to the remote PEs SHOULD NOT be suppressed,
or the address resolution process for some CEs will not be completed.
*/
*/ [jorge] Since DAD is still performed by the CEs, we wanted to make this duplicate IP detection on the PEs as a recommendation rather than a MUST. Also there are many proxy-ND implementations for EVPN BDs out there that do not do this and we didn’t
want to make them non-compliant unless it is absolutely necessary. Let me know if it is ok to keep it as SHOULD.
Also, I added this to address your comment about RFC6957, let me know if it is ok: The Proxy-ARP/ND function SHOULD support duplicate IP detection so
that ARP/ND-spoofing attacks or duplicate IPs due to human errors can
be detected. For IPv6 addresses, CEs will continue to carry out the
DAD procedures as per [RFC4862]. The solution described in this
section is an additional security mechanism carried out by the PEs
that guarantees IPv6 address moves between PEs are legit and not
the result of an attack. [RFC6957] describes a solution for IPv6
Duplicate Address Detection Proxy, however, it is defined for point-
to-multipoint topologies with a split-horizon forwarding, where the
'CEs' have no direct communication within the same L2 link and
therefore it is not suitable for EVPN Broadcast Domains. In
addition, the solution described in this section includes the use of
the AS-MAC for additional security.
*/
/* [jorge] the “layer-2” refers to the network between the CEs and not the nature of the CEs or the messages they sent. I modified the sentence to clarify, let me know if it helps please: PEs do not intercept ARP/ND requests and flood all
requests issued by the CEs, as a conventional layer-2 network among
those CEs would do.
*/
/* [jorge] the attacker and the victim are in the same L2 broadcast domain, as discussed at the beginning of the email. Does that change your comment? Let me know if it doesn’t please. */
/* [jorge] Based on Russ’ review
https://mailarchive.ietf.org/arch/msg/bess/wi_uxXT1HGfxCGphJL6fDmeqPa4/ - I removed any references to SEND in the text. Other than that, I added this: Finally, it is worth noting that the Proxy-ARP/ND solution in this
document will not work if there is a mechanism securing ARP/ND
exchanges among CEs, because the PE is not able to secure the
"proxied" ND messages.
Taking your words as a model… Let me know if this addresses your concern, please.
*/
/* [jorge] thank YOU for such thorough review of the ND aspects! */ |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
