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

[[e-mail] (Sandy Murphy)]

 

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

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf