[secdir] Secdir review of draft-ietf-isis-trill

Sam Hartman <hartmans-ietf@mit.edu> Tue, 14 December 2010 16:07 UTC

From: Sam Hartman <hartmans-ietf@mit.edu>
To: draft-ietf-isis-trill-@tools.ietf.org, ietf@ietf.org, secdir@ietf.org
Date: Tue, 14 Dec 2010 11:09:20 -0500
Message-ID: <tslipywbakv.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [secdir] Secdir review of draft-ietf-isis-trill
Precedence: list

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.

[secdir] Secdir review of draft-ietf-isis-trill Sam Hartman
Re: [secdir] Secdir review of draft-ietf-isis-tri… Sam Hartman
Re: [secdir] Secdir review of draft-ietf-isis-tri… Adrian Farrel
Re: [secdir] Secdir review of draft-ietf-isis-tri… Sam Hartman
Re: [secdir] Secdir review of draft-ietf-isis-tri… Erik Nordmark
Re: [secdir] Secdir review of draft-ietf-isis-tri… Sam Hartman
Re: [secdir] Secdir review of draft-ietf-isis-tri… Donald Eastlake
Re: [secdir] Secdir review of draft-ietf-isis-tri… Radia Perlman
Re: [secdir] Secdir review of draft-ietf-isis-tri… Sam Hartman
Re: [secdir] Secdir review of draft-ietf-isis-tri… Donald Eastlake
Re: [secdir] Secdir review of draft-ietf-isis-tri… Sam Hartman
Re: [secdir] Secdir review of draft-ietf-isis-tri… Stewart Bryant
Re: [secdir] Secdir review of draft-ietf-isis-tri… Donald Eastlake