Following up... > On Jan 27, 2020, at 10:01 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> 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 <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. 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
