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

[Erik Kline <[e-mail]>]

On Wed, Mar 17, 2021 at 12:31 PM Rabadan, Jorge (Nokia - US/Mountain View) <
[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]>
> *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.*
>

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


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


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



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


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


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


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


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

   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.