[secdir] secdir review of draft-ietf-trill-directory-framework-05

[Charlie Kaufman <[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 describes a framework for adding a central control mechanism to trill to replace or supplement its autoconfiguring mechanism of dynamically learning the locations of all addresses on the LAN. The specific protocols for supplying and consuming this configuration information will presumably appear in future specs. This sort of configuration control is useful in a datacenter where all connections are carefully configured rather than being plug and play. It is particularly applicable in a "cloud" environment where virtual machines are moved between physical machines by some sort of Virtual Machine Management System that will also assign addresses and place them.

The Security Considerations section of this document is very bland, noting that reachability depends on the correct delivery of information and stating that there may be security considerations specific to particular directory assistance mechanisms. The feature is designed to improve performance rather than security. I believe this seriously understates the security advantages that are possible if a central control mechanism replaces the autoconfiguration mechanism. In particular, the main protection/isolation mechanisms available today on a LAN concern partitioning by VLAN. Within a VLAN, any node can impersonate any other and can arrange to receive traffic addressed to another node. This can be prevented if the network learns the addresses belonging to each physical connection port not from looking at what the node transmits but rather from a central controller. A node cannot receive traffic addressed to someone else simply by sending a packet from that address or responding to an ARP searching for an IP address. In fact, such packets can be blocked by the ingress Rbridge. So control is much more fine-grained than with VLANs. The network guarantees the authenticity of the source address of each incoming packet.

The directory framework could be made more useful in serving this security functionality if its configuration included in each entry not simply the IP address, MAC/VLAN, and list of attached Rbridges, but also a port identifier for each attached RBridge. Egress RBridges could use this information to impose more precise limits. If this information is not in the database, a central controlling mechanism would need a separate protocol and communications path to communicate this information to the Egress RBridges. The current spec allows such information to be included in the directory, but does not require it.

Nits:

Page 4, bullet 4: "more common occurrence" -> "more frequent occurrence"