Last Call Review of draft-ietf-trill-esadi-06

Request Review of draft-ietf-trill-esadi
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-05-13
Requested 2014-03-20
Authors Hongjun Zhai, fangwei hu, Radia Perlman, Donald Eastlake, Olen Stokes
Draft last updated 2014-05-02
Completed reviews Genart Last Call review of -06 by David Black (diff)
Genart Telechat review of -07 by David Black (diff)
Secdir Last Call review of -06 by Phillip Hallam-Baker (diff)
Assignment Reviewer Phillip Hallam-Baker
State Completed
Review review-ietf-trill-esadi-06-secdir-lc-hallam-baker-2014-05-02
Reviewed rev. 06 (document currently at 09)
Review result Has Nits
Review completed: 2014-05-02


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 is describing extensions to a routing infrastructure. As
such the only security properties that are reasonably achievable
without inappropriate assumptions such as trustworthy routing nodes is
to assure continuity of service. We should assume that authentication
and confidentiality of the message content are assured via some
end-to-end means where the ends are the source and destination of the

[It would be rather useful if the IAB would draft a document that
would state what security properties are expected at which level]

ESADI does provide for improved service assurances by allowing the
authentication of nodes.

What is less clear is how this authentication is leveraged Section 5.1
suggests that authenticating endpoints permits higher confidence to be
built up. if end nodes are authenticated to their MAC address. But
this authentication only has value if there is a chain of custody
authentication to the relying party. Section 6.2 describes a mechanism
that might be relevant here. A pointer would be helpful.