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
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.
Ietf mailing list