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 <noreply@xxxxxxxx> 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. > - 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. > - 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. -- Chuck Lever -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
