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

[Yaron Sheffer <[e-mail]>]

Hi Chuck,

Please see below. Sorry for the delay.

Thanks,
	Yaron

On 1/27/20, 17:01, "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.

YS: but "inherits the security considerations" is more specific than merely referring the reader to the RFC. I suggest to reword.
    
    
    > - 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.

YS: so we can say this is de facto required and include the citation.
    
    
    > - 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.

YS: so please mention that, something like: RFC 5042 recommends IPsec as the default security solution, however for the InfiniBand and RoCE use cases, typically no transport-level security protocol is implemented.
    
    
    > - 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.

YS: I am an outsider to this community, but my own experience is that it's very difficult to predict these things. So we should maybe qualify this statement by saying it only refers to the data fields defined here, and not to any potential future extensions.
    
    
    --
    Chuck Lever