Last Call Review of draft-ietf-trill-o-pw-03
review-ietf-trill-o-pw-03-secdir-lc-sheffer-2013-12-19-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 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