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

Chuck Lever <chuck.lever@oracle.com> Fri, 06 March 2020 16:47 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 DBB423A0AB9 for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 08:47:01 -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 gnlX7ZBRUAfo for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 08:47:00 -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 1519F3A0A81 for <nfsv4@ietf.org>; Fri, 6 Mar 2020 08:46:59 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 026GNBRU061741; Fri, 6 Mar 2020 16:46:59 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=gF5kp/1u92EOF+bb3qMJMZ40k/kkYR04S312BeAexTs=; b=c4GDQ8tyOvw1bVz01Mz7UMuRGDHrgy91sx5fM9LzS6ofTtH7+CujaR4yMNh8iaCMz0K9 BWk/SYU3q8XRRexOybVDBm+zKZH4/E4R9M7+UGD/Iu5C6uukZ1COcqnh47H4g310lXn2 munfwa02dyksGIREF1yh7yBZ1kWPCVG32OWAe/ZqOUPOr53MzqygBbdTfzf4DjlnnLIF QTn1I9oy1tYszlO+61PE9ah6kQVaIMOvkMmLfk9pGsRugemxi5cIJqAqZl5JwkLmZnrN hUbRqfZNbWMoAjTuxV3HKy0Jcw0pPXa4XAUYn9sVr44K9rfFA+IVxIN0V+yKz3sLAwt8 GQ==
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 2yghn3r3q6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 Mar 2020 16:46:59 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 026Gh4Q3177916; Fri, 6 Mar 2020 16:46:58 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 2yjuf42ydg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 Mar 2020 16:46:58 +0000
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 026GkvAA017050; Fri, 6 Mar 2020 16:46:57 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Mar 2020 08:46:57 -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: <e70711cc-9d7e-a531-deec-7b09d1837c0b@talpey.com>
Date: Fri, 6 Mar 2020 11:46:56 -0500
Cc: nfsv4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C20F1A2-6FCE-4650-AB84-7C158552D9F8@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> <276AED2C-DD15-44F6-BA17-D74376B51D98@oracle.com> <e70711cc-9d7e-a531-deec-7b09d1837c0b@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=9552 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 malwarescore=0 bulkscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003060110
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9552 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0 spamscore=0 impostorscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 bulkscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003060110
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/RDRGAzFa2axLtnoDVcBSDP5Q_-k>
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: Fri, 06 Mar 2020 16:47:02 -0000


> On Mar 3, 2020, at 11:10 PM, Tom Talpey <tom@talpey.com> wrote:
> 
> On 3/3/2020 6:45 AM, Chuck Lever wrote:
>> 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.
> 
> I agree with the changes, but stylistically I might suggest rearranging
> the sentences for emphasis and flow, such as:
> 
> The integrity of CM Private Data and the authenticity of its source
> are ensured by the exclusive use of reliable queue pairs. iWARP queue
> pairs are always reliable connections [RFC5040]. 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]. Any attempt to interfere with or hijack data
> in transit on a reliable connection in either transport protocol
> results in the RDMA provider terminating the connection.
> 
> Just a suggestion!

Agreed, and pushed to my Editor's copy.


> Tom.
> 
>>>> 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
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever