[secdir] secdir review of draft-ietf-trill-oam-req

Tobias Gondrom <tobias.gondrom@gondrom.org> Tue, 01 January 2013 09:01 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 99D3321F8A67 for <secdir@ietfa.amsl.com>; Tue, 1 Jan 2013 01:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.113
X-Spam-Status: No, score=-95.113 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id slxJv4JWbeiQ for <secdir@ietfa.amsl.com>; Tue, 1 Jan 2013 01:01:37 -0800 (PST)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de []) by ietfa.amsl.com (Postfix) with ESMTP id 811EE21F8A6B for <secdir@ietf.org>; Tue, 1 Jan 2013 01:01:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=B/xewOiSEDzr/CLjym7MxGu2adzgiOQcWZjbI6je+VL8JKTW681elVU2Z3iQdi+xJvyjUujGe/wk3OSXQAMu0OUbt1DI5rVovcMumPR48VjfMPqZ4xk9Oa+At6QBYxgl; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type;
Received: (qmail 21520 invoked from network); 1 Jan 2013 10:01:34 +0100
Received: from 059148230045.ctinets.com (HELO ? ( by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Jan 2013 10:01:34 +0100
Message-ID: <50E2A5EB.7040706@gondrom.org>
Date: Tue, 01 Jan 2013 17:01:31 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-trill-oam-req.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------030609060906060507010902"
Subject: [secdir] secdir review of draft-ietf-trill-oam-req
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 01 Jan 2013 09:01:37 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments ust like any other last call comments.

This ID is informational and specifies requirements for operations, 
administration and maintenance (OAM) in TRILL (Transparent 
Interconnection of Lots of Links).

The document lists requirements from an operational perspective. And 
less from a security perspective.
Section "4.8. Security and Operational considerations" is very brief.
And although I like the basic attitude of the first sentence there 
"Methods MUST be provided to protect against exploitation of OAM 
framework for security and denial of service attacks."
The section is not clear about which requirements might derive from the 
"protect against exploitation of OAM ...for security...". The draft 
could benefit from deriving from this security consideration statement a 
set of clear and specific requirements for OAM for TRILL and/or linking 
them to the operational requirements listed in the previous sections.

Section 5 is just a pointer to section 4.8 and could be merged with 
section 4.8 and/or removed.
It is reasonable to refer to the basic security considerations for TRILL 
in RFC6325, but it would be good to add/think about requirement 
implications from security requirements for OAM.

Best regards, Tobias