Subject: [secdir] SECDIR review of draft-ietf- bess-evpn-usage-07

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Feb 2018 13:16:26 -0500

SECDIR review of draft-ietf- bess-evpn-usage-07

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.These comments were written with the intent of improving security 
requirements and considerations in IETF drafts.Comments not addressed in 
last call may be included in AD reviews during the IESG review.Document 
editors and WG chairs should treat these comments just like any other 
last call comments.

This document describes the applicability of an Ethernet VPN (EVPN) 
enabled via BGP MPLS, in what the authors say is a “fairly common 
deployment scenario.” It intended status is INFORMATIONAL. The document 
complements RFC 7432, which already defines BGP MPLS-based EVPN technology.

Section 2 (Terminology)

The acronym PE (provider edge?) is used here, but not defined.

Section 3

This section describes the common deployment scenario that is the focus 
of this document. The scenario involves three customer sites; one 
requires multi-homing to two provider access points, while the other two 
sites are single-homed. The goal is to make all three sites appear to be 
on the same Ethernet.

Section 3.2 describes rationale (motivation) for using this technology 
(vs. VPLS) to satisfy the service and redundancy requirements. That’s 
not exactly an “applicability” discussion, but …

Section 4 describes the provisioning model for the chosen deployment 
scenario. Section 5 describes what route update processing capabilities 
are needs by the provider equipment, in support of this deployment 
scenario. Section 6 is rather long; it describes the EVPN initialization 
procedures in detail for MAC-based forwarding. Section 7 provides a 
similar description for MPLS-based forwarding. Section 8 compares the 
two approaches and Section 9 discuss traffic flow optimization (to avoid 
flooding traffic to all sites when such flooding is not needed).

Section 10 (Security Considerations) consists of only one sentence, 
which refers to the corresponding discussion in RFC 7432. Additional 
text should be provided here to explain why this document does not add 
any new security considerations. Presumably the rationale is that the 
provisioning model and initialization procedures described here are a 
subset of the more general discussion in 7432 and thus no new security 
concerns arise as a result of this more detailed information. I am not 
in a position to judge whether that potential rationale is true.

I reviewed the Security Considerations section of RFC 7432. It contains 
about 1.5 pages of text. The first paragraph there cites security 
considerations text in RFCs 4761, 4762, and 4364 and the text there is 
generally well-written. However, there is a significant omission, one 
that should have been noted in the SECDIR review of that document. 
Specifically, 7432 cites NONE of the BGP security RFCs produced by the 
SIDR WG (e.g., RFCs 6480-93 et al), even though they preceded 
publication of that RFC. Since those documents represented the latest 
proposals for improving BGP security at the time, they ought to have 
been cited and a very brief discussion of their relevance to EVPN BGP 
MPLS deployments. I suggest that this document rectify this omission, 
i.e., cite several of the BGP secure origin authentication RFCs, and the 
recent BGPSec RFCs (8205-11), and note the relevance of those standards 
to EVPN BGP MPLS deployments.

Comments on Grammar/Typos

There are a several places in the text where sentences are 
un-grammatical. For example:

“… irrespectively of the number of affected services… “

->

“…irrespective of the number of affected services …”

“ … we can use ingress replication for on EVI100 …”

->

“…we can use ingress replication for EVI100 and …”

“In regards to service interfaces …”

->

“With regard to service interfaces …”

“…(and even suppress) the ARP-flooding.”

->

“…(and even suppress) ARP-flooding.”

“…certain parameters which are not service-specific…”

->

“certain parameters that are not service-specific..”

“In our use-case, besides the above parameters, the same LACP

parameters will be configured in PE1 and PE2 for the ESI, so that CE2

can send different flows to PE1 and PE2 for the same CE-VID as though

they were forming a single system from the CE2 perspective.”

Sentence too long

“E.g.: PE1 and PE2 CE-VID binding …”

->

“For example, PE1 and PE2 CE-VID binding …”

“PE3 is only required to export MAC …”

->

“PE3 is required to export only MAC …”

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 2 Feb 2018 16:22:01 -0500

On February 2, 2018 at 1:16:28 PM, Stephen Kent ([email-masked]) wrote:

Steve:

Hi!  How are you?

...

Section 10 (Security Considerations) consists of only one sentence, which
refers to the corresponding discussion in RFC 7432. Additional text should
be provided here to explain why this document does not add any new security
considerations. Presumably the rationale is that the provisioning model and
initialization procedures described here are a subset of the more general
discussion in 7432 and thus no new security concerns arise as a result of
this more detailed information. I am not in a position to judge whether
that potential rationale is true.

Fair enough.

