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

Adrian Farrel <Adrian.Farrel@huawei.com> Fri, 17 December 2010 21:22 UTC

Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE16F3A6C2A; Fri, 17 Dec 2010 13:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.641
X-Spam-Level:
X-Spam-Status: No, score=-103.641 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlMzLG2Qc64d; Fri, 17 Dec 2010 13:22:52 -0800 (PST)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D44E03A6C1D; Fri, 17 Dec 2010 13:22:52 -0800 (PST)
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LDL00J18CT30P@usaga01-in.huawei.com>; Fri, 17 Dec 2010 13:24:40 -0800 (PST)
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LDL00EHDCT1U5@usaga01-in.huawei.com>; Fri, 17 Dec 2010 13:24:39 -0800 (PST)
Date: Fri, 17 Dec 2010 21:24:38 +0000
From: Adrian Farrel <Adrian.Farrel@huawei.com>
In-reply-to: <tsl4oac15m0.fsf@mit.edu>
To: 'Sam Hartman' <hartmans-ietf@mit.edu>
Message-id: <010701cb9e30$d17a1990$746e4cb0$@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-type: text/plain; charset=us-ascii
Content-language: en-gb
Content-transfer-encoding: 7BIT
Thread-index: AQEnHMNUQZgblglcEzvZ5LOribmVJgIlUz+ilNz8YHA=
References: <tslipywbakv.fsf@mit.edu> <tsl4oac15m0.fsf@mit.edu>
Cc: draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian.Farrel@huawei.com
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Dec 2010 21:22:54 -0000

Sam,

Thanks for your work.

Can I clarify. You wrote:

> 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.

I you have one positive and one negative statement.
I think you meant them to both be negative.
Perhaps you could confirm.

Cheers,
Adrian

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Sam
> Hartman
> Sent: 17 December 2010 20:56
> To: Sam Hartman
> Cc: draft-ietf-isis-trill@tools.ietf.org; ietf@ietf.org; secdir@ietf.org
> Subject: Re: Secdir review of draft-ietf-isis-trill
> 
> 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.
> 
> --Sam
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf