Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-rpcrdma-cm-pvt-data
Chuck Lever <chuck.lever@oracle.com> Mon, 16 December 2019 14:53 UTC
Return-Path: <chuck.lever@oracle.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21D12007C for <nfsv4@ietfa.amsl.com>; Mon, 16 Dec 2019 06:53:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmOGhDlzc5Iv for <nfsv4@ietfa.amsl.com>; Mon, 16 Dec 2019 06:53:04 -0800 (PST)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D751200B1 for <nfsv4@ietf.org>; Mon, 16 Dec 2019 06:53:04 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xBGEcp4k063074; Mon, 16 Dec 2019 14:53:03 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=FvE2kxGUcup8eW2ojYPaVEDux7ylZflP2DYDkiiROz4=; b=TIWoIAWqVLQJRisPyT2FLpt8+yIomYLM5iUkWbG5gFwah+zQ+UoKBDiYZpJRrUKkBShm iss2I/JXXQFFCMdBlmpdxGUY4BhsYMImBCteN/VVSgd3kuYKaISxuxydN3MS9LK8Q1Rh A7MBFhzU0302NvkzcUBUDfRrcJN5Fw1QqP/qsmrPpM+nlDu0AY/DmraurKVFdtl0o/U8 cIFaCIEeQpRhPBONZ5BH6YXr+2IDqZTbz3ZAv9O70Nr/77NxYEXmX2qQiO41GTDuEjE1 nvOq349u1AZOju6x4eqwl/brHrGvo6J+37LtTP2b5+Ny9MBHxBr/7/MMjw4J8tNhSk7F Xg==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2wvrcqyydg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Dec 2019 14:53:03 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xBGEd8qO099120; Mon, 16 Dec 2019 14:53:02 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 2ww9vmb0vv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Dec 2019 14:53:02 +0000
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xBGEr00W007949; Mon, 16 Dec 2019 14:53:00 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Dec 2019 06:53:00 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <14e44b2a-f6ed-9b7b-2e28-fb4016be173b@talpey.com>
Date: Mon, 16 Dec 2019 09:52:59 -0500
Cc: nfsv4@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <DB9F91F9-455C-4710-949F-01A9BEEE16CA@oracle.com>
References: <863D1C52-3FCB-47EF-9DEA-4BE8CEF51D6C@oracle.com> <14e44b2a-f6ed-9b7b-2e28-fb4016be173b@talpey.com>
To: Tom Talpey <tom@talpey.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9472 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912160131
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9472 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912160131
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/2SNBoavMfv_LiYy7OJPBIuo3ROc>
Subject: Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-rpcrdma-cm-pvt-data
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2019 14:53:06 -0000
> On Dec 16, 2019, at 9:36 AM, Tom Talpey <tom@talpey.com> wrote: > > On 12/15/2019 3:48 PM, Chuck Lever wrote: >> As a result of expert review, changes are needed to Section 4.1.2 >> to clarify the purpose and implementation guidance of the Format >> Identifier field. >> I propose that the new Section read (in its entirety): >> 4.1.2. Amongst Implementations of Other Upper-Layer Protocols > > That first word is a very odd one in a section title. Would > "Interoperability With" be more meaningful? I will review the titles of the sub-sections here. >> The Format Identifier field in the message format defined in this >> document is provided to enable implementations to distinguish RPC- >> over-RDMA version 1 Private Data from private data inserted at layers >> below RPC-over-RDMA version 1. An example of a layer below RPC-over- > > "Below" is problematic here. The RFC6581 MPA enhanced connection > processing can insert private data at the start of the field, and > it is "below" RPC in the stack, but the peer's RFC6581 processing > strips it off. Therefore, of RPC is the "lowest upper layer" in > such a stack, there is no issue. > > However, there might well be other lower layers, with different > behaviors, injecting their own private data payloads. Or indeed, > upper layers. And these payloads may choose to append, or prepend > to the buffer. OK. Are you requesting a change to this paragraph? >> RDMA version 1 that makes use of CM Private Data is iWARP, via the >> MPA enhancement described in [RFC6581]. >> During connection establishment, an implementation of the extension >> described in this document checks the Format Identifier field before >> decoding subsequent fields. If the RPC-over-RDMA version 1 CM >> Private Data Format Identifier is not present as the first 4 octets, > > So, just to be clear - this introduces a new requirement on other > layers over the same connection. They MUST NOT inject private data > at the beginning of the buffer, or if they do, they MUST strip it > off. > >> an RPC-over-RDMA version 1 receiver MUST ignore the CM Private Data, >> behaving as if no RPC-over-RDMA version 1 Private Data has been >> provided (see above). > > And, if the prior requirement is not made, then the RPC layer needs > to scan the prvate data rather carefully to see if the identifier, > and the payload associated with it, is present somewhere in the > private data. You might have misread this paragraph. I don't think there's a need for any new requirements: the paragraph states if the first word in the buffer is not the RPC-over-RDMA Format Identifier, then the receiver ignores the CM private data. No other scanning is necessary, it's a fail-safe design since the CM private data contains only hints. >> Because the Format Identifier field is newer than some other >> potential users of private data (such as iWARP), there is a risk that >> a lower layer might inject its own private data with a payload >> somehow containing the identifier of RPC-over-RDMA version 1. It is > > Well, *and* not strip it off. This could happen if the peer implemented > a lower layer that wasn't recognized by the receiver, and the data > simply passed up. See previous paragraph. > >> recommended that RPC-over-RDMA version 1 implementations perform >> additional checks on the content of received CM private data before >> making use of it. > > "Additional checks" is pretty vague. Are there any specific requirements? Would "perform sanity checks on the content" be preferable? -- Chuck Lever
- [nfsv4] Proposed updates to draft-ietf-nfsv4-rpcr… Chuck Lever
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… David Noveck
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… Tom Talpey
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… Chuck Lever
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… Tom Talpey
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… David Noveck
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… Tom Talpey
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… Chuck Lever
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… Chuck Lever
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… David Noveck
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… Tom Talpey
- Re: [nfsv4] Proposed updates to draft-ietf-nfsv4-… Chuck Lever