Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement
draft-ietf-nfsv4-nfs-rdma-problem-statement-08

[Ballot discuss]
This technology creates a new security requirement for a security
mechanism that provides the necessary security services for NFS
(authentication, integrity and confidentiality) in a manner that will
meet the performance requirements that motivated this RDDP work.  Of
course this security needs to interact well with the infrastructure
used for NFS authentication.

Please document this new security requirement in the security
considerations section.

[Ballot comment]
I'm voting no objection, but support Tim's discuss on the security
considerations.

Two pieces of advice:

* A reference to the security considerations of RFC 4297 from the
  security considerations section of this document may be about
  a 70% solution.
* When NFS requires security, I understand GSS/Kerberos is one
  mechanism that is at least widely implemented and may be used
  more than NFS+IPsec.  A discussion similar to the ones in RFC 4297
  for IPsec and TLS would be helpful to understand the impact of the
  GSS/Kerberos mechanism on RDMA.  If you need help with such text, I
  recommend asking Nicolas Williams for help.

[Ballot discuss]
Sandy Murphy's Security Directorate review identified a number of issues.  I am holding
this discuss pending resolution of her issues.  I have included her comments in their
entirety below.  Following Sandy's review, I have appended a couple of related issues
under the heading "Part 2: AD Issues".

This is a review of draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt

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.

This document describes the use of NFS (over RPC) over RDMA.  Most of
the text surveys current literature as to why doing RDMA to avoid data
copying would be a good thing.

The security considerations section is quite short:

    The NFS protocol, in conjunction with its layering on RPC, provides
    a rich and widely interoperable security model to applications and
    systems.  Any layering of NFS over RDMA transports must address the
    NFS security requirements, and additionally must ensure that no new
    vulnerabilities are introduced.  For RDMA, the integrity, and any
    privacy, of the data stream are of particular importance.

    Security Considerations must be addressed by any relevant RDMA
    transport layering.  The protocol described in [RPCRDMA] provides
    one such approach.

I don't think the particularly important aspects of RDMA transfer are
limited to integrity and privacy.  I think that one of the important
security considerations would be the authorization of the source of the
RDMA transfer to be reading or writing into whatever memory or data
buffers it was writing into.  The RPCRDMA draft does not address this
question.  It discusses the integrity and privacy of the data
transferred, as here.

The RDDP has a draft which discusses DDP/RDMA security in depth.  I think that
the draft http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-10.txt
is a suitable reference for this draft.  It's on the RFC Ed queue
according to the I-D tracker.

