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

[Chuck Lever <[e-mail]>]

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.


> - 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