I reviewed the Security Considerations section of RFC 7432. It contains
about 1.5 pages of text. The first paragraph there cites security
considerations text in RFCs 4761, 4762, and 4364 and the text there is
generally well-written. However, there is a significant omission, one that
should have been noted in the SECDIR review of that document. Specifically,
7432 cites NONE of the BGP security RFCs produced by the SIDR WG (e.g.,
RFCs 6480-93 et al), even though they preceded publication of that RFC.
Since those documents represented the latest proposals for improving BGP
security at the time, they ought to have been cited and a very brief
discussion of their relevance to EVPN BGP MPLS deployments. I suggest that
this document rectify this omission, i.e., cite several of the BGP secure
origin authentication RFCs, and the recent BGPSec RFCs (8205-11), and note
the relevance of those standards to EVPN BGP MPLS deployments.

The work from sidr doesn’t directly apply to EVPN simply because the ROAs
and BGPSec have been specified only for IPv4/IPv6 and not for the Address
Family used by EVPN.

Maybe a statement like that is what you’re looking for — but I don’t think
it is appropriate to go any further in this document.
Thanks!

Alvaro.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Feb 2018 17:06:48 -0500

Alvaro,
> On February 2, 2018 at 1:16:28 PM, Stephen Kent ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
> Steve:
>
> Hi!  How are you?
I'm well. Thanks for asking.
>> text should be provided here to explain why this document does not 
>> add any new security considerations. Presumably the rationale is that 
>> the provisioning model and initialization procedures described here 
>> are a subset of the more general discussion in 7432 and thus no new 
>> security concerns arise as a result of this more detailed 
>> information. I am not in a position to judge whether that potential 
>> rationale is true.
>>
> Fair enough.
>
Good.
>>
>> I reviewed the Security Considerations section of RFC 7432. It 
>> contains about 1.5 pages of text. The first paragraph there cites 
>> security considerations text in RFCs 4761, 4762, and 4364 and the 
>> text there is generally well-written. However, there is a significant 
>> omission, one that should have been noted in the SECDIR review of 
>> that document. Specifically, 7432 cites NONE of the BGP security RFCs 
>> produced by the SIDR WG (e.g., RFCs 6480-93 et al), even though they 
>> preceded publication of that RFC. Since those documents represented 
>> the latest proposals for improving BGP security at the time, they 
>> ought to have been cited and a very brief discussion of their 
>> relevance to EVPN BGP MPLS deployments. I suggest that this document 
>> rectify this omission, i.e., cite several of the BGP secure origin 
>> authentication RFCs, and the recent BGPSec RFCs (8205-11), and note 
> The work from sidr doesn’t directly apply to EVPN simply because the 
> ROAs and BGPSec have been specified only for IPv4/IPv6 and not for the 
> Address Family used by EVPN.
>
> Maybe a statement like that is what you’re looking for — but I don’t 
> think it is appropriate to go any further in this document.
>
A statement explaining why AS origin authentication and BGPSec are not 
relevant would address my concerns.

Thanks,

Stevce

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 8 Feb 2018 14:03:04 +0000

Kent,

Thank you very much for your comments.
I have fixed the grammar errors, added PE to the terminology section and added this to the security section:

“The procedures described in this document are a subset of the procedures in [RFC7432] and thus no new security concerns arise.”

Alvaro, I assume we don’t need to post a new version and it can wait till the next reviews, right?

Thank you.
Jorge

From: Stephen Kent <[email-masked]>
Date: Friday, February 2, 2018 at 11:06 PM
To: Alvaro Retana <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Palislamovic, Senad (Nokia - US)" <[email-masked]>
Subject: Re: SECDIR review of draft-ietf- bess-evpn-usage-07

Alvaro,
On February 2, 2018 at 1:16:28 PM, Stephen Kent ([email-masked]<mailto:[email-masked]>) wrote:

Steve:

Hi!  How are you?

...
Section 10 (Security Considerations) consists of only one sentence, which refers to the corresponding discussion in RFC 7432. Additional text should be provided here to explain why this document does not add any new security considerations. Presumably the rationale is that the provisioning model and initialization procedures described here are a subset of the more general discussion in 7432 and thus no new security concerns arise as a result of this more detailed information. I am not in a position to judge whether that potential rationale is true.

Fair enough.
Good.

I reviewed the Security Considerations section of RFC 7432. It contains about 1.5 pages of text. The first paragraph there cites security considerations text in RFCs 4761, 4762, and 4364 and the text there is generally well-written. However, there is a significant omission, one that should have been noted in the SECDIR review of that document. Specifically, 7432 cites NONE of the BGP security RFCs produced by the SIDR WG (e.g., RFCs 6480-93 et al), even though they preceded publication of that RFC. Since those documents represented the latest proposals for improving BGP security at the time, they ought to have been cited and a very brief discussion of their relevance to EVPN BGP MPLS deployments. I suggest that this document rectify this omission, i.e., cite several of the BGP secure origin authentication RFCs, and the recent BGPSec RFCs (8205-11), and note the relevance of those standards to EVPN BGP MPLS deployments.

