Subject: [secdir] SECDIR review of draft-ietf-nfsv4-rpcrdma-bidirection

From: Radia Perlman <[email-masked]>
Date: Sun, 29 Jan 2017 19:11:07 -0800

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 draft concerns running NFS over RDMA (memory to memory access), and in
particular running RPC requests “in both directions” (client to server –
called forward direction – and callbacks from server to client called
reverse direction). The RFC claims to describe current practice rather than
to prescribe future practice, but it is intended to be Standards track,
which is a little odd, but I guess documenting what is current practice and
standardizing on it for the future is fine.

In any case, RDMA is a high performance protected channel considered to be
secure by its nature. If an RDMA protocol were run over a network tunnel,
it would be the responsibility of the tunnel to implement authentication
and encryption. And access rights of particular nodes and/or users is
defined in higher layers of NFS, and so is unaffected by the fact that this
is running over RDMA.

Bottom line is there are no security considerations. The security
considerations section refers readers to RFC5666bis (which is about NFS
over RDMA generally rather than the specific issue of callbacks). This
seems appropriate.

If I were to make one comment it's that I don't like the terminology
"backwards".  I might have used "reverse".  "Backwards" has a somewhat
negative connotation, and it's slightly confusing when discussing "Backward
Credits". I'd think a "backwards credit" would be taking away credits from
someone. "Reverse credits" would be just as bad, but perhaps
"reverse-direction credits" might be clear.

Radia

---

From: Chuck Lever <[email-masked]>
Date: Mon, 30 Jan 2017 11:18:56 -0500

> On Jan 29, 2017, at 10:11 PM, Radia Perlman <[email-masked]> 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. 
> 
> This draft concerns running NFS over RDMA (memory to memory access), and in particular running RPC requests “in both directions” (client to server – called forward direction – and callbacks from server to client called reverse direction). The RFC claims to describe current practice rather than to prescribe future practice, but it is intended to be Standards track, which is a little odd, but I guess documenting what is current practice and standardizing on it for the future is fine.
> 
>  
> 
> In any case, RDMA is a high performance protected channel considered to be secure by its nature. If an RDMA protocol were run over a network tunnel, it would be the responsibility of the tunnel to implement authentication and encryption. And access rights of particular nodes and/or users is defined in higher layers of NFS, and so is unaffected by the fact that this is running over RDMA.
> 
>  
> 
> Bottom line is there are no security considerations. The security considerations section refers readers to RFC5666bis (which is about NFS over RDMA generally rather than the specific issue of callbacks). This seems appropriate.
> 
> 
> 
> If I were to make one comment it's that I don't like the terminology "backwards".  I might have used "reverse".  "Backwards" has a somewhat negative connotation, and it's slightly confusing when discussing "Backward Credits".  I'd think a "backwards credit" would be taking away credits from someone.  "Reverse credits" would be just as bad, but perhaps "reverse-direction credits" might be clear.

At first blush, this suggestion seems like an improvement to me. I'll need to
revisit the document to ensure that "reverse" and "reverse-direction" do not
introduce any specific issues. I'll consider this change for the next revision
if I don't hear objections.

--
Chuck Lever