Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06

[Chuck Lever <[e-mail]>]

Following up...

> On Jan 27, 2020, at 10:01 AM, Chuck Lever <[e-mail]> wrote:
> 
> Hello Yaron-
> 
> Thanks for your review and comments. I will respond to your comments
> below, then we can determine how to clarify the text to improve matters.
> 
> 
>> On Jan 26, 2020, at 3:26 PM, Yaron Sheffer via Datatracker <[e-mail]> wrote:
>> 
>> Reviewer: Yaron Sheffer
>> Review result: Has Issues
>> 
>> The document defines limited parameter negotiation for RPC-RDMAv1, using a
>> private message sent over the underlying transport protocol (e.g., InfiniBand).
>> 
>> The document is clear enough, until it comes to the Security Considerations. As
>> a newcomer to this domain, there are several points that I fail to understand:
>> 
>> - The CM Private Data described here is not one of the messages of the RPC-RDMA
>> protocol. So how can it "inherit the security considerations of the protocols
>> it extends," - where this refers to RPC-RDMA?
> 
> The private data is conveyed on the same transport connection as the
> other messages in RPC-over-RDMA. The exchange of private data is part
> of the connection handshake, and does not appear after the connection
> is established.
> 
> The intended purpose of this paragraph is introductory, referring the
> reader to the Security Considerations section of RFC 8166 as background
> material.
> 
> 
>> - The next paragraph explains that the integrity is ensured by use of RC QP
>> (whatever that is). But there's no mention of this entity in RFC 8166, which is
>> supposed to define the security for this protocol. (Or in RFC 5042, for that
>> matter).
> 
> That does seem to be an omission of background material in these documents.
> 
> The queue pair (QP) type used for RPC-over-RDMA is Reliable Connected (RC).
> This is part of the RDMA Verbs API, thus it is not defined in any
> published IETF document.
> 
> However, a relevant definition can be found in Section 9.7.7 of
> 
> InfiniBand Trade Association, "InfiniBand Architecture Specification Volume
> 1", Release 1.3, March 2015. Available from https://www.infinibandta.org/
> 
> Section 8.1.1 of RFC 8166 discusses one aspect of Reliable Connected behavior
> but does not provide an adequate citation. The document as a whole does not
> make a specific compliance statement about the use of RC QPs.
> draft-ietf-nfsv4-rpcrdma-version-two rectifies that omission.
> 
> However, the protocol framework depends on the semantics of RC QPs, thus
> RPC-over-RDMA version one implementations to date use only the RC QP type.
> That makes it rather a de facto requirement up to this point.

To address the above two comments, I've updated the Security Considerations
section to read:

6.  Security Considerations

   The Private Data extension specified in the current document inherits
   the security considerations of RPC-over-RDMA version one [RFC8166].
   The reader is directed to the Security Considerations section of that
   document for further discussion.  Additional analysis of RDMA
   transport security appears in the Security Considerations section of
   [RFC5042].

   Improperly setting one of the fields in a version 1 Private Message
   can result in an increased risk of disconnection (i.e., self-imposed
   Denial of Service).  There is no additional risk of exposing upper-
   layer payloads.


>> - I am usually suspicious of pre-2010 RFCs that recommend IPsec as a
>> per-protocol solution (RFC 5042, Sec. 5.4.3). Is IPsec deployed in real life to
>> protect these protocols, and if so, does it also protect the new CM Private
>> Data?
> 
> IPsec is appropriate for iWARP (defined in the RFC 504x series), as iWARP
> can operate on public untrusted networks. Typically IPsec is implemented
> along side iWARP in NIC hardware, and thus is relatively transparent to
> the host (aside from initial configuration).
> 
> When deployed, IPsec would establish a protected channel before iWARP
> operations are exchanged, and thus would protect the exchange of private
> data that occurs as each QP connection is established.
> 
> IPsec is not used for InfiniBand or RoCE. Deployment of these fabrics is
> typically in monolithic security environments.

I'm not clear whether this issue is in the scope of cm-pvt-data.


>> - And then after saying that integrity protection is ensured, we say that even
>> if integrity was compromised and the parameters were modified anyway, no
>> problem, this would only result in "self imposed denial of service". Even if
>> true for the currently negotiated parameters, this cannot be true for every
>> conceivable parameter that may be added in the future.
> 
> That's correct.
> 
> Practically speaking, even though we made this private data mechanism
> extensible, we are already busy creating an RPC-over-RDMA version two,
> where the same exchange is done via RPC-over-RDMA messages rather than
> via CM Private Data. It's not likely that cm-pvt-data itself will ever
> be extended.

To address this comment, I've added a paragraph to the end of Section 5
"Updating the Message Format":

   In addition to describing the structure of a new format version, any
   document that extends the Private Data format described in the
   current document must discuss security considerations of new items
   exchanged between connection peers.


--
Chuck Lever