Re: [secdir] SecDir review of draft-ietf-l2vpn-evpn-req-05

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Tina,

Thanks for your review. I have incorporated all your comments. Please
refer inline for details on resolutions ...

On 11/27/13 6:32 PM, "Tina TSOU" <[e-mail]> wrote:

>Dear all,
>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 primarily for the benefit of the security
>area directors. Document editors and WG chairs should treat these
>comments just like any other last call comments.
>
>This document specify the requirement for an Ethernet VPN (EVPN)
>solution, to address the issues mentioned in this draft.
>
>Some comments are below.
>
>1. In Section 4.2, it says:
> "The solution MUST also be able to leverage
> work in the MPLS WG that is in progress to improve the load balancing
> capabilities of the network based on entropy labels [RFC6790]."
>
> Since this work is already published as RFC, the sentence should be
>rewritten as: 
> "The solution MUST also be able to leverage the MPLS load balancing
> capabilities based on entropy labels [RFC6790]."

Agreed.

> 
>
>2. In Section 4.2, it says:
> "For example consider a scenario in which CE1 is multi-homed to PE1
> and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active
> mode. Furthermore, consider that there exist three ECMPs between any
> of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can
> be forwarded on twelve different paths over MPLS/IP core as follow:
> CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and
> PE2 have three ECMPs to PE3 and PE4 for the total of twelve paths.
> Finally, when traffic arrives at PE3 and PE4, it gets forwarded to
> CE2 over the Ethernet channel (aka link bundle)."
>
> It seems "ECMP", "ECMP path" and "path" are messed up in this paragraph.
>To make it straight, the following is suggested:
> "For example consider a scenario in which CE1 is multi-homed to PE1
> and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active
> mode. Furthermore, consider that there exist three ECMP paths between
>any 
> of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can
> be forwarded on twelve different paths over MPLS/IP core as follow:
> CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and
> PE2 have three paths to PE3 and PE4 for the total of twelve paths.
> Finally, when traffic arrives at PE3 and PE4, it gets forwarded to
> CE2 over the Ethernet channel (aka link bundle)."

Agreed.

> 
>
>3. In Section 12 "Security Considerations", it says:
> "...The requirement is to introduce no
> new vulnerabilities beyond those of [RFC4761] and [RFC4762] when MAC
> learning is performed in data-plane and beyond that of [RFC4364] when
> MAC learning is performed in control plane."
>
>Though BGP is used similarly in E-VPN, some new vulnerabilities will
>inevitably be introduced, such as MAC forgery in BGP, and how to protect
>against individual MACs may pose a challenge.
>
>4.  Section 12 "Security Considerations"
>It is very brief. It does not mention when using multi-homing.


I have updated the section 12 as follow:

Any protocol extensions developed for the EVPN solution shall include the
appropriate security analysis. Besides the security requirements covered
in [RFC4761] and [RFC4762] when MAC learning is performed in data-plane
and in [RFC4364] when MAC learning is performed in control plane, the
following additional requirements need to be covered.

(R13) A solution MUST be capable of detecting and properly handling a
situation where the same MAC address appears behind two different Ethernet
Segment (whether inadvertently or intentionally).

(R14) A solution MUST be capable of associating a MAC address to a
specific Ethernet Segment such that MAC mobility for this kind of MAC
addresses are disallowed.




Regards,
Ali 



>
>
>Thank you,
>Tina