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