Subject: [secdir] sec-dir review of draft-ietf-nfsv4-pnfs-block-10.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 4 Dec 2008 10:04:16 +0200

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.

I have to say that I am not an NFS expert and the size of NFS related
documents is scary.

Anyway, draft-ietf-nfsv4-pnfs-block-10.txt provides an optimization to
NFSv4.1 to "to allow clients to directly access file data on the storage
used by the NFSv4 server.". draft-ietf-nfsv4-minorversion1-26.txt already
introduces the concept (in Section 12) and this document illustrates how to
use it for block/volume layouts.

As such, draft-ietf-nfsv4-pnfs-block-10.txt builds heavily on
draft-ietf-nfsv4-minorversion1-26.txt and therefore a lot of the transport
and security related features are inherited. 

Figure 1 of draft-ietf-nfsv4-pnfs-block-10.txt illustrates the architecture
quite nicely and the authors of the document do a good job of describing the
consequences with regard to security. In short, when clients access the
storage systems directly then the security properties are not only dependent
on the usage of NFSv4.1 anymore but also on the storage protocol used
between clients and the storage system. The used storage protocol may or may
not provide the desired security capabilities. This includes communcation
security as well as access control. 

This may sound dramatic. However, it is a matter of deployment and the
administrator of the system needs to make a decision about what is
acceptable. Consequently, in certain setups clients have to be trusted to a
high degree and communication security between the clients and the storage
system may need to rely on physical security. 

As such, I don't have problem with the chosen approach also given that the
concept is already introduced the main NFSv4.1 specification (a separate
security consideration section is also available in Section 12.9 of
draft-ietf-nfsv4-minorversion1-26.txt). 

A few minor comments / questions:  

* Figure 1 in draft-ietf-nfsv4-minorversion1-26.txt also includes a
description of the communication between the clients and the storage device
and between the storage devices and the servers. This description is missing
in Figure 1 of draft-ietf-nfsv4-pnfs-block-10.txt. Very likely a
copy-and-paste error. 

* In Section 2.2.1 volume identification is described and it is noted that
content-based identification would be necessary. I am not quite sure what
that means. I suspect that you are talking about using an opaque string as
identification rather than something like a IP address and port. Right? 

* Typo in last paragraph of page 20: s/SEQUEUNCE/SEQUENCE/ 

Ciao
Hannes

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: [email-masked]
Date: Fri, 5 Dec 2008 21:16:33 -0500

Hannes,

Thank you very much for this review.  All 3 of your minor comments
are reasonable and we'll do something about each of them in the -11.

The answer to your question about content identification:

> I suspect that you are talking about using an opaque string as

That's correct, and multiple opaque strings that are intended
to match different locations on the volume may be used.  This
is a long-standing identification technique for storage - for
example, volume managers usually identify a volume by checking
the volume label that is often stored at the start of a volume.

I can offer to explain why address-based volume identification
doesn't work well over a suitable alcoholic beverage at some
point.  In any case, we'll add some additional explanation of
this method of identification in the -11 version.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Thursday, December 04, 2008 3:04 AM
> To: [email-masked]
> Cc: [email-masked]; fridella, stephen; Black, David; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: sec-dir review of draft-ietf-nfsv4-pnfs-block-10.txt 
> 
> used by the NFSv4 server.".  draft-ietf-nfsv4-minorversion1-26.txt
> already introduces the concept (in Section 12) and this document
illustrates how to