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

[Benjamin Kaduk <[e-mail]>]

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.
> 
> 
> 
>