Skip to main content

Last Call Review of draft-ietf-pals-mpls-tp-dual-homing-coordination-05
review-ietf-pals-mpls-tp-dual-homing-coordination-05-secdir-lc-weis-2017-02-16-00

Request Review of draft-ietf-pals-mpls-tp-dual-homing-coordination
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-02-13
Requested 2017-01-30
Authors Weiqiang Cheng , Lei Wang , Han Li , Jie Dong , Alessandro D'Alessandro
I-D last updated 2017-02-16
Completed reviews Opsdir Last Call review of -05 by Menachem Dodge (diff)
Secdir Last Call review of -05 by Brian Weis (diff)
Genart Last Call review of -05 by Jouni Korhonen (diff)
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-ietf-pals-mpls-tp-dual-homing-coordination by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 06)
Result Has issues
Completed 2017-02-16
review-ietf-pals-mpls-tp-dual-homing-coordination-05-secdir-lc-weis-2017-02-16-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.

This document concerns a Dual-Node Interconnection (DNI) message, which is
carried over an already defined protocol ("G-ACh”) placed between a pair of
MPLS-TP Provider Edge (PE) device. In this case, “dual-homed” means that both
PE routers are connected to a Customer Edge (CE) device. The two PE devices use
the DNI to signal which of the Pseudowires (PWs) leading from the PE devices
into the provider network currently is carrying the CE traffic.

The security considerations section in this document points to the security
considerations for G-ACh (RFC 5586), which in turn points to RFC 4485. The
security considerations for RFC 4485 basically says any application using the
channel should fully consider the resultant security issues and provide
mechanisms to stop attacks. I don’t actually see any such analysis considering
the security issues to the DNI  in this document, and I think that it would be
good say a little something about how the DNI could be mis-used by an attacker.
Because of this  I consider this document to be Ready with Issues. Below I
suggest what might be the analysis and what could be added to the the security
considerations.

The data carried in the DNI contains control data, which if an attacker
falsified or changed then the two PE devices might not agree on which which PE
should be sued  to deliver the CE data, and this could be used as a denial of
service attack against the CE. If the G-ACh protocol ever crosses an untrusted
link where an attacker could make this attack then it would be a good idea if
the G-ACh protocol was integrity protected so that the two PEs have confidence
that the message arrived unmodified. For example, I imagine that if the PE
devices were in different data centers, then probably the G-ACh protocol is
vulnerable somewhere in the network — even if it’s all the same provider
network. It would be good to acknowledge this in the document by saying that if
the G-ACh protocol goes across an untrusted link that the DNI messages should
be integrity protected. I don’t see any TLVs defined for the G-ACh that would
provide integrity, and I’m not familiar enough with MPLS-TE networks to know
how that could be done, but a hint to implementors saying how this could be
done would also be a good idea.

Brian