Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

Thank you Ben. And sorry for the delay in replying.

Jorge

From: Benjamin Kaduk <[e-mail]>
Date: Tuesday, March 9, 2021 at 12:18 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>
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 <[e-mail]>
>
> Date: Wednesday, January 20, 2021 at 7:51 AM
>
> To: The IESG <[e-mail]>
>
> Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>
>
> 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.
>
>
>
>