Skip to main content

Last Call Review of draft-ietf-mpls-egress-protection-framework-05
review-ietf-mpls-egress-protection-framework-05-secdir-lc-huitema-2019-06-17-00

Request Review of draft-ietf-mpls-egress-protection-framework
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-06-17
Requested 2019-06-03
Authors Yimin Shen , Jeyananth Minto Jeganathan , Bruno Decraene , Hannes Gredler , Carsten Michel , Huaimo Chen
I-D last updated 2019-06-17
Completed reviews Rtgdir Last Call review of -03 by Sasha Vainshtein (diff)
Secdir Last Call review of -05 by Christian Huitema (diff)
Genart Last Call review of -05 by Peter E. Yee (diff)
Opsdir Last Call review of -05 by Scott O. Bradner (diff)
Secdir Telechat review of -06 by Christian Huitema (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-mpls-egress-protection-framework by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/hDitSBYNHXPaz07lzxHO79oXa1w
Reviewed revision 05 (document currently at 07)
Result Has nits
Completed 2019-06-17
review-ietf-mpls-egress-protection-framework-05-secdir-lc-huitema-2019-06-17-00
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.