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

Sam Hartman <> Fri, 17 December 2010 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97AC53A69C2; Fri, 17 Dec 2010 12:54:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.885
X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eZaX7XGnXb9A; Fri, 17 Dec 2010 12:54:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 928813A6998; Fri, 17 Dec 2010 12:54:19 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS id EC778202C9; Fri, 17 Dec 2010 15:54:58 -0500 (EST)
Received: by (Postfix, from userid 8042) id 3E21C4060; Fri, 17 Dec 2010 15:55:51 -0500 (EST)
From: Sam Hartman <>
To: Sam Hartman <hartmans-ietf@MIT.EDU>
References: <>
Date: Fri, 17 Dec 2010 15:55:51 -0500
In-Reply-To: <> (Sam Hartman's message of "Tue, 14 Dec 2010 11:09:20 -0500")
Message-ID: <>
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: Re: [secdir] Secdir review of draft-ietf-isis-trill
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Dec 2010 20:54:20 -0000

Hi.  I've been asked by the trill authors to clarify what I meant by my
secdir review.

That's certainly fair.

I think there are two issues.

The first is that I think that draft-ietf-isis-trill does an adequate
job of discussing the security implications of IS-IS on trill.  I've
read the security considerations section of
draft-ietf-trill-rbridge-protocol and I think it doesn't do so either.

However, it comes very close.  If I understand Is-IS security correctly,
the only attack that we would expect a routing protocol to deal with
that it does not is replays. (IS-Is is no worse than anything else
here.)  The impact of replays is a denial of service.  If I'm
understanding section 6.2 of draft-ietf-trill-rbridge-protocol
correctly, similar denial of service attacks are also possible with
trill-specific messages.

If my understanding of the impact of IS-IS security (even with
authentication) is sufficient, I think this concern could be addressed
by adding a sentence to the security considerations section of
draft-ietf-isis-trill saying something like "Even when the IS-IS
authentication is used, replays of IS-IS packets can create
denial-of-service conditaions; see RFC 6039 for details. These issues
are similar in scope to those discussed in section 6.2 of
draft-ietf-trill-rbridge-protocol, and the same mitigations may apply."

I have a second large issue with the way we've handled trill.  First I'd
like to compliment the authors of draft-ietf-trill-rbridge-protocol,
particularly on the security considerations section, but the document
quality of other sections of that document I've looked at is high.
They've done a good job of describing what they've done and as far as I
can tell delivering what they've said they would deliver.

However, something went wrong somewhere.  We have some standards that
we've agreed to as a community for the security of new work we do. It's
my opinion that trill does not meet those standards. The document
doesn't claim it does.

I think that was wrong, however the mistake was in the review of RFC
5556 (the TRILL problem statement), which clearly sets out what TRILL
was going to do.  I believe I was on the IESG at a time when that
document was reviewed, so I especially don't have room to complain here.

So, actually even were I on the IESG, I would not hold up the protocol
over this issue.

Looking forward to future work, though, I think we should be more
consistent about applying our community standards to work we charter. If
those standards are wrong, let's revise them.  No, TRILL should not have
been forced to solve the ethernet control plane security
problem. However TRILL should have had a security mechanism that meets
current standards so that when the ethernet control plane is updated
TRILL never ends up being the weakest link.  As best I can tell, TRILL
does meet the security goals stated in its problem statement.

Also, my comment about document quality was never intended to be
blocking. While I don't believe draft-ietf-isis-trill is of as high
quality as draft-ietf-trill-rbridge-protocol, I did manage to understand
it without the rbridge-protocol document. The authors claim that should
not be requried; I think if I had looked at the rbridge-protocol
document first I would have concluded that it was more clear than
isis-trill, although I think it's also true that I would have been less
bothered.  Either way, I did manage to follow both documents.