Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks
draft-ietf-bess-evpn-proxy-arp-nd-16
Yes
(Martin Vigoureux)
No Objection
(Alissa Cooper)
(Deborah Brungard)
(Magnus Westerlund)
Note: This ballot was opened for revision 10 and is now closed.
Erik Kline
(was Discuss)
No Objection
Comment
(2021-07-18 for -14)
Sent
This seems much improved in many ways; thanks very much. [S3.5] [comment] * For send-refresh of IPv6 addresses, I suspect the PE might use an IPv6 SA == unspecified address and an SLLA option with the MAC address equal to the PE sender MAC. Alternatively, if the PE has an IPv6 link-local address in the BD then it can just do the normal NS dance. But I'll defer to Eric Vyncke as I'm sure he has more experience in this area (where a device wishes to be "transparent" at the IP layer). Ah, I see in section 3.7 it's assumed that the PE has an IPv6 link-local address configured in the BD. [S3.7] [nit] * "legit" -> "legitimate"
Murray Kucherawy
No Objection
Comment
(2021-01-20 for -11)
Sent
In addition to Barry's comments, I found that "BD" appears in the glossary twice, and "SLLA" appears in the glossary but nowhere else in the document. Are "Address Resolution" and "Large Data Center" formal terms? If not, they should be lowercase. Alluding to a lot of things Alvaro pointed out: Many of the SHOULDs in this document are bare, in that they give the implementer a choice but no guidance on how to make that choice. For instance: A Proxy-ARP/ND implementation SHOULD support static, dynamic and EVPN-learned entries. How would I decide whether I've got a use case that justifies not doing one of those, and what are the interoperability implications of that decision? I suggest reviewing these.
Roman Danyliw
No Objection
Comment
(2021-01-20 for -11)
Sent
Thanks to Russ Housley for the SECDIR review. A few editorial nits: ** Abstract. Please remove the reference [I-D.ietf-bess-evpn-na-flags] from the abstract as this section of the document is not permitted to have references. ** Section 3.1.b. s/They SHOULD be learned out of/They SHOULD be learned from/ ** Section 5.5. s/almost all IXPs installed/almost all IXPs install/
Warren Kumari
No Objection
Comment
(2021-01-20 for -11)
Sent
Thank you for engaging with, and addressing the OpsDir review, and thanks to Joe for performing it...
Éric Vyncke
(was Discuss)
No Objection
Comment
(2021-10-06)
Sent
Thanks to Jorge for addressing my previous DISCUSS and COMMENT issues. Regards -éric
Martin Vigoureux Former IESG member
Yes
Yes
(for -10)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -11)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(2021-01-18 for -11)
Sent
As mentioned in the Introduction: This document describes the Proxy-ARP/ND function in [RFC7432] networks, augmented by the capability of the ARP/ND Extended Community [I-D.ietf-bess-evpn-na-flags]. From that perspective this document updates [RFC7432]. Even with this statement, the purpose of this document and the relationship between it, rfc7432 and I-D.ietf-bess-evpn-na-flags is not completely clear to me. I would like to understand the following: - Why isn't this description included in I-D.ietf-bess-evpn-na-flags if the functionality is introduced there? - This document formally Updates rfc7432, but I-D.ietf-bess-evpn-na-flags didn't. How can the description of the function Update rfc7432 if the functionality doesn't? What exactly is the update to rfc7432? - The WG developed this document alongside I-D.ietf-bess-evpn-na-flags, but it is not referenced from there. Why? Besides those high-level questions, I have a set of comments that are mostly related to the normative language used. I would like to see these issues addressed before publication. (1) §3.1 recommends this: The provisioned static IP->MAC entry SHOULD be advertised in EVPN with an ARP/ND Extended Community where the Immutable ARP/ND Binding Flag flag (I) is set to 1, as per [I-D.ietf-bess-evpn-na-flags]. ...but I-D.ietf-bess-evpn-na-flags requires the behavior, from §3.1: o If an IP->MAC pair is static (it has been configured) the corresponding MAC/IP Advertisement route MUST be sent along with an ARP/ND Extended Community with the I Flag set. (2) §3.1: "An entry MAY associate a configured static IP to a list of potential MACs, i.e. IP1->(MAC1,MAC2..MACN)." s/MAY/may This is not a normative statement, but just a fact. (3) The phrase "MUST/SHOULD be learned" is used several times, but the normative action doesn't seem to apply to learning, but to what is required to learn. For example, from §3.1: a. Proxy-ARP dynamic entries: They SHOULD be learned by snooping any ARP packet (Ethertype 0x0806) received from the CEs attached to the BD. A better wording would be something like: "The PE SHOULD snoop all ARP packets received from the CEs in order to learn dynamic entries." The normative action is clear: snoop! Please review/update other places where this phrase is used. (4) §3.1: "They SHOULD be learned by snooping any ARP packet..." Why is this action only recommended? When would a PE not snoop the ARP packets? IOW, why is MUST not used? Note that neither rfc7432/I-D.ietf-bess-evpn-na-flags use Normative language then talking about snooping. (5) §3.1: "They SHOULD be learned out of the Target Address and TLLA information in NA messages (Ethertype 0x86DD, ICMPv6 type 136) received from the CEs attached to the BD." Same questions... (6) §3.1: "A Proxy-ND implementation SHOULD NOT learn IP->MAC entries from NS messages, since they don't contain the R Flag required by the Proxy-ND reply function." If the R flag is required, when is it ok to learn from NS messages? IOW, why is this action not a requirement? (7) §3.1.1: "the node MUST remove that router from the Default Router List...as specified in [RFC4861] section 7.3.3." This is in fact already specified in rfc4861, there's no need to specify it here again. s/MUST/must (8) §3.1.1: "Static entries SHOULD have the R Flag information added by the management interface. The O Flag information MAY also be added by the management interface." It sounds as if the action here is to add the flag, right? Perhaps: "The R Flag information SHOULD be added...for static entries. ..." When is it ok to not configure the flags? Why is the configuration not required? The text in I-D.ietf-bess-evpn-na-flags seems to assume that it is a requirement (but no normative language is used there): "R and O Flag values...are...configured in case of static entries." (§3.1) What if the value is not configured, what is the default? (9) §3.2: a. When replying to ARP Request or NS messages, the PE SHOULD use the Proxy-ARP/ND entry MAC address 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. It seems to me that the use as MAC SA should be required and not just recommended "so that the resolved MAC can be learned in...layer-2 switches". Why is that not the case? (10) §3.2: "A PE SHOULD NOT reply to ARP probes received from the CEs." When is it ok for the PE to reply? IOW, why is the behavior recommended and not required? (11) §3.2: "A PE SHOULD only reply to ARP-Request and NS messages with the format specified in [RFC0826] and [RFC4861] respectively." When is it ok to reply using a different format, and what format would that be? (12) §3.3: "The operator SHOULD be able to activate this option with one of the following parameters..." For the operator to be able to do anything, the implementation has to support the functionality. It might be better to recommend the implementation... (13) §5.1: "Existing mitigation solutions, such as the ARP-Sponge daemon [ARP-Sponge] MAY also be used in this scenario." This seems to just be an example: s/MAY/may (14) §6: "IXPs MUST still employ additional security mechanisms that protect the peering network..." Which are the required mechanisms? (15) §6: "IXPs...SHOULD follow established BCPs such as the ones described in [Euro-IX-BCP]." When is it ok to not follow "established BCPs"? Seeing that you are normatively recommending something, please add specific mechanisms, not just an example. (16) The references to ARP-Sponge and Euro-IX-BCP don't include enough information to access the documents. Is there a stable link that can be included?
Barry Leiba Former IESG member
No Objection
No Objection
(2021-01-19 for -11)
Sent
Just some very small points; please consider them, but there’s no need to respond. Please expand “EVPN” in the title, abstract, and introduction. It’s also not necessary to include the abbreviations for IXP, DC, and BD (which is misspelled as “DB”) in the abstract, as they’re each only used once there and are included in Section 1. Even after having “DC” and “IXP” defined, it seems better to me to spell them out in the section titles of 2.1 (“The Data Center Use Case”) and 2.2 (“The Internet Exchange Point Use Case”). Maybe consider that for Sections 5.5 and 5.6 as well. And throughout the document, “use case” doesn’t need a hyphen and shouldn’t have one.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2021-01-19 for -11)
Sent
Thanks for this clear and well-written document; the effort that went into presenting the information really comes through. I basically just have editorial nits as comments, with a few substantive notes on the security considerations section. For most of the document I was convinced that I understood this point, but then Section 5.5 led me to question myself: in the "static provisioning" learning mode, is the IP->MAC mapping configured only at the PE that the CE using those addresses will attach to, or at all PEs in the BD? I can follow up out-of-band with some editorial suggestions either way. Abstract (and Introduction) This document describes the EVPN Proxy-ARP/ND function, augmented by the capability of the ARP/ND Extended Community [I-D.ietf-bess-evpn-na-flags]. From that perspective this document updates [RFC7432]. [...] nit: this paragraph doesn't do very much to tell me what the nature of the update is. If it's just to clarify how all the pieces fit together we might add a clause at the end ", to provide more comprehensive documentation of the operation of the system as a whole" or similar. (Some parts of it might also have worked as an RFC 2026 Applicability Statement, but it is probably not worth the trouble of trying to rework things at this stage, especially since what we have is already nicely laid out.) Section 3 There's a lot of information packed into the Figure, and the surrounding text does a great job describing it. Thank you! The Proxy-ARP/ND function can be structured in six sub-functions or procedures: (editorial) the text from here to the end of the section feels distinct from the explanation of the figure; it might benefit from getting promoted into a (sub)section of its own. Section 3.1 An entry MAY associate a configured static IP to a list of potential MACs, i.e. IP1->(MAC1,MAC2..MACN). When there is more than one MAC in the list of allowed MACs, the PE will not advertise any IP->MAC in EVPN until a local ARP/NA message or any other frame is received from the CE. [...] (nit) would it be better to phrase this as "until a frame (including local ARP/NA message) is received from the CE"? That seems to emphasize that any traffic will do, even if we expect that traffic to be ARP/NA. Section 3.1.1 o Hosts build a Default Router List based on the received RAs and NAs with R Flag=1. Each cache entry has an IsRouter flag, which must be set based on the R Flag in the received NAs. A host can nit: maybe "must be set for received RAs and is set based on the R flag [...]" Section 3.6 The distributed nature of EVPN and Proxy-ARP/ND allows the easy detection of duplicated IPs in the network, in a similar way to the MAC duplication function supported by [RFC7432] for MAC addresses. nit: is this "MAC duplication detection function"? IP1->MAC2 in the Proxy-ARP/ND table. Static IP->MAC entries, that is, locally provisioned or EVPN-learned entries (with I=1 in the ARP/ND Extended Community), are not subject to this procedure. [...] nit: I think the sentence is better without the parentheses, since the presence of I=1 is critical for correct functioning and not intrinsic to the entries being EVPN-learned. 1. The entry in duplicate detected state cannot be updated with new dynamic or EVPN-learned entries for the same IP. The operator MAY override the entry though with a static IP->MAC. nit: commas before and after "though". 2. The PE SHOULD alert the operator and stop responding ARP/NS for the duplicate IP until a corrective action is taken. nit: "stop responding to". for IP1. Since the AS-MAC is a managed MAC address known by all the PEs in the EVI, all the PEs MAY apply filters to drop nit: this seems to be the first time that we talk about the AS-MAC being a managed address and being known to all PEs in the EVI; it might be worth rewording in light of that or mentioning that in the definition of AS-MAC. Section 5.2 This scenario minimizes flooding while enabling dynamic learning of IP->MAC entries. The Proxy-ARP/ND function is enabled in the BDs of the EVPN PEs, so that the PEs intercept and respond to CE requests. nit: from context it seems like the "dynamic learning" here refers to the EVPN-learned entries, but in §3.1 we reserved the term "dynamic" for entries learned by local snooping. Since the next paragraph talks about snooping as an optional addition, we run into semi-conflicting usage of the term "dynamic". I would suggest (assuming the above is correct) rewording this to "while enabling learning of IP->MAC entries over the EVPN" or similar. Section 5.5 These rules are often called port security. Port security summarizes different operational steps that limit the access to the IXP-LAN, to the customer router and controls the kind of traffic that the routers are allowed to exchange (e.g., Ethernet, nit: this list lacks parallel structure; going with "limit the access to the IXP-LAN and the customer router, and controls the kind of traffic" would be okay. Section 6 I think it would be useful to reiterate that the security considerations of RFC 7432 and draft-ietf-bess-evpn-na-flags continue to apply (in addition to the useful text that is already present here). I guess ARP and IPv6 ND are arguably also applicable (AFAICT the security properties of the proxied scheme are very similar to those of native usage, in an environment that already has to trust the PEs and provider network that supply the EVPN to the same extent that one would otherwise trust an IP router). It would also be my personal preference (though I do not insist upon it) to note that EVPN does not inherently provide cryptographic protection (including confidentiality protection) despite the word "private" appearing in the name. (This is really a topic that should be addressed via a long-term IETF-wide shift towards just "virtual network" instead of "virtual private network", but I try to mention it when I can so as to socialize the idea.) I appreciate the discussion (earlier in the document) of the use of dummy MACs to suppress unknown ARP-Request/NS flooding, added in response to the opsdir review. Is it worth calling out the security/availability considerations of that technique from this section? ("No" is a perfectly fine answer.) Is it too banal to repeat that configuring the unicast-forwarding and/or flooding sub-functions to be disabled risks blocking service for a CE if the static configuration is broken? The solution also provides protection against Denial Of Service attacks that use ARP/ND-spoofing as a first step. [...] Are these DoS attacks described anywhere that we might reference for further reading? ("No" is a perfectly fine answer.) When EVPN and its associated Proxy-ARP/ND function are used in IXP networks, they provide ARP/ND security and mitigation. IXPs MUST If I understand correctly, this security/mitigation is provided in the face of malicious CE devices, but the system still requires that PEs are trusted and does not provide cryptographic or independently verifiable assurances of correct IP->MAC bindings. I would suggest being explicit about the threat that is being protected against, since by itself the term "security" is so vague so as to become almost meaningless. For example, IXPs should disable all unneeded control protocols, and block unwanted protocols from CEs so that only IPv4, ARP and IPv6 I suggest the parenthetical "so that (for example) only"; we do not really have much reason to preclude other ethertypes if desired by the IXP.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -11)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -11)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(2021-01-15 for -11)
Sent
Please expand the following acronyms on first use, or in Section 1: EVPN, PE, EVI, VPLS. Similarly, CE is expanded in Section 2.2, which is not the first use. In Section 5.5, you use the term "white-listed". While not required, I ask that you change this to "allow-listed", which some have argued is a more inclusive term.
Robert Wilton Former IESG member
No Objection
No Objection
(2021-01-20 for -11)
Not sent
Thank you for this document, I found it easy to read and understand.