[secdir] SecDir review of draft-ietf-forces-lfb-subsidiary-management-01

Alexey Melnikov <alexey.melnikov@isode.com> Sun, 30 August 2015 12:09 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD1E1ACD65 for <secdir@ietfa.amsl.com>; Sun, 30 Aug 2015 05:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.112
X-Spam-Level:
X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh8wp-o96twW for <secdir@ietfa.amsl.com>; Sun, 30 Aug 2015 05:09:28 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF41A008A for <secdir@ietf.org>; Sun, 30 Aug 2015 05:09:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1440936566; d=isode.com; s=selector; i=@isode.com; bh=AOywPMDvOqoayx0qAb48VUOWn1eR9mpIE2mHJinDHUE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cxrzjiFQpcxAySgaUlbd1174XBTsJOOPK5GUXpzj8p99xJA15CLveso+BdvdUyLIyrUcUn 2J+2rL9H7k6lEPCY7iRvbGkYckoCbOpNGO67t/AtHwtNJZ7jBFf0W2Xl1ZDKEATcpt0Zox eosF2fnBkJXiUyG7P+bdHkuQweIU4fs=;
Received: from [192.168.0.5] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VeLydQABaJXq@waldorf.isode.com>; Sun, 30 Aug 2015 13:09:26 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: draft-ietf-forces-lfb-subsidiary-management.all@tools.ietf.org, secdir@ietf.org
X-Enigmail-Draft-Status: N1110
Message-ID: <55E2F242.60604@isode.com>
Date: Sun, 30 Aug 2015 13:08:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/HTuGdEZhDEiCVKTZKtv--DU_4vg>
Subject: [secdir] SecDir review of draft-ietf-forces-lfb-subsidiary-management-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 30 Aug 2015 12:09:29 -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 with the intent of improving security
requirements and considerations in IETF drafts. Comments not addressed
in last call may be included in AD reviews during the IESG review.
Document editors and WG chairs should treat these comments just like any
other last call comments.

draft summary: This document is using the Forwarding and Control Element
Separation (ForCES) architecture to manage resources other than packet
forwarding.  The Forwarding Element Manager (FEM) is modeled by creating
a Logical Functional Block (LFB) to represent its functionality.  The
document to this LFB as the Subsidiary Mechanism (SM) LFB.  A Control
Element (CE) that controls a Forwarding Element's (FE) resources can
also manage its configuration via the SM LFB.  This document introduces
the SM LFB, an LFB that specifies the configuration parameters of an FE.
The SM LFB describes the configuration parameters of an FE, namely the
LFB classes it should load, the CEs it should be associated with as well
the respective CE IP addresses.  Additionally the SM LFB provides a
general purpose attribute definition to describe config information, as
well as the ability to manipulate debug logging mechanism.

SecDir status summary: Ready.

This document states that it does not alter the ForCES Model [RFC5812]
or the ForCES Protocol [RFC5810], so it has no impact on their security.
I am not an expert in ForCES, but I tend to agree with this.
This document defines the operational parameters and capabilities of an
LFB that manages subsidiary mechanism for loading LFBs and create new
connections between FEs and CEs. This document does not attempt to
analyze the security issues that may arise from misuse of the SM LFB and
defers analysis and design of mitigation strategies (if any needed) to
designers of SM implementations.

I am wondering if it is worth pointing directly to RFC 3746, Section 8
(In particular Section 8.1.6 on Data Confidentiality)? This would avoid
the need to go through a level of indirection provided by RFC 5810.