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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.

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.