Re: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

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

Hi Erik,

Thank you for your thorough review. Will publish a new version addressing your great comments as well as the ones in other reviews too.
Please see in-line with [jorge].

Thx
Jorge

From: Erik Kline via Datatracker <[e-mail]>
Date: Thursday, January 21, 2021 at 8:21 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: Erik Kline's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)
Erik Kline has entered the following ballot position for
draft-ietf-bess-evpn-proxy-arp-nd-11: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ meta ]

* I appreciate the attempt to explicitly discuss handling NS/NA messages with
  not-previously-seen options.  Thank you for that.

  It seems to me, however, that the proposed approach to proceed with
  setting the current capabilities in concrete but point to things like
  "unicast-forward" as a relief valve, even though 3.2-f seems to say the
  multicast packets (i.e. on cache miss) should be discarded (implying the
  unicast mapping might never be learned in the first place?).
[jorge] I think you are saying that the spec should also allow an option to forward, even if the MAC DA of the IP owner is not known on the PE. That sounds reasonable, although I would think operators who implemented the draft in their EVPN networks would prefer more security and not allow flooding ARP-Requests/NS with unknown options. I modified 3.2-f as follows, let me know if that addresses your concern:
   f.  A PE MUST only reply to ARP-Request and NS messages with the
       format specified in [RFC0826] and [RFC4861] respectively.
       Received ARP-Requests and NS messages with unknown options SHOULD
       be either forwarded (as unicast packets) to the owner of the
       requested IP (assuming the MAC is known in the Proxy-ARP/ND table
       and BD) or discarded.  An option to flood ARP-Requests/NS
       messages with unknown options MAY be used.  The operator should
       assess if flooding those unknown options may be a security risk
       for the EVPN BD.  An administrative option to control this
       behavior ('unicast-forward', 'discard' or 'forward') SHOULD be
       supported.  The 'unicast-forward' option is described in
       Section 3.4.



[ general ]

* When a PE reboots, should it do MLD (e.g. 2710, 3810, ...) of some kind to
  gather critical state so that it doesn't have to wait for CEs to have
  problems?
[jorge] hmm...in this document the PEs provide a layer-2 BD for the CEs that they connect (the PEs do not generally have IP interfaces in that BD). If no MLD-snooping is enabled in the BD, the ND multicast messages are flooded to all the CEs attached to the local PE or remote PEs. So upon reboot, when the PE is back online it will start building its proxy-ARP/ND database again, and in the meantime it will flood NS that do not hit an entry. Whether the operator decides to use MLD snooping or not on the same BD where proxy-ARP/ND is enabled, is out of scope of this document... we can add a sentence say that, do you think it is needed? Let me know if I am misunderstanding please.


[ section 3.1 ]

* To my knowledge there is no concept in IPv6 of a link where anycast/O=0
  NAs only propagate partway through a broadcast domain.  In practice, if I
  understand the architecture correctly, O=0 NAs will propagate to all CEs
  "behind" a given PE but, if anycast=false, no further.

  This could lead to a difficult to debug scenario (though I admit this is
  probably quite rare).

  Note that 4861-7.2.4 implies that most nodes sending NAs for their own
  addresses will adhere to "the Override flag SHOULD be set to one".  This
  is not a MUST, though.  Dropping all O=0 NAs might affect some
  implementations that don't comply with this SHOULD.  I have no idea how
  many implementations this might affect (in practice, I suspect none?), but...
  I think it might need to be considered.
[jorge] the NA messages with O Flag = 0 should not be dropped, they are normally forwarded by the PE based on the MAC DA. The only consideration is that the IP->MAC bind will only be learned on the proxy-ND table if the ‘anycast’ capability is enabled in the PE’s BD. Otherwise the NA message will be normally forwarded, its IP->MAC not being learned. We added a sentence to clarify that:

          Note that if the O Flag is zero in the received NA message,

          the IP->MAC SHOULD only be learned in case IPv6 'anycast' is

          enabled in the BD.  Irrespective, an NA message with O Flag =

          0 will be normally forwarded by the PE based on a MAC DA

          lookup.



[ section 3.1.1/3.2 ]

* I was not able to understand what the typical disposition of the O bit
  is supposed to be in these proxied NAs.  Is the intent to default to O=0 so
  that local O=1 can be preferred (vis. 4861-7.2.4 and 4389)?  Or will it
  more typically be set to O=1 (as if just replaying the NA that was learned
  by another PE)?
[jorge] normally the PE will learn an IP->MAC bind, e.g., IP1->MAC1, in its proxy-nd table from received NA messages with O=1 or EVPN routes with O=1. Hence when replying to received NS for IP1 the PE will issue an NA with O=1. However, the document also allows to configure the support for “anycast” in the proxy-nd function, in which case, the PE proxy-nd function will learn IP1->MAC1 with O=1 or 0, depending on how the flag is set on the received NA or EVPN route for IP1->MAC1. I modified the text to clarify this:

   Note that, typically, IP->MAC entries with O=0 will not be learned,

   and therefore the Proxy-ND function will reply to NS messages with NA

   messages that contain O=1.  However, this document allows the

   configuration of the "anycast" capability in the BD where the Proxy-

   ND function is enabled.  If "anycast" is enabled in the BD and an NA

   message with O=0 is received, the associated IP->MAC entry will be

   learned with O=0.  If this "anycast" capability is enabled in the BD,

   Duplicate IP Detection must be disabled so that the PE is able to

   learn the same IP mapped to different MACs in the same Proxy-ND

   table.  If the "anycast" capability is disabled, NA messages with O

   Flag = 0 will not create a Proxy-ND entry (although they will be

   forwarded normally), hence no EVPN advertisement with ARP/ND Extended

   Community will be generated.