(In particular, it talks about the idea of a protection domain:

  A correct implementation of a
  Protection Domain requires that resources which belong to a given
  Protection Domain can not be used on a resource belonging to
  another Protection Domain, because Protection Domain membership
  is checked by the RNIC prior to taking any action involving such
  a resource. Protection Domains are therefore used to ensure that
  an STag can only be used to access an associated data buffer on
  one or more Streams that are associated with the same Protection
  Domain as the specific STag.

I think that settles my question of authorizing the RDMA transfer.

The rddp-rdmap-07 draft has a nice summary (sect 8.1) of the security
requirements derived from the discussion in the rddp-security draft.

There's also a discussion of security services in RFC4296, the
DDP and RDMA Architecture.  E.g.:

          Peer connections that do not pass authentication and
          authorization checks must not be permitted to begin processing
          in RDMA mode with an inappropriate endpoint.  Once associated,
          peer accesses to buffer regions must be authenticated and made
          subject to authorization checks in the context of the
          association and endpoint (socket) on which they are to be
          performed, prior to any transfer operation or data being
          accessed.  The RDMA protocols must ensure that these region
          protections be under strict application control.

Of course there's the question of relating the authentication and
authorization done by RPC_GSSAPI to the protection domain of the RDMA
security, and both to the SA of the IPSec if that is used to protect
the RDMA transfer.  Perhaps this is just one channel binding, perhaps
it is channel binding squared, perhaps the CCM referenced in the
rpsrdma draft is sufficient for both.  I just can't tell.


A process question.

This draft (and the rpcrdma draft) contain a normative reference called
"rfc1831bis", with a title of
          R. Thurlow, Ed., "RPC: Remote Procedure Call Protocol
          Specification Version 2", Standards Track RFC

That would seem to be a reference to draft-ietf-nfsv4-rfc1831bis-06.txt,
but the I-D Tracker has that listed as "Dead".

Also. Not my job, but the rpcrdma draft has a reference:
    [CCM]
          M. Eisler, N. Williams, "CCM: The Credential Cache GSS
          Mechanism", Internet Draft Work in Progress, draft-ietf-
          nfsv4-ccm

But on tools.ietf.org (the draft has expired from the internet-drafts
list, but at least it is still called "I-D Exists" in the I-D Tracker)
the title is:

            The Channel Conjunction Mechanism (CCM) for GSS
                    draft-ietf-nfsv4-ccm-03


Another not-my-job question.  The rpcrdma draft and the rddp-security
draft both mention transport over Infiniband, but everything that I've
been able to find imply that Infiniband is not an IP protocol.  So IPSec
would not apply, presumably.  Do  the discussions of security in the
nfsv4 and rddp drafts still work if Infiniband is the RDMA transport? 
In particular, rddp-security says
  For RDDP, IPsec is the better choice for a security framework,
  and hence is mandatory-to-implement (as specified elsewhere in
  this document).
Also, the rddp-security draft seems to
assume the reliable, ordered delivery of TCP, and I can not tell if
that is provided by Infiniband.

--Sandy


Part 2: AD issues

The security considerations section states that "Any layering of NFS over RDMA transports
must address the NFS security requirements", but it is unclear where these requirements are
documented.  In the absence of a clear reference, some elaboration of the NFS security
requirements is needed here.

The second clause of that same sentence is also troublesome.  Here is the
complete sentence (emphasis added):

      Any layering of NFS over RDMA transports must address the
      NFS security requirements, *and additionally must ensure that no new
      vulnerabilities are introduced*.

I don't believe this provides enough guidance regarding the types of vulnerabilities
that one should be worried about.  While this can never be comprehensive, some
assitance to protocol designers is probably in order.

The RDMA over IP problem statement (RFC 4297) provided a much more robust analysis
with respect to the types of problems that could be encountered.  For example, the
security considerations section begins with the following paragraph:

  Solutions to the problem of reducing copying overhead in high
  bandwidth transfers may introduce new security concerns.  Any
  proposed solution must be analyzed for security vulnerabilities and
  any such vulnerabilities addressed.  Potential security weaknesses --
  due to resource issues that might lead to denial-of-service attacks,
  overwrites and other concurrent operations, the ordering of
  completions as required by the RDMA protocol, the granularity of
  transfer, and any other identified vulnerabilities -- need to be
  examined, described, and an adequate resolution to them found.

Given the brevity of the security considerations section in this document,
it is unclear if the potential security weaknesses have been adequately
explored.  That is, it is unclear if the "NFS security requirements" are really
complete with respect to NFS with RDMA.

[Ballot discuss]
Sandy Murphy's Security Directorate review identified a number of issues.  I am holding
this discuss pending resolution of her issues.  I have included her comments in their
entirety below.  Following Sandy's review, I have appended a couple of related issues
under the heading "Part 2: AD Issues".

This is a review of draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt

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.

This document describes the use of NFS (over RPC) over RDMA.  Most of
the text surveys current literature as to why doing RDMA to avoid data
copying would be a good thing.

The security considerations section is quite short:

    The NFS protocol, in conjunction with its layering on RPC, provides
    a rich and widely interoperable security model to applications and
    systems.  Any layering of NFS over RDMA transports must address the
    NFS security requirements, and additionally must ensure that no new
    vulnerabilities are introduced.  For RDMA, the integrity, and any
    privacy, of the data stream are of particular importance.

    Security Considerations must be addressed by any relevant RDMA
    transport layering.  The protocol described in [RPCRDMA] provides
    one such approach.

I don't think the particularly important aspects of RDMA transfer are
limited to integrity and privacy.  I think that one of the important
security considerations would be the authorization of the source of the
RDMA transfer to be reading or writing into whatever memory or data
buffers it was writing into.  The RPCRDMA draft does not address this
question.  It discusses the integrity and privacy of the data
transferred, as here.

The RDDP has a draft which discusses DDP/RDMA security in depth.  I think that
the draft http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-10.txt
is a suitable reference for this draft.  It's on the RFC Ed queue
according to the I-D tracker.

(In particular, it talks about the idea of a protection domain:

  A correct implementation of a
  Protection Domain requires that resources which belong to a given
  Protection Domain can not be used on a resource belonging to
  another Protection Domain, because Protection Domain membership
  is checked by the RNIC prior to taking any action involving such
  a resource. Protection Domains are therefore used to ensure that
  an STag can only be used to access an associated data buffer on
  one or more Streams that are associated with the same Protection
  Domain as the specific STag.

I think that settles my question of authorizing the RDMA transfer.

The rddp-rdmap-07 draft has a nice summary (sect 8.1) of the security
requirements derived from the discussion in the rddp-security draft.

There's also a discussion of security services in RFC4296, the
DDP and RDMA Architecture.  E.g.:

          Peer connections that do not pass authentication and
          authorization checks must not be permitted to begin processing
          in RDMA mode with an inappropriate endpoint.  Once associated,
          peer accesses to buffer regions must be authenticated and made
          subject to authorization checks in the context of the
          association and endpoint (socket) on which they are to be
          performed, prior to any transfer operation or data being
          accessed.  The RDMA protocols must ensure that these region
          protections be under strict application control.

Of course there's the question of relating the authentication and
authorization done by RPC_GSSAPI to the protection domain of the RDMA
security, and both to the SA of the IPSec if that is used to protect
the RDMA transfer.  Perhaps this is just one channel binding, perhaps
it is channel binding squared, perhaps the CCM referenced in the
rpsrdma draft is sufficient for both.  I just can't tell.


A process question.

This draft (and the rpcrdma draft) contain a normative reference called
"rfc1831bis", with a title of
          R. Thurlow, Ed., "RPC: Remote Procedure Call Protocol
          Specification Version 2", Standards Track RFC

That would seem to be a reference to draft-ietf-nfsv4-rfc1831bis-06.txt,
but the I-D Tracker has that listed as "Dead".

Also. Not my job, but the rpcrdma draft has a reference:
    [CCM]
          M. Eisler, N. Williams, "CCM: The Credential Cache GSS
          Mechanism", Internet Draft Work in Progress, draft-ietf-
          nfsv4-ccm

But on tools.ietf.org (the draft has expired from the internet-drafts
list, but at least it is still called "I-D Exists" in the I-D Tracker)
the title is:

            The Channel Conjunction Mechanism (CCM) for GSS
                    draft-ietf-nfsv4-ccm-03


Another not-my-job question.  The rpcrdma draft and the rddp-security
draft both mention transport over Infiniband, but everything that I've
been able to find imply that Infiniband is not an IP protocol.  So IPSec
would not apply, presumably.  Do  the discussions of security in the
nfsv4 and rddp drafts still work if Infiniband is the RDMA transport? 
In particular, rddp-security says
  For RDDP, IPsec is the better choice for a security framework,
  and hence is mandatory-to-implement (as specified elsewhere in
  this document).
Also, the rddp-security draft seems to
assume the reliable, ordered delivery of TCP, and I can not tell if
that is provided by Infiniband.

--Sandy


Part 2: AD issues

The security considerations section states that "Any layering of NFS over RDMA transports
must address the NFS security requirements", but it is unclear where these requirements are
documented.  In the absence of a clear reference, some elaboration of the NFS security
requirements is needed here.

The second clause of that same sentence is also troublesome:

      Any layering of NFS over RDMA transports must address the
      NFS security requirements, and additionally must ensure that no new
      vulnerabilities are introduced.

I don't believe this provides enough guidance reagrding the types of vulnerabilities
that one should be worried about.  While this can never be comprehensive, some
assitance to protocol designers is probably in order.

The RDMA over IP problem statement (RFC 4297) provided a much more robust analysis.
For example, the security considerations section begins with the following paragraph:

  Solutions to the problem of reducing copying overhead in high
  bandwidth transfers may introduce new security concerns.  Any
  proposed solution must be analyzed for security vulnerabilities and
  any such vulnerabilities addressed.  Potential security weaknesses --
  due to resource issues that might lead to denial-of-service attacks,
  overwrites and other concurrent operations, the ordering of
  completions as required by the RDMA protocol, the granularity of
  transfer, and any other identified vulnerabilities -- need to be
  examined, described, and an adequate resolution to them found.

Given the brevity of the security considerations section in this document,
it is unclear if the potential security weaknesses have really been explored.
That is, it is unclear if the "NFS security requirements" are really complete
with respect to NFS with RDMA.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

The document shepherd is Spencer Shepler. Spencer has reviewed
the documents and believes they are ready for publication.


(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

The documents have been reviewed via two working group last
calls:

WG last call on Aug 17, 2006
http://www1.ietf.org/mail-archive/web/nfsv4/current/msg03706.html

WG last call on May 8th, 2007
http://www1.ietf.org/mail-archive/web/nfsv4/current/msg04322.html

And the documents have received external review as well.

There are no remaining concerns related to depth or breadth
of the reviews that have occurred.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No concerns exist.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of?

No such concerns exist.


(1.e) How solid is the consensus of the interested community behind
this document?

There is broad consensus within the NFS and RPC communities
in this work.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent?

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits?

Yes.

(1.h) Has the document split its references into normative and
informative?

Yes.

Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?

No.

If such normative references exist, what is the strategy for
their
completion?

Not applicable.

Are there normative references that are downward
references, as described in [RFC3967]?

Yes.

If so, list these downward
references to support the Area Director in the Last Call
procedure
for them [RFC3967].

RFC1813 "NFS Version 3 Protocol Specification"

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document?

Yes.

If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA
registries clearly identified?

Yes. Yes.

If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

Not Applicable.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:


Document Announcement Write-Up for:

"NFS RDMA Problem Statement"
draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt
---------------------------------------------------------------

Technical Summary

Motivation for the application of Remote Direct Memory Access
to the NFS protocols is described. NFS implementations
historically incur significant overhead due to data copies on
end-host systems, as well as other processing overhead. The
potential benefits of RDMA to these implementations are
explored, and the reasons why RDMA is especially well-suited to
NFS and network file protocols in general are evaluated.

Working Group Summary

There is consensus in the WG to publish these documents.

Document Quality

As the Informative References demonstrate, this work has drawn
on a variety of work in academia and industry and
appropriately motivates the appropriate use of RDMA
technologies for protocols such as NFS.