[secdir] SecDir review of draft-ietf-trill-o-pw-03

[Yaron Sheffer <[e-mail]>]

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