Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)

Chuck Lever <chuck.lever@oracle.com> Tue, 03 March 2020 14:45 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 5746E3A0CCA; Tue, 3 Mar 2020 06:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 TxRWEST_cu4B; Tue, 3 Mar 2020 06:45:19 -0800 (PST)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 B7C433A0CC0; Tue, 3 Mar 2020 06:45:19 -0800 (PST)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 023ENsbH010359; Tue, 3 Mar 2020 14:45:13 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-2020-01-29; bh=SS7HJxwCDSkAZ0LzoItgC1cx3VVayKuHomoE9vM9+hE=; b=huYxr1JEEQ5ywJ8GbIA6rwzuOBsmcTTjdRDdFp6Cu2OLCwZqMB+2W9l6iyF7jV66ZDbI Dd7iFWi8SxkFysSAWOmD0xJ/h8TC6klIkkCWfYe469ukkYlk4rYzAiELauXtGZNCaZo1 EXrmgnCzgixul8jhIYUZhdBM7xsbit+XiB83+M/kstrdMrSco62+Mdif+z5c2+RpGQeS KJ4JHjnWsDePOoAIphrEM9dd9g132QAXaWIXKNJ3CSZyLveeElak80AKF5WlZtnNizeZ nrPuFdeKHYVh25W7ovl3fzaQb8UxuY0CBe+bfT7ZYIGKEiYZmiC/YGTJGkxLZ9MOTLt1 9w==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2yffcufrcd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Mar 2020 14:45:13 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 023Eh86R009188; Tue, 3 Mar 2020 14:45:12 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 2yg1gxk5wq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Mar 2020 14:45:12 +0000
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 023Ej8Mr011121; Tue, 3 Mar 2020 14:45:08 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Mar 2020 06:45:08 -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: <BE0ECB52-596B-467C-BEB4-D76319016E32@oracle.com>
Date: Tue, 03 Mar 2020 09:45:06 -0500
Cc: nfsv4-chairs <nfsv4-chairs@ietf.org>, NFSv4 <nfsv4@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpcrdma-cm-pvt-data@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <276AED2C-DD15-44F6-BA17-D74376B51D98@oracle.com>
References: <158216101788.17661.6926758160404035704.idtracker@ietfa.amsl.com> <E718C1B8-B96B-4A64-8B92-C4ABEC7B5E5F@oracle.com> <20200220195155.GJ97652@kduck.mit.edu> <e74002a7-e1f1-a738-20d4-fa7d3395dd66@talpey.com> <BE0ECB52-596B-467C-BEB4-D76319016E32@oracle.com>
To: Tom Talpey <tom@talpey.com>, Benjamin Kaduk <kaduk@mit.edu>, Roman Danyliw <rdd@cert.org>, Yaron Sheffer <yaronf.ietf@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9548 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003030110
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9548 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003030110
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/k-1LSJxcLJo2Ia3g7t0Vsbxrenw>
Subject: Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)
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: Tue, 03 Mar 2020 14:45:22 -0000

Hello -

> On Mar 1, 2020, at 1:13 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> 
> 
>> On Mar 1, 2020, at 12:24 PM, Tom Talpey <tom@talpey.com> wrote:
>> 
>> On 2/20/2020 11:51 AM, Benjamin Kaduk wrote:
>>> Hi Chuck,
>>> On Thu, Feb 20, 2020 at 10:13:26AM -0500, Chuck Lever wrote:
>>>> Hi Ben, thanks for your comments! Responses and questions below.
>>>> 
>>>> 
>>>>> On Feb 19, 2020, at 8:10 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
>>>>> 
>>>>> Benjamin Kaduk has entered the following ballot position for
>>>>> draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: No Objection
>>>>> 
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> introductory paragraph, however.)
>>>>> 
>>>>> 
>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>> 
>>>>> 
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/
>>>>> 
>>>>> ...
>>>>> Section 6
>>>>> 
>>>>>  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
>>>>> 
>>>>> It's interesting to see such a reference to [IBA], when IIUC the RFC
>>>>> 8166 protocol is not limited to Infiniband as the underlying transport.
>>>> 
>>>> Correct, RPC/RDMA can operate on iWARP and RoCE as well. However:
>>>> 
>>>> - both of those RDMA fabric types also support RC QPs, and
>>>> - [IBA] appears to be the only publication where "RC QP type"
>>>>   is defined, though I could be wrong.
>>>> 
>>>> I don't read this text as suggesting that RPC/RDMA cannot operate
>>>> on those alternate fabrics, but perhaps I am "too close to the
>>>> code".
>>> I don't read it that way, either; I was just noting that it was surprising
>>> that this is the only reference available.  If it is, then it is, though,
>>> so no need to change anything.
>> 
>> The term "RC" or "Reliable Connected" is an InfiniBand-specific term.
>> The iWARP protocol has neither a datagram nor unreliable mode, therefore
>> it is an "RC" transport by definition, in InfiniBand-speak.
>> 
>> I do agree that referring normatively to the IB Architecture is odd,
>> and perhaps unnecessary. Alternatively, the sentence could be relaxed
>> to avoid this IB-specific term, and describe the situation in an
>> informative way. "Supports RC-type Infiniband and iWARP Queue Pairs."
> 
> No objection to that phrasing, and that certainly explains why RFC 8166
> does not refer directly to RC.

Because this was directly commented on several times during IESG balloting,
I'm providing an update via this email thread. The new second paragraph of
the Security Considerations section will read:

   On InfiniBand, 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].  iWARP queue pairs have neither
   a datagram nor an unreliable mode, therefore they are always reliable
   connections [RFC5040].  The integrity of CM Private Data and the
   authenticity of its source are ensured by the exclusive use of
   reliable queue pairs.  Any attempt to interfere with or hijack data
   in transit on an RC connection results in the RDMA provider
   terminating the connection.

Also, the IBA reference has been moved back to the Informative References
subsection.

I will request these updates be made to the document during AUTH48, unless
there are objections or further corrections.


>> There is a document describing the iWARP consumer-visible semantics,
>> in 2003's https://tools.ietf.org/html/draft-hilland-rddp-verbs-00
>> However, this document was never adopted as an RDDP work item, and
>> was not developed further. It is nonetheless an excellent reference
>> and is frequently referred to.
>> 
>> Tom.
> 
> --
> Chuck Lever

--
Chuck Lever