[ section 3.2 ]

* Item (f) as currently written would break Enhanced DAD (RFC 7527),
  would it not?
[jorge] when addressing Jean-Michel’s concerns, we changed the text to the following. Hopefully that clears your concern too? Let me know please:

   f.  A PE MUST only reply to ARP-Request and NS messages with the

       format specified in [RFC0826] and [RFC4861] respectively.

       Received ARP-Requests and NS messages with unknown options SHOULD

       be either forwarded (as unicast packets) to the owner of the

       requested IP (assuming the MAC is known in the Proxy-ARP/ND table

       and BD) or discarded.  An option to flood ARP-Requests/NS

       messages with unknown options MAY be used.  The operator should

       assess if flooding those unknown options may be a security risk

       for the EVPN BD.  An administrative option to control this

       behavior ('unicast-forward', 'discard' or 'forward') SHOULD be

       supported.  The 'unicast-forward' option is described in

       Section 3.4.



[ section 3.6 ]

* "Duplicate IP Detection for IPv6 SHOULD be disabled when IPv6
   'anycast' is activated in a given EVI."

  This doesn't seem like the right response to me.  It should be okay to keep
  doing DAD for O=1 addresses regardless of the setting of this 'anycast'
  option, I would have thought.
[jorge] yes, the DAD procedures implemented by the CEs should continue, and this is out of the scope. The sentence refers to the procedure in this section which only affects the PEs. We changed the text to clarify, let me know if it makes sense please:

   The Proxy-ARP/ND function SHOULD support duplicate IP detection as

   per this section so that ARP/ND-spoofing attacks or duplicate IPs due

   to human errors can be detected.  For IPv6 addresses, CEs will

   continue to carry out the DAD procedures as per [RFC4862].  The

   solution described in this section is an additional security

   mechanism carried out by the PEs that guarantees IPv6 address moves

   between PEs are legit and not the result of an attack.



<snip>



   For Proxy-ND, the Duplicate IP Detection described in this section

   SHOULD only monitor IP moves for IP->MACs learned from NA messages

   with O Flag=1.  NA messages with O Flag=0 would not override the ND

   cache entries for an existing IP, and therefore the procedure in this

   section would not detect duplicate IPs.  This Duplicate IP Detection

   for IPv6 SHOULD be disabled when the IPv6 "anycast" capability is

   activated in a given BD.


[ section 5.5 ]

* I think that recommending Reply Sub-Functions discard NS packets of
  unexpected for means, in practice, no new NS option or flag can ever really
  be made to work.  The PE(s) serving the CE(s) that make "new NS"
  solicitations will all need to be upgraded, and it's not immediately clear
  to me that remote PEs wouldn't also need to be upgraded (to support a
  possible "new NA"in response).

  If this is in fact likely to be the operational reality then I think this
  limitation probably needs to be noted explicitly.
[jorge] is this concern addressed with the previous comment about item f)? please let me know.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ section 3.1.1 ]

* "                                   ... If no ARP/ND Extended
   Community is received, the PE will add a configured R Flag/O Flag
   to the entry.  This configured R Flag SHOULD be an administrative
   choice with a default value of 1."

   This reads as though the R flag should be added essentially by default?
   I realize that might seem reasonable on a broadcast domain populated by
   almost entirely by routers but it might cause confusion w.r.t. any
   hosts/servers added to the broadcast domain.  It seems like it might be
   better if the flags were always learned reliably, propagated reliably,
   and never presumed?
[jorge] yes, the intent is that flags for EVPN-learned entries are always learned from the extended community. However the ARP/ND extended community is recent and not supported by RFC7432 PEs, where the proxy-ARP/ND function was already there, so this default configuration provides a backwards compatibility option. I added a sentence to reflect that:

      The configuration of this

      administrative choice provides a backwards compatible option with

      EVPN PEs that follow [RFC7432] but do not support this

      specification.


   I guess a host being mistaken for a router that never actually sends an
   RA doesn't cause any real problems in other nodes' ND tables.  I would
   think, though, that if R were presumed to be 0 then it would force R bit
   learning and propagation to be made to work reliably and be more easily
   detected if it doesn't.
[jorge] I agree, and this document provides the tools for the R flag to be correctly learned and propagated in EVPN. As mentioned, we also wanted to cover the backward compatibility cases for RFC7432 EVPN PEs.


[ section 5.6 ]

* Saying that anycast is not a requirement for IXPs seems like maybe a bit
  presumptuous speaking for all IXPs (maybe someone wants an anycast on-link
  NTP/PTP service?).  Perhaps just say that it's not /typically/ a requirement
  for IXPs?
[jorge] agreed, I added “typically”, thanks.



[[ nits ]]

[ section 1 ]

* "BD: Broadcast Domain" is listed twice.
[jorge] fixed, thanks.


[ section 2.2 ]

* s/go worse/grow worse/, perhaps
[jorge] changed, thanks.


[ section 3.1 ]

* s/to the all/to all/
[jorge] fixed, thanks.