[secdir] Sector review of draft-ietf-nfsv4-layout-types-03

Joseph Salowey <joe@salowey.net> Thu, 16 April 2015 23:31 UTC

Return-Path: <joe@salowey.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7D8591A8739 for <secdir@ietfa.amsl.com>; Thu, 16 Apr 2015 16:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.578
X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id i3Kg2CeJiZNh for <secdir@ietfa.amsl.com>; Thu, 16 Apr 2015 16:31:33 -0700 (PDT)
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955681A8734 for <secdir@ietf.org>; Thu, 16 Apr 2015 16:31:33 -0700 (PDT)
Received: by qkhg7 with SMTP id g7so143083609qkh.2 for <secdir@ietf.org>; Thu, 16 Apr 2015 16:31:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=f6Jb0tP4RxdsFzB1wiWmvOhxNHRlMj10464r0yiS+Aw=; b=Li1TQmYUqMrWFfwAdL385b8PYrlMrZKzvfCN6G5QaSZYu7AW8XWJBeH/oLIhi8NBy5 wKxhAC2rhftNRfutsgMqGmNcHawRz99H20cW50zO6xR/YvGkxxEbdS9I9kGcZEt68T2+ X/hdPFsJ+nV89FpsmZ1VRFub+rgiKlPBqgP5oH+x8GL6V+RK7uPE+MYnHJsOncRYhfUi XkoM96VU+NXsSoY8ziYRoG7j2TK5SSNExlykmCstAtE2TpW5wfpcVwmq9NQz7V/F/KQ5 Lb1/9S+W5+kv8BV7QSsHFmaxT3ap9kuG3kjnc2MCMBf0tePNo363vgaqjDzhSLJHcPsH 1XNg==
X-Gm-Message-State: ALoCoQmJ7gLDd4xc2fIjlPnIKfDliQis76HriR3Or/w6I94PnlEAfBz8NA0XeVX+oBeX5LE3I+sX
MIME-Version: 1.0
X-Received: by with SMTP id ba3mr294542qcb.3.1429227092889; Thu, 16 Apr 2015 16:31:32 -0700 (PDT)
Received: by with HTTP; Thu, 16 Apr 2015 16:31:32 -0700 (PDT)
X-Originating-IP: []
Date: Thu, 16 Apr 2015 16:31:32 -0700
Message-ID: <CAOgPGoAJxN+qWXoR7ZFZUCJbTaC87NYqiii81oHPKuWEnwL5bQ@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
To: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-nfsv4-layout-types.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=001a11c2875a2cecde0513dfdd04
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Hw4NXVlLn-S5mOXnSWM9TUluJkc>
Subject: [secdir] Sector review of draft-ietf-nfsv4-layout-types-03
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: <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: Thu, 16 Apr 2015 23:31:35 -0000

Do not be alarmed, this document review is part of the security
directorate's ongoing effort to review all IETF documents being processed
by the IESG.  These comments were written for the benefit of the document
editors, WG chairs and the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call

I believe this document is ready with issues.

The document discusses security requirements for pNFS layout types.  The
document has significant discussions of security considerations, however
I'm not sure its complete and I think it could be better organized.  The
main places that need work are the security considerations section and the
protocol requirements section.

I'm not sure how best to break up the information between the security
considerations and the rest of the document, but here are some suggestions.

Security considerations - Different Layout types have significantly
different security properties.  I think this should be emphasized in the
security considerations section:

"Different layout types have significantly different security properties
which need to be considered during their design and deployment.  For
example, some layouts, such as the block layout type, can only enforce
minimal security controls and require the client to be trusted to enforce
additional access controls. "

The current security considerations section discusses fencing
requirements.  Are there additional security considerations around the
control protocol used to revoke access at the storage device?  It would
seem that the integrity and availability of this channel is important.
Possibly the confidentiality of the channel is important as well.

It would probably be a good idea to discuss the security requirements of
the storage protocol as well.

It would probably be a good idea to reference section 12.9 and 13.12 of RFC

Are there cases where any contextual information needs to be communicated
over the control channel (access control information perhaps)?

This document does not include privacy considerations, but neither does RFC
5661, so I'm not sure it would be in scope.

I'm new to NFSv4 and pNFS so if some of this isn't clear let me know and I
can try to clarify.