Last Call Review of draft-ietf-trill-directory-assist-mechanisms-11
review-ietf-trill-directory-assist-mechanisms-11-secdir-lc-franke-2017-01-18-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.

I believe this document is READY WITH NITS. I'm satisfied with its
normative content but the Security Considerations section could use
a bit of elaboration.

I had never heard of TRILL prior to being assigned this review and
the tree of normative references is a bit daunting, so these comments
will necessarily be based only on an extremely high-level view of
the system.

draft-ietf-trill-directory-assist-mechanisms proposes to augment
TRILL by adding directory servers which cache information about network
topology, allowing RBridges to sometimes shortcut the usual learning
algorithm that they would use to discover this information.

Here are the fundamental points which the Security Considerations
section either addresses or ought to address:

1. There are three relevant security goals:

   a. Availability: packets should reach their intended destination

   b. Confidentiality: packets should not reach unintended destinations

   c. Privacy: metadata concerning network presence should not be
      shared more widely than necessary

2. Access control to directory servers can be enforced using
   pre-existing cryptographic mechanisms specified in RFCs 5304, 5310,
   and 7978.

3. Principals authorized (duly or otherwise) to read directory data
   can violate privacy.

4. Principals authorized to modify directory data can violate
   availability and confidentiality.

5. Directory servers must therefore take care to implement and enforce
   access control policies which are not overly permissive.

The current text of the Security Considerations section directly
addresses points 1a, 1b, 2, and 4. The paragraph added in version 11 of
the draft obliquely implies points 1c and 3 but I wish they'd be
stated more explicitly. But the major omission is point 5: what does
a correct authorization predicate look like? What sort of access must
necessarily be authorized in order for protocol execution to succeed?
What sort of access generally ought *not* be authorized?