Thank you Ben. And sorry for the delay in replying. Jorge
From: Benjamin Kaduk <ka...@mit.edu> Date: Tuesday, March 9, 2021 at 12:18 AM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> Cc: The IESG <i...@ietf.org>, draft-ietf-bess-evpn-proxy-arp...@ietf.org <draft-ietf-bess-evpn-proxy-arp...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com> Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT) Hi Jorge, Thanks for these -- your proposals all sound good. With respect to your question about the "dummy MAC", I think I was referring to the AS-MAC (but I'm not 100% sure). I don't think there's anything about that topic that is critical to cover in the security considerations, so we should be okay with your editor's copy as-is. Thanks again, Ben On Mon, Mar 08, 2021 at 07:50:09PM +0000, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > Hi Benjamin, > > > > Thanks for the thorough review. > > Please see my comments in-line with [jorge]. I’ll incorporate the changes in > the next version. > > > > Thx > > Jorge > > > > > > ------------------------------------------------------------------------------------- > > From: Benjamin Kaduk via Datatracker <nore...@ietf.org> > > Date: Wednesday, January 20, 2021 at 7:51 AM > > To: The IESG <i...@ietf.org> > > Cc: draft-ietf-bess-evpn-proxy-arp...@ietf.org > <draft-ietf-bess-evpn-proxy-arp...@ietf.org>, bess-cha...@ietf.org > <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, Bocci, Matthew (Nokia > - GB) <matthew.bo...@nokia.com>, Bocci, Matthew (Nokia - GB) > <matthew.bo...@nokia.com> > > Subject: Benjamin Kaduk's No Objection on > draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT) > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-bess-evpn-proxy-arp-nd-11: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > 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. > > [jorge] thanks! > > > > 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. > > [jorge] I added this in section 3.1 to clarify, let me know if you prefer > different wording: > > “Static entries are provisioned from the management plane. A static entry is > configured on the PE attached to the host using the IP address in that entry” > > > > 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.) > > [jorge] ok, I added: > > “From that perspective this document updates RFC7432 to provide more > comprehensive documentation of the operation of the Proxy-ARP/ND function” > > > > > > 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. > > [jorge] done! Thanks. > > > > > > 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. > > [jorge] done. > > > > > > > > > > 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 > > [...]" > > [jorge] added: “Each cache entry has an IsRouter flag, which must be set for > received RAs and is set based on the R flag in the received NAs” > > > > 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"? > > [jorge] yes, added “detection” > > > > 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. > > [jorge] good point, removed. > > > > > > 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". > > [jorge] added > > > > 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". > > [jorge] fixed > > > > 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. > > [jorge] added this in the definition: “AS-MAC: Anti-spoofing MAC. It is a > especial MAC configured on all the PEs attached to the same BD and used for > the Duplicate IP Detection procedures.” > > > > 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. > > [jorge] you are right that 5.2 is confusing. I changed it to: > > “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 snoop ARP/ND messages issued by the CEs and respond to CE > ARP-requests/NS messages. > > PEs will flood requests if the entry is not in their Proxy table. Any unknown > source MAC->IP entries will be learned and advertised in EVPN, and traffic to > unknown entries is discarded at the ingress PE.” > > > > > > > > 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. > > [jorge] done. > > > > > > 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). > > [jorge] agreed. Added. > > > > > > 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.) > > [jorge] that sounds good to me. Added: “Note that EVPN does not inherently > provide cryptographic protection (including confidentiality protection).” > > > > > > 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.) > > [jorge] not sure what you mean by the use of “dummy MACs”? > > > > 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? > > [jorge] sure, I added: “While the unicast-forward and/or flooding suppression > sub-functions provide an added security mechanism for the BD, they can also > increase the risk of blocking the service for a CE if the EVPN PEs cannot > provide the ARP/ND resolution that the CE needs.” > > > > 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.) > > [jorge] It’s a generic statement, I fail to know what references to provide. > If you have suggestions I’d be glad to add them. > > > > > > 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. > > [jorge] sure, I added: “When EVPN and its associated Proxy-ARP/ND function > are used in IXP networks, they provide ARP/ND security and mitigation against > attacks from malicious CEs” > > > > 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. > > [jorge] added. > > > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
