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

Yaron Sheffer via Datatracker <noreply@ietf.org> Sun, 26 January 2020 20:26 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A1E120043; Sun, 26 Jan 2020 12:26:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yaron Sheffer via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpcrdma-cm-pvt-data.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Yaron Sheffer <yaronf.ietf@gmail.com>
Message-ID: <158007038921.30641.13334124837519126164@ietfa.amsl.com>
Date: Sun, 26 Jan 2020 12:26:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/hY6OTDbplzp9uONAvEjkcfa-N4A>
Subject: [secdir] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jan 2020 20:26:30 -0000

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.