Last Call Review of draft-ietf-nfsv4-rfc5666bis-10
review-ietf-nfsv4-rfc5666bis-10-secdir-lc-roca-2017-03-02-00

Hello,

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: ready with issues

Main comments:

A long and detailed Security considerations section is provided, which is
clearly a good thing. However I have a few comments WRT this section:

** Privacy or confidentiality? Throughout section 8, authors mention "Privacy"
inappropriately IMHO. Privacy refers to PII (Personally identifiable
information) which is different. For instance in section 8.2, when saying:
        "However, integrity and privacy services require significant movement
        of data on each endpoint host."
the authors really mean confidentiality (this is mentioned just above, when
saying that RPCSEC_GSS implements "per-message confidentiality"). There are
several mistakes of that kind throughout section 8.

** On the opposite, meta-data can raise privacy issues, regardless of whether
the content is encrypted or not. Can an eavesdropper who observes the traffic
from an intermediate node (for instance) derive these meta-data and identify
the hosts that communicate together, at what frequency, when? It probably
depends on the protection provided (IPsec versus other RPCSEC integrated
approach if I understand correctly). However if this is the case then there can
be privacy impacts... Is it the case, this is not detailed?

** Section 8.1: it is said:
        "The use of RPC-over-RDMA MUST NOT introduce any vulnerabilities to
        system memory contents, nor to memory owned by user processes."
This is of course highly desirable, but how can the destination be sure that
data copied in its own memory does not contain a malware? I have the feeling
(but may be wrong) that there's a confusion between the RPC-over-RDMA
**protocol** that MUST be secure, and the **content** transferred between two
hosts where it's more a matter of trust between them.

** Section 8.2.2.1: What happens when there's no TCP based NFS server on port
2049? The authors could be more explicit and provide guidance.

** Section 8.2.2.4: There's something that is not clear to me.
It is said that "IDs, connection credit limits, and chunk lists" are exposed
and if an attacker alters them, several consequences are possible. I understand
that this information **is not** included in the RPCSEC_GSS integrity
verifications. Is it really the case?  I'm asking this because the paragraph
concludes with:
        "The use of RPCSEC_GSS integrity or privacy services enable the
        requester to detect if such tampering has been done and reject the RPC
        message."
which suggests that this information **is** protected.

** Last sentence:
        "To address attacks on RDMA protocols themselves, RDMA transport
        implementations should conform to [RFC5042]."
"should" or "SHOULD"?

Minor comments:

- A side comment: can we really say that IPsec can be co-located in RDMA
hardware "without any [...] loss of data movement efficiency"? I'd rather say
that the IPsec performance impacts can be **greatly reduced**.

- Typo in Introduction: "future NFSv4 minor verions" => versions

Cheers,

   Vincent