Re: [secdir] SecDir review of draft-ietf-nfsv4-rfc3530bis-25

"Haynes, Tom" <Tom.Haynes@netapp.com> Mon, 08 April 2013 16:55 UTC

Return-Path: <Tom.Haynes@netapp.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8563B21F942B; Mon, 8 Apr 2013 09:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvmWH9MjVFRO; Mon, 8 Apr 2013 09:55:39 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3104121F940D; Mon, 8 Apr 2013 09:55:39 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.87,432,1363158000"; d="scan'208,217"; a="38442746"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 08 Apr 2013 09:55:38 -0700
Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r38GtcQl020698; Mon, 8 Apr 2013 09:55:38 -0700 (PDT)
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.175]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Mon, 8 Apr 2013 09:55:37 -0700
From: "Haynes, Tom" <Tom.Haynes@netapp.com>
To: Yoav Nir <ynir@checkpoint.com>
Thread-Topic: SecDir review of draft-ietf-nfsv4-rfc3530bis-25
Thread-Index: AQHONETOGWagEh4py0udbBA2y+BXSZjNAJYA
Date: Mon, 08 Apr 2013 16:55:27 +0000
Message-ID: <EBFA8133-C174-41C7-A76A-89E991504386@netapp.com>
References: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com>
In-Reply-To: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.51]
Content-Type: multipart/alternative; boundary="_000_EBFA8133C17441C7A76A89E991504386netappcom_"
MIME-Version: 1.0
Cc: "draft-ietf-nfsv4-rfc3530bis.all@tools.ietf.org" <draft-ietf-nfsv4-rfc3530bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-nfsv4-rfc3530bis-25
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: Mon, 08 Apr 2013 16:55:40 -0000

Yoav,

Thanks for the comments. Rather than address them all, I want to
talk about the main ones driving the document.

On Apr 8, 2013, at 3:35 AM, Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>>
 wrote:

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 just like any other last call comments.

Summary: In my opinion, this I-D needs more work.

This is a huge draft. It's on track to become the 3rd biggest RFC behind the security glossary and the NFS 4.1 RFC (5661).


Yes, and the WG has taken pains to make sure we do not do that again.
See for example draft-ietf-nfsv4-minorversion2-19<http://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/> which weighs in at
under 100 pages.


I've spent more time on this than my previous SECDIR reviews combined, and I still don't think I've done a thorough enough job. This revision splits RFC 3530 in two: this document, and the XDR document. This is the third revision of the NFSv4 spec (after 3530 and 3010). RFC 3010 was published on December 2000, over 12 years ago. It may have been a good idea back then to write the spec as a comparison to previous specifications, but I don't think this makes sense 12 years later. As an example, we need look no further than the Abstract:

  The Network File System (NFS) version 4 is a distributed filesystem
  protocol which owes heritage to NFS protocol version 2, RFC 1094, and
  version 3, RFC 1813.  Unlike earlier versions, the NFS version 4
  protocol supports traditional file access while integrating support
  for file locking and the mount protocol.

And it goes on throughout the document - always a diff from NFS 3. That kind of voice makes sense when addressing a community with significant NFS 3 experience, and little or no NFS 4 experience. Is this still the case?


While some implementors may go straight to NFSv4.1, the path is still NFSv3
to NFSv4.0.


The Introduction section does not talk at all about what NFS is and what it could possibly be used for. It's just a series of sections detailing differences from version 3, from 3530, and from 3010. Nowhere does it say why we need a revision of version 4, when version 4.1 is already published.

Valid point and the main one I want to address here.

We have a lot of implementation experience in NFSv4.0 that made its way into NFSv4.1. We still
have many NFSv4 implementations that do not have corresponding NFSv4.1 implementations.

We want to drive back those lessons that do not require protocol changes into the base
document to improve interoperability.

I'll look at how to add that back to the document.

Tom