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 specifies how multiple networks running TRILL can be connected using pseudowires. Summary Coming from the L3 security community, I am very worried by this document and its predecessors. It seems to me that we are creating the infrastructure for larger and larger L2 networks, often spanning large geographical distances, but the security mechanisms are not keeping up with this wider scope. I am not familiar with either the TRILL or PWE3 standards. Nor am I familiar with their real-life implementations. If secure deployments are common, I will be happy to be proven wrong (though I would expect such best practices to be documented and standardized). Details - This document copies the following text from the analogous PPP transport RFC: "not all implementations need to include specific security mechanisms at the pseudowire layer, for example if they are designed to be deployed only in cases where the networking environment is trusted or where other layers provide adequate security. A complete enumeration of possible deployment scenarios and associated threats and options is not possible and is outside the scope of this document.' I beg to differ. I think Security Considerations should recommend such solutions, and discuss the specific issues that come up when deploying them in this context: how should endpoints be authenticated? What protocol information should be protected? How do TRILL identities map to identities authenticated by the selected security protocol etc. In general, although not ALL implementations need security mechanisms, I assume an overwhelming majority of them does. - Moreover, text such as the following (RFC 6325) strongly hints that this traffic will be passing under the radar of many security devices: "TRILL ignorant devices with firewall features that cannot be detected by RBridges as end stations will generally not be able to inspect the content of such frames for security checking purposes." - The Security Considerations recommend end-to-end security as a replacement for link-level security. Though attractive from a security point of view, such solutions (security protocols between end hosts) are far from ubiquitous in large networks and so cannot replace link-level mechanisms. - This document is analogous to RFC 6361, which uses PPP to bridge the TRILL islands. RFC 6361 does in fact discuss specific security mechanisms (yes, one wonders about CHAP being recommended in a 2011 document). The current document does not do so. Thanks, Yaron