Last Call Review of draft-ietf-trill-directory-framework-05
review-ietf-trill-directory-framework-05-secdir-lc-kaufman-2013-07-12-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 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"