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 considers the case of two MPLS Label Switching Routers (LSRs) that are connected over an arbitrary packet-switched network (i.e., an IP or MPLS network). This document provides a mechanism (i.e., a pseudowire) to simulate a direct data-link (in particular, an Ethernet link, as Ethernet is the encapsulation mechanism specified) between the two MPLS LSRs. This pseudowire provides an interface to exchange IP packets (and indeed, multiplex IP packets associated with a variety of protocols) between the two MPLS LSRs in a manner that is completely isolated from the MPLS traffic that they exchange. For example, the document claims that the pseudowire could be used to exchange packets for adjacency formation, control, routing, label exchange, management and monitoring purposes.

The security considerations section of the document claims that this use of pseudowires creates no new security considerations that are not covered in the pseudowire architecture (RFC 3985) or the specification for creating/maintaining pseudowires using LDP (RFC 4447). I would generally agree with the authors, that this use of pseudowires introduces no fundamentally new security considerations. However, I think it would be valuable for the authors add a small amount of additional cautionary text to the security considerations section (and I think it would be perfectly reasonable to copy text from, for example, the beginning of the RFC 3985 security considerations).

The key issue is that Pseudowires do not provide any integrity or authenticity guarantees and in particular security assumptions that are reasonable when using physical Ethernet links are no longer reasonable when you are using a virtual pseudowire traversing an arbitrary packet-switched network. The motivating examples in this document discuss routing protocol control traffic and network management traffic as things you might send over a packet pseudowire. When you send this type of control or management traffic over a physical Ethernet link one might reasonably choose not to invoke all integrity and authenticity mechanisms available in these protocols, but when using a pseudowire the use of such intregrity and authenticity mechanisms is much more important to the correct operation of one's network. All of this is said quite nicely in RFC 3985, but I believe adding a bit of cautionary text to the security considerations section of this document (in addition to the reference to RFC 3985) could be quite helpful to the reader of this document.