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 taking the time to review the changes again.

We just posted rev 13 trying to address your latest comments.

A diff from the previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-proxy-arp-nd-13

Please see in-line below with [jorge2].

Thx
Jorge

From: Erik Kline <[e-mail]>
Date: Wednesday, March 31, 2021 at 1:56 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: Erik Kline's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)


On Wed, Mar 17, 2021 at 12:31 PM Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
Date: Thursday, January 21, 2021 at 8:21 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>, Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[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.

[ek] I am not clear on how "RFC4861 format" addresses the issue of options.  I have the feeling rather that you mean a specific list of ND options.

Note also that since RFC 7527 a node can modify its DAD messages (NSes) to include a Nonce option to detect looped back DAD packets.  (This is an example of how these messages have changed over time.)

(more in the 3.2-f section below)


[jorge2] I see your point. I changed the text, please see below about (f) too.



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

[ek] I think I had assumed the devices did something like configure an IPv6 link-local address in the BD.  But it's purely "transparent" then there's no source address from which to originate MLD messages and so it doesn't make any sense.  Thanks.
[jorge2] thanks.


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

[ek] So you're saying that O=0 messages get forwarded but not learned, is that correct?  If so, I think that's fine.  (The text you include below reads this way to me.)
[jorge2] precisely, thanks!



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

[ek] If O=0 messages are forwarded normally regardless of "learning", that seems fine.  Thanks.
[jorge2] that’s correct, thanks.


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

[ek] I think having the option to discard ND packets with unknown options is highly likely to create some difficulty.  I understand the intent may be to save unwanted multicast traffic, and perhaps address some other concerns.  But, as I understand it, the first CE to add a Nonce to their NS messages during DAD would result in the packets being dropped and the device determining that there was no duplicate address conflict, potentially leading directly to duplicate addresses in the BD.
[jorge2] I see your point. The reason why we wanted a config option to discard was based on the security requirements that we got from the IXP operator that co-authors the draft. I changed the text with the discard being optional, and adding a warning for the operator. Let me know if this clears your concern please:

   f.  For Proxy-ARP, a PE MUST only reply to ARP-Request with the
       format specified in [RFC0826].  For Proxy-ND, a PE MUST reply to
       NS messages with the format and options specified in [RFC4861],
       and MAY reply to NS messages containing other options.  Received
       NS messages with unknown options SHOULD be forwarded (as unicast
       packets) to the owner of the requested IP (assuming the MAC is
       known in the Proxy-ARP/ND table and BD).  An administrative
       choice to control the behavior for received NS messages with
       unknown options ('unicast-forward', 'discard' or 'forward') MAY
       be supported.  The 'unicast-forward' option is described in
       Section 3.4.  If 'discard' is available, the operator should
       assess if flooding NS unknown options may be a security risk for
       the EVPN BD (and is so, enable 'discard'), or if, on the
       contrary, not forwarding NS unknown options may disrupt
       connectivity.


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

[ek] I suppose this is fine.  I'll have to reread the text in context to be completely sure, but thanks.
[jorge2] sounds good, thanks.


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

[ek] I still think it might lead to increasing the likelihood of duplicate address formation.
[jorge2] sure. The new text changes the ‘discard’ as an option and adds the warning (see the new ‘f’ above). Let me know if that is okay.


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

[ek] Ah, I see: the newer implementations would use the info as given in the na-flags draft.  Makes sense.
[jorge2] thanks.

   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.

[ek] Ack.
[jorge2] thanks!