[mpls] Secdir last call review of draft-ietf-mpls-egress-protection-framework-05

Christian Huitema via Datatracker <noreply@ietf.org> Tue, 18 June 2019 01:39 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 982B3120179; Mon, 17 Jun 2019 18:39:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-mpls-egress-protection-framework.all@ietf.org, ietf@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Christian Huitema <huitema@huitema.net>
Message-ID: <156082197755.22389.14803953372788869090@ietfa.amsl.com>
Date: Mon, 17 Jun 2019 18:39:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/EeEmoSV2xAtjNh2OpsQT-3kqJvs>
Subject: [mpls] Secdir last call review of draft-ietf-mpls-egress-protection-framework-05
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2019 01:39:38 -0000

Reviewer: Christian Huitema
Review result: Has Nits

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.

I think the document is almost ready, although I would like some considerations
of a potential attack through the customer equipment.

I reviewed draft-ietf-mpls-egress-protection-framework-05, MPLS Egress Protection Framework.
The document specifies a framework for implementing protection of an MPLS tunnel against
failure of the egress router or the egress link. 

The implementation of the framework relies on the control functions of the MPLS network,
and the security considerations correctly state that the security of the implementation relies on
the security of these protocols. The security consideration also point out the need for
special establishment of trust if the nodes involved are not under the same administrative
authority.

These general security considerations are correct, but I am concerned that the egress
links between the MPLS network routers and the customer could also become a point of
attack. Attackers that gain control of a customer's equipment might use it to simulate
link failures and trigger the backup mechanism. They could do so in a coordinated fashion
across a large number of customer equipments, to try overload the control plane or try
create cascading effects in the network.

It may well be that in the absence of the local backup mechanism, the attackers could mount
the same type of attack and trigger an other type of control plane activity. The defenses
against that might also defend against the attack listed in the previous paragraph. But
it might be good to state it.