Last Call Review of draft-ietf-trill-o-pw-03

Request Review of draft-ietf-trill-o-pw
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-12-23
Requested 2013-12-12
Authors Lucy Yong, Donald Eastlake, Sam Aldrin, Jon Hudson
Draft last updated 2013-12-19
Completed reviews Genart Last Call review of -03 by Christer Holmberg (diff)
Genart Telechat review of -04 by Christer Holmberg (diff)
Secdir Last Call review of -03 by Yaron Sheffer (diff)
Opsdir Last Call review of -03 by Tina Tsou (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Review review-ietf-trill-o-pw-03-secdir-lc-sheffer-2013-12-19
Reviewed rev. 03 (document currently at 06)
Review result Has Issues
Review completed: 2013-12-19


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.


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).


- 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 


- 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.