Last Call Review of draft-ietf-isis-trill-
review-ietf-isis-trill-secdir-lc-hartman-2010-12-16-00

Please treat these as normal last call comments.

I found the introduction to draft-ietf-isis-trill inadequate. I'm
familiar with the base concepts behind TRILL, roughly understand what
was going on and followed the chartering discussions of the WG fairly
closely.  I have read the requirements document but have not read the
protocol document.  In an ideal world this document would be
significantly easier to follow; I suspect that after reading the
protocol document I'd still find this a bit choppy.
However, I understand  that sometimes you can only spend so much time on
a spec and sometimes you reach the point where if someone isn't willing
to jump in and volunteer a lot of hours to add clarity, good enough is
good enough.

This document claims that it adds no new security considerations to
IS-IS.  That's true.  However, TRILL is a new protocol--completely new.
It re-uses IS-IS as a building block, but if I were a security AD I'd
still insist that TRILL meet our current standards for security,
including a strong mandatory-to-implement security mechanism and (where
appropriate) automated key management.

I definitely think that this specification should at least document how
IS-IS+TRILL fall short of standards we'd require for a new protocol
today.  The big area I can think of is replay handling for hello
packets, which I suspect leads to a DOS.  If we had more success with
multicast key management we'd probably also require automated key
management for a protocol like this. However,we don't, so I think that
the RFC 4107 analysis would conclude that manual key management is
acceptable under the multicast exception.

I suspect the sec ADs will not actually require a solution even though
it is a new protocol. I think that's a mistake, but I also don't have a
lot of time to spend on TRILL, and I'd definitely rather see it get
published than bogged down. I think documenting how IS-IS security
interacts with TRILL security and IETF security BCPs should only take a
relatively short time.