Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS and COMMENT)

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

Thank you Warren!
Jorge

From: Warren Kumari <[e-mail]>
Date: Monday, October 12, 2020 at 4:38 PM
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: Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS and COMMENT)
Hi there,

Just a quick note to say thank you for addressing my concerns; I
appreciate your adding text even though the concern isn't (strictly)
within this document.

I've just cleared my DISCUSS.

W



On Mon, Oct 12, 2020 at 5:10 AM Rabadan, Jorge (Nokia - US/Mountain
View) <[e-mail]> wrote:
>
> Hi Warren,
>
>
>
> OK, thanks for explaining.
>
>
>
> Added the following text in rev 08. Let me know if it satisfies your concern. I understand it is a general concern about proxy-arp/nd in EVPN networks and not about this specific document.
>
>
>
>
>
> The same security considerations described in [RFC7432] apply to this
>
>    document.  In general, it is worth noting that the use of Proxy ARP/
>
>    ND in EVPN BDs may add some security risks.  Attackers can make use
>
>    of ARP/ND messages to create state in all the PEs attached to the
>
>    same BD as the attacker and exhaust resources in those PEs.
>
>    Therefore, additional security mechanisms may be needed.  Some
>
>    examples of such additional security mechanisms are e.g., limit the
>
>    number of Proxy ARP/ND entries per-BD/per-port, or monitor closely
>
>    the rate at which hosts create dynamic Proxy-ARP/ND entries.
>
>
>
>
>
> Thank you!
>
> Jorge
>
>
>
> From: Warren Kumari <[e-mail]>
> Date: Sunday, October 11, 2020 at 3:39 PM
> 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: Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS and COMMENT)
>
>
>
>
>
> On Fri, Oct 9, 2020 at 7:38 AM Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]> wrote:
>
> Hi Warren,
>
>
>
> Thank you for reviewing!
>
>
>
> Please see some comments in-line and let us know if we still need to add information to the security section.
>
>
>
> Thx
>
> Jorge
>
>
>
> From: Warren Kumari via Datatracker <[e-mail]>
> Date: Wednesday, September 23, 2020 at 6:17 PM
> 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: Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS and COMMENT)
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-bess-evpn-na-flags-06: 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-na-flags/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Be ye not afraid! This DISCUSS should be fairly trivial to address...
>
>
>
> This allows for more information to be carried with MAC/IP Advertisements. It
> seems to me that this gives a DoS-style attacker more opportunities to exhaust
> state on routers - I could sit on a wire and create lots of ARP/ND states (make
> up new IP and MAC combinations), causing this to be propagated and burning
> memory / state / etc.
>
> This is somewhat discussed in RFC 7432, but the technique in this document
> seems like it makes this issue somewhat worse - a single sentence in the
> Security Considerations noting it would satisfy me (as would an explanation
> that I'm mistaken :-)).
>
> --------------------
>
> [jorge] we’re happy to add any other explanations in the security section, however I thought your concern could have been addressed by this existing sentence:
>
>    “In addition, this document adds pieces of information that impact on
>
>    the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND
>
>    tables, and therefore the resolution protocols for IPv4 and IPv6
>
>    addresses.”
>
>
>
> Also, can you please clarify what you mean by this?:
>
> “this gives a DoS-style attacker more opportunities to exhaust
> state on routers - I could sit on a wire and create lots of ARP/ND states (make
> up new IP and MAC combinations), causing this to be propagated and burning
> memory / state / etc.”
>
> Note that the new flags come in an extended community, which is not part of the route key, hence receiving multiple combinations of flags with the same IP->MAC information will not create new state, but update the existing one. As an example, if a PE receives IP1->MAC1(R=1,I=0) and later IP1->MAC1(R=0,I=1), the PE will not create additional state but will update the entry with the latest information.
>
>
>
> Yes, multiple combinations of flags with the same IP->MAC will just result in updates, but let's pretend I'm sitting on a network at work, my IP address is 172.16.0.10/12 and my MAC address is 00:11:22:33:44:55. I've decided I want the rest of the day off to go watch the cricket match, and so it would be *just great* if the network were to go down....
>
>
>
> I generate an ARP request for 172.16.0.11, and then immediately reply to my own ARP with a MAC address of 00:11:22:33:44:56. I then generate an ARP request for 172.16.0.12, and immediately reply to my own ARP with a MAC address of 00:11:22:33:44:57, etc. (This is a trivial ARP flooding attack - https://www.trendmicro.com/vinfo/us/threat-encyclopedia/archive/security-advisories/arp%20flooding%20attack. Variations include using the same IP and different MACs, or the same MAC and different IPs.)
>
>
>
> On a "normal" (non-VPN) system, this is only slightly painful (everything is local, you can purge old IP->MAC entries easily, and the worst case failure is the single router that you are behind). In a (L2-style) VPN this needs to be propagated, and each new ARP entry requires a new announcement, all devices need to do $something, and the failure domain is all of the devices participating.
>
>
>
>
>
> Let me know if I’m missing your point please, and if so it would be great if you can suggest some text for the security section.
>
>
>
> I don't really have any suggested text, other than perhaps a warning that implementations should pay attention to this. Actually I'm not sure what the least painful response is...
>
>
>
> W
>
>
>
>
>
> --------------------
>
>
>
>
>
> I also support EK & Rob's DISCUSSes
>
> [jorge] we think we addressed their discusses… but obviously they (and you) can let us know if it is not the case.
>
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Other than my DISUCSSes, I found this document to be well written and easy to
> understand - thank you for writing it...
>
> [jorge] thank you for your kind words!
>
>
>
>
>
>
> --
>
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf