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

From: Yaron Sheffer via Datatracker <[email-masked]>
Date: Sun, 26 Jan 2020 12:26:29 -0800

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

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

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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 27 Jan 2020 10:01:12 -0500

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 <[email-masked]> wrote:
> 
> Reviewer: Yaron Sheffer

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.

> supposed to define the security for this protocol. (Or in RFC 5042, for that

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.

> protect these protocols, and if so, does it also protect the new CM Private

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.

> 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

---

From: Chuck Lever <[email-masked]>
Date: Wed, 29 Jan 2020 13:11:18 -0500

Following up...

> On Jan 27, 2020, at 10:01 AM, Chuck Lever <[email-masked]> wrote:
> 
> Hello Yaron-
> 

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.

> typically in monolithic security environments.

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

> via CM Private Data. It's not likely that cm-pvt-data itself will ever

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

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 29 Jan 2020 23:01:12 +0200

Hi Chuck,

Please see below. Sorry for the delay.

Thanks,
	Yaron

On 1/27/20, 17:01, "Chuck Lever" <[email-masked]> wrote:

    Hello Yaron-

    

YS: but "inherits the security considerations" is more specific than merely referring the reader to the RFC. I suggest to reword.

    

    

YS: so we can say this is de facto required and include the citation.

    

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.

    That's correct.

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

---

From: Chuck Lever <[email-masked]>
Date: Thu, 30 Jan 2020 07:09:14 -0800 (PST)

Hello Yaron-

The Security Considerations section now reads as follows:

   The reader is directed to the Security Considerations section of
   [RFC8166] for background and further discussion.

   The RPC-over-RDMA version 1 protocol framework depends on the
   semantics of the Reliable Connected (RC) queue pair (QP) type, as
   defined in Section 9.7.7 of [IBA].  The integrity of CM Private Data
   and the authenticity of its source are ensured by the exclusive use
   of RC queue pairs.  Any attempt to interfere with or hijack data in
   transit on an RC connection results in the RDMA provider terminating
   the connection.

   Additional analysis of RDMA transport security appears in the
   Security Considerations section of [RFC5042].  That document
   recommends IPsec as the default transport layer security solution.
   When deployed with iWARP, IPsec establishes a protected channel
   before any iWARP operations are exchanged, thus it protects the
   exchange of Private Data that occurs as each QP is established.
   However, IPsec is not available for InfiniBand or RoCE deployments.
   Those fabrics rely on physical security and cyclic redundancy checks
   to protect network traffic.

   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 after exchanging the Private Message format defined in
   the current document.

   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 data
   items exchanged between connection peers.

--
Chuck Lever

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 30 Jan 2020 18:28:45 +0200

Looks good. Thank you very much!

	Yaron

On 1/30/20, 17:10, "Chuck Lever" <[email-masked]> wrote:

    Hello Yaron-

    

    

    --
    Chuck Lever