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

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 9 Oct 2020 11:38:23 +0000

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 <[email-masked]>
Date: Wednesday, September 23, 2020 at 6:17 PM
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>
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. 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 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!

---

From: Warren Kumari <[email-masked]>
Date: Sun, 11 Oct 2020 09:38:53 -0400

On Fri, Oct 9, 2020 at 7:38 AM Rabadan, Jorge (Nokia - US/Mountain View) <
[email-masked]> wrote:

> *From: *Warren Kumari via Datatracker <[email-masked]>
> *Date: *Wednesday, September 23, 2020 at 6:17 PM
> *To: *The IESG <[email-masked]>
> *Cc: [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew
> (Nokia - GB) <[email-masked]>, Bocci, Matthew (Nokia - GB) <
> [email-masked]>
> *Subject: *Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06:
> (with DISCUSS and COMMENT)
>
> [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:
>
> 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

> [jorge] we think we addressed their discusses… but obviously they (and
> you) can let us know if it is not the case.
>
>
>
>

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

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 12 Oct 2020 09:10:15 +0000

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 <[email-masked]>
Date: Sunday, October 11, 2020 at 3:39 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Warren,

Thank you for reviewing!

Thx
Jorge

From: Warren Kumari via Datatracker <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 23, 2020 at 6:17 PM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
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

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<http://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 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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Oct 2020 10:37:52 -0400

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) <[email-masked]> wrote:
> On Fri, Oct 9, 2020 at 7:38 AM Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]> wrote:
>
> Hi Warren,
>
>
>
> Thank you for reviewing!
>
>
>
> 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 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

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 12 Oct 2020 14:49:56 +0000

Thank you Warren!
Jorge

Date: Monday, October 12, 2020 at 4:38 PM

W