Last Call Review of draft-ietf-pwe3-packet-pw-
review-ietf-pwe3-packet-pw-secdir-lc-lepinski-2012-03-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 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.