Telechat Review of draft-ietf-trill-directory-assisted-encap-09

Request Review of draft-ietf-trill-directory-assisted-encap
Requested rev. no specific revision (document currently at 11)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2018-03-06
Requested 2018-02-15
Draft last updated 2018-03-08
Completed reviews Rtgdir Early review of -02 by Ben Niven-Jenkins (diff)
Secdir Telechat review of -09 by Hilarie Orman (diff)
Genart Telechat review of -09 by Roni Even (diff)
Assignment Reviewer Hilarie Orman
State Completed
Review review-ietf-trill-directory-assisted-encap-09-secdir-telechat-orman-2018-03-08
Reviewed rev. 09 (document currently at 11)
Review result Has Issues
Review completed: 2018-03-08


Security review of Directory Assisted TRILL Encapsulation

(A day late and a dollar short, sorry)

Do not be alarmed.  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

The document describes "the benefits of and a scheme for non-RBridge
nodes performing TRILL encapsulation."  The scheme uses TRILL
directories to help with the scaling issues for large TRILL networks
that co-exist with non-TRILL networks.  Non-RBridge nodes can
find a TRILL directory and properly encapsulate packets with TRILL
headers to guide them to and from the network edges.  The method
reduces the amount of node information that might otherwise be
assigned and flooded through the network.

There are security considerations that mandate that the directory
server and the TRILL encapsulating nodes "properly authenticate with
each other to protect sensitive information," but there is no
discussion what is "proper" or how the propriety is maintained.
How does the directory server know which entities are authorized to
be encapsulating nodes and what information are they allowed to
see (or change)?  How do the encapsulating nodes know how to
authenticate the directory nodes?  Is this essential configuration
that has to be built in before the network can function with directory
assisted encapsulation?  Does it require cooperation between
administrators in different parts of a campus?

In some place the behavior of the nodes depends on whether or not
the directory is "known to be complete".  This seems like transient
information that has to be communicated in some unspecified way at
unspecified times.  It may not affect security, but it might affect

Nits about grammar are many, but the one that interferes with
comprehension is the split infinitive in "it is still necessary to
designate AF ports to, for example, be sure that multi-destination