The work from sidr doesn’t directly apply to EVPN simply because the ROAs and BGPSec have been specified only for IPv4/IPv6 and not for the Address Family used by EVPN.

Maybe a statement like that is what you’re looking for — but I don’t think it is appropriate to go any further in this document.
A statement explaining why AS origin authentication and BGPSec are not relevant would address my concerns.

Thanks,

Stevce

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Feb 2018 09:32:37 -0500

Jorge,

> Kent,
Steve is my first name.
> I have fixed the grammar errors, added PE to the terminology section
>
great
>
> and added this to the security section:
>
> “The procedures described in this document are a subset of the 
> procedures in [RFC7432] and thus no new security concerns arise.”
>
fine.

How about adding a couple of sentences after that, noting why the SIDR 
BGP origin authentication and route security RFCs are not relevant, e.g.,

"The standards produced by the SIDR WG, which address secure route 
origin authentication (e.g., RFCs 6480-93) and route advertisement 
security (e.g., RFCs 8205-11) do not apply here. This is because EVPNs  
rely on BGP to convey information about Ethernet address space, not 
IPv4/v6 address space."

Steve

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 8 Feb 2018 19:15:46 +0000

Hi Steve,

Please see in-line.
Thank you!
Jorge

From: Stephen Kent <[email-masked]>
Date: Thursday, February 8, 2018 at 3:32 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, Alvaro Retana <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Palislamovic, Senad (Nokia - US)" <[email-masked]>
Subject: Re: [secdir] SECDIR review of draft-ietf- bess-evpn-usage-07

Jorge,
Kent,
Steve is my first name.
[JORGE] Sorry about that! I should have paid more attention.

fine.

How about adding a couple of sentences after that, noting why the SIDR BGP origin authentication and route security RFCs are not relevant, e.g.,

"The standards produced by the SIDR WG, which address secure route origin authentication (e.g., RFCs 6480-93) and route advertisement security (e.g., RFCs 8205-11) do not apply here. This is because EVPNs  rely on BGP to convey information about Ethernet address space, not IPv4/v6 address space."
[JORGE] hmm... how about this instead:
“The standards produced by the SIDR WG, which address secure route origin authentication (e.g., RFCs 6480-93) and route advertisement security (e.g., RFCs 8205-11) do not apply to the EVPN family, hence they are not relevant to [RFC7432] or this document.”

The reason is because EVPN conveys Ethernet address space but also some other information.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Feb 2018 05:56:52 -0500

Jorge,

> “The standards produced by the SIDR WG, which address secure route 
> security (e.g., RFCs 8205-11) do not apply to the EVPN family, hence 
> they are not relevant to [RFC7432] or this document.”
>
First, I'm not sure if the sentence immediately above is intended to be 
part of the text, or if it is a comment to me.  I'm, assuming the 
latter, in which case I think more info would help the reader to 
understand why those RFCs are not applicable. Saying that the RFCs "do 
not apply to the EVPN family" does not seem clear enough, although I 
agree that noting RFC 7432 is a good idea.. How about:

“The standards produced by the SIDR WG address secure route origin 
authentication (e.g., RFCs 6480-93) and route advertisement security 
(e.g., RFCs 8205-11). They protect the integrity and authenticity of IP 
address advertisements and ASN/IP prefix bindings. This document, and 
[RFC7432], use BGP to convey other info, e.g., MAC addresses, and thus 
the protections offered by the SIDR WG RFCs are not applicable in this 
context."

Steve

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 9 Feb 2018 11:45:05 +0000

Steve,

Your proposal looks very good to me.
I’ll add it to the document.

Thank you!
Jorge

From: Stephen Kent <[email-masked]>
Date: Friday, February 9, 2018 at 11:57 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, Alvaro Retana <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Palislamovic, Senad (Nokia - US)" <[email-masked]>
Subject: Re: [secdir] SECDIR review of draft-ietf- bess-evpn-usage-07

Jorge,

The reason is because EVPN conveys Ethernet address space but also some other information.
First, I'm not sure if the sentence immediately above is intended to be part of the text, or if it is a comment to me.  I'm, assuming the latter, in which case I think more info would help the reader to understand why those RFCs are not applicable. Saying that the RFCs "do not apply to the EVPN family" does not seem clear enough, although I agree that noting RFC 7432 is a good idea.. How about:

“The standards produced by the SIDR WG address secure route origin authentication (e.g., RFCs 6480-93) and route advertisement security (e.g., RFCs 8205-11). They protect the integrity and authenticity of IP address advertisements and ASN/IP prefix bindings. This document, and  [RFC7432], use BGP to convey other info, e.g., MAC addresses, and thus the protections offered by the SIDR WG RFCs are not applicable in this context."

Steve