[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 directorates 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.
- [secdir] SecDir review of draft-ietf-forces-lfb-s… Alexey Melnikov