Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

Chuck Lever <chuck.lever@oracle.com> Thu, 23 April 2020 15:51 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 6A6BA3A0AE6 for <nfsv4@ietfa.amsl.com>; Thu, 23 Apr 2020 08:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 lKufxAA6bqYp for <nfsv4@ietfa.amsl.com>; Thu, 23 Apr 2020 08:51:08 -0700 (PDT)
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 88D723A0AD9 for <nfsv4@ietf.org>; Thu, 23 Apr 2020 08:51:08 -0700 (PDT)
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 03NFmdce178228; Thu, 23 Apr 2020 15:51: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-2020-01-29; bh=7EbIgY2iNvsi2jxfQ18HJKYCwiDfXjamBnofnh3mJW4=; b=dbtvAbtAmoDQjIuPWTbGVcCIQp65tD5qVds2azTtDOsNf8wYwXQfxFdMzst9TggX39Yn VAzo1UQlHFDac/1JYFr+4Vc9Viu2ELwSXS5ROlL7IBdqFaziRuWIUld1pLfN1Hwt/3vK yPqB5RZ3iGiLADJYAVCf7lEWgtNCio5SD3ZrqYwm8wZa9bAd1Pj9deeNGaJ7R50Vmo1u Vz9rMYJtRjmiKcHKAAueMQleR2IoX0S9gG0Pv5JmhvDgGbokn5unS4prBL+LHhdnIbRU vXYEPwAb5xIfeKveza3I7rjMZf0BsOwzqBc3aUtC/BTTVqb+xE/F1V2eEp0wZgvSRQ9u Gg==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 30grpgwvkr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Apr 2020 15:51:03 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03NFgbA9069293; Thu, 23 Apr 2020 15:49:03 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 30gbbmde9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Apr 2020 15:49:02 +0000
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03NFn1Fd031763; Thu, 23 Apr 2020 15:49:01 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 23 Apr 2020 08:49:01 -0700
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: <0c882df033889200e038e068ba6d6977520072bf.camel@ericsson.com>
Date: Thu, 23 Apr 2020 11:48:59 -0400
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>, Trond Myklebust <trondmy@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB87D726-1A4C-4BAD-B67E-5869BF147646@oracle.com>
References: <VI1PR0702MB3775838FD12AB8A89392C17B95C90@VI1PR0702MB3775.eurprd07.prod.outlook.com> <FA2D661E-A787-4772-8F9D-A7594AE82F38@oracle.com> <CADaq8jciLWhL_FMmPcsdrVVS=9Gee8SYAsqi36H5v9iuNo7Pgw@mail.gmail.com> <E414F060-532B-4017-AC7E-5869884B2153@oracle.com> <e5796752c6204ffdd78503b1a9c9045cfd761e52.camel@gmail.com> <F9AC44CE-750E-416A-944D-E2382524020E@oracle.com> <19d2513b1093fc71223e361afca90d1a1ad6183a.camel@gmail.com> <E8D24949-C2A3-463A-953F-FAE7F46D4D23@oracle.com> <4e7912c6c55680f50b05aaa2cdc98f59733cd5b2.camel@ericsson.com> <C89BF8F3-7F65-4995-9CDB-CC1673E01463@oracle.com> <7833b21f09aaffdb35e1a578e2a07b533002d318.camel@ericsson.com> <7B26B15B-DE0C-4B6C-BBB0-D8F7B00EF328@oracle.com> <HE1PR0702MB3772D2EF118A844C6527171995D20@HE1PR0702MB3772.eurprd07.prod.outlook.com> <5CC44355-69D5-4C26-A976-FBECB182033D@oracle.com> <6f44c1ed7d6b4889cc2fdf6597fa032c32a98c75.camel@ericsson.com> <3FE13967-9805-4808-90ED-851B5FEF38DD@oracle.com> <0c882df033889200e038e068ba6d6977520072bf.camel@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9600 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 suspectscore=0 mlxlogscore=689 adultscore=0 mlxscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004230122
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9600 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=739 mlxscore=0 lowpriorityscore=0 adultscore=0 suspectscore=0 bulkscore=0 clxscore=1015 malwarescore=0 phishscore=0 spamscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004230122
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/CjckhGv2aqvKmFGDt9YeEt0ePE0>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls
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: Thu, 23 Apr 2020 15:51:10 -0000


> On Apr 23, 2020, at 3:27 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> 
> Hi,
> 
> With the additional 
> 
> On Wed, 2020-04-22 at 15:49 -0400, Chuck Lever wrote:
>> After reviewing Section 9 of tls-dtls37, IMO:
>> 
>> - the explicit reference to tls-dtls-connection-id can be removed
>> - the discussion of connectionless operation should be dropped
>> - the strong RECOMMENDATION to use connected operation should be dropped
>> - rpc-tls should REQUIRE the use of the CID extension for RPC-on-DTLS
> 
> To try to clarify this REQUIRE a bit. I think what you mean is that the proposal
> is: It is mandatory to implement CID. Which implies that client include the CID
> extension in the handshake. However if that indicates a CID non-zero value, or a
> zero-length value indicating support but no desire to use it in server to client
> direction is up to the client. Simular it will be up to the server to actually
> use it. 
> 
>> - rpc-tls should provide implementation guidance to RPC server implementers
>> to use large CIDs for popular RPC services.
>> 
>> Does that sound right? If so I will propose replacement text here on list.

For completion, here is the current text of Section 5.1.2:


5.1.2.  Protected Operation on UDP

   RPC over UDP is protected using the Datagram Transport Layer Security
   (DTLS) protocol [I-D.ietf-tls-dtls13].

   Using DTLS does not introduce reliable or in-order semantics to RPC
   on UDP.  Each RPC message MUST fit in a single DTLS record.  DTLS
   encapsulation has overhead, which reduces the effective Path MTU
   (PMTU) and thus the maximum RPC payload size.  The use of DTLS record
   replay protection is REQUIRED when transporting RPC traffic.

   As soon as a client initializes a UDP socket for use with an RPC
   server, it uses the mechanism described in Section 4.1 to discover
   DTLS support for an RPC program on a particular port.  It then
   negotiates a DTLS session.

   For RPC-on-DTLS, each DTLS handshake MUST include the connection_id
   extension described in Section 9 of [I-D.ietf-tls-dtls13].  RPC-on-
   DTLS peer endpoints SHOULD provide a ConnectionID with a non-zero
   length.  Endpoints implementing RPC programs that expect a
   significant number of concurrent clients should employ ConnectionIDs
   of at least 4 bytes in length.

   Sending a TLS Closure Alert terminates a DTLS session.  Subsequent
   RPC messages exchanged between the RPC client and server are no
   longer protected until a new DTLS session is established.


--
Chuck Lever