[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.
- [secdir] Secdir last call review of draft-ietf-nf… Yaron Sheffer via Datatracker
- Re: [secdir] [nfsv4] Secdir last call review of d… Chuck Lever
- Re: [secdir] [nfsv4] Secdir last call review of d… Chuck Lever
- Re: [secdir] [nfsv4] Secdir last call review of d… Yaron Sheffer
- Re: [secdir] [nfsv4] Secdir last call review of d… Chuck Lever
- Re: [secdir] [nfsv4] Secdir last call review of d… Yaron Sheffer