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

Chuck Lever <chuck.lever@oracle.com> Tue, 28 April 2020 21:32 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 0A9413A0926 for <nfsv4@ietfa.amsl.com>; Tue, 28 Apr 2020 14:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L3=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 Xo6uULepxD6M for <nfsv4@ietfa.amsl.com>; Tue, 28 Apr 2020 14:32:11 -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 9C8353A0922 for <nfsv4@ietf.org>; Tue, 28 Apr 2020 14:32:11 -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 03SLNYNb181700; Tue, 28 Apr 2020 21:32:06 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=i0GV/ES3k7wTMND9MrC6hJky4mZv2ToyufU1VXEaOms=; b=YFK2cd70vjFCQsy1y00mibZTg6tCKqEh6q0VchaLQfVUj9UqkZNZE1dgNJllUb3mXqCy BIQxMS/h6mWYIL1ow0pqZrD13uh7aDwHDO5BXgOkQSvZC0+tRgzo7RWuCE3VkjzoTDJ5 chEU7tvpCN9cI3+lDEUjQAHRYLoJigzfi+IrT0+JdeXY2aQATk2oAuZz0Cbg5BlKmrYL sD22G61CVirzCNZz5YndRmeVqolQpdPyaPpueT4VlLK+/pKAIdlxoQpCEOsdYhPgOqWF Qy2/s3cK8pMeH9rEwBwY0FPrx59vNzx62hDPeJ5q3xvaNVZ60AfsrwxpPnCNGlc2gGzM jQ==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 30p01ns16a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Apr 2020 21:32:06 +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 03SLN2lH114347; Tue, 28 Apr 2020 21:32:06 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 30my0eesuq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Apr 2020 21:32:05 +0000
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03SLW5cM024448; Tue, 28 Apr 2020 21:32:05 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 Apr 2020 14:32:05 -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: <05ce7d9a9600b2c516605acad041dea687595377.camel@ericsson.com>
Date: Tue, 28 Apr 2020 17:32:04 -0400
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BEF788D4-646A-445A-A43E-88F1857E3E57@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> <BB87D726-1A4C-4BAD-B67E-5869BF147646@oracle.com> <ff05325b40e8be64055af25b8dd22c8323565fd6.camel@ericsson.com> <83499FF8-BF16-46F4-9485-9694E3BB81D5@oracle.com> <CAABAsM5tUauO3tKAmSbqXKQ6zNRRMpM6Gx9BeR1WTDddHLP+og@mail.gmail.com> <94F6D6BE-F62E-4FAA-91E4-D70C6C69C581@oracle.com> <CAABAsM7w=mMV3XjsbTdHcCZ5QRTSq0BrVdLyqV1Rp-0zX6ObOw@mail.gmail.com> <73670430-85DE-4195-B9CB-B32DD6400A4F@oracle.com> <05ce7d9a9600b2c516605acad041dea687595377.camel@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Trond Myklebust <trondmy@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004280166
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 clxscore=1015 phishscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004280166
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/VBj20RoaaYW1ICyqovaQYElpJfs>
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: Tue, 28 Apr 2020 21:32:15 -0000


> On Apr 28, 2020, at 7:23 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> 
> On Mon, 2020-04-27 at 17:02 -0400, Chuck Lever wrote:
>>> On Apr 27, 2020, at 4:37 PM, Trond Myklebust <trondmy@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Mon, 27 Apr 2020 at 11:45, Chuck Lever <chuck.lever@oracle.com> wrote:
>>> 
>>> 
>>>>> On Apr 27, 2020, at 11:11 AM, Trond Myklebust <trondmy@gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, 27 Apr 2020 at 10:21, Chuck Lever <chuck.lever@oracle.com>
>>>>> wrote:
>>>>> Hi Magnus-
>>>>> 
>>>>>> On Apr 27, 2020, at 4:47 AM, Magnus Westerlund <
>>>>>> magnus.westerlund@ericsson.com> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I think that text works. However, that now recommends using a non-zero
>>>>>> connection ID. From my perspective which have no implementation stake
>>>>>> into this,
>>>>>> this is fine. However, I would note that this backtracks on what was
>>>>>> said just a
>>>>>> few messages ago.
>>>>> 
>>>>> It's always possible I've gotten something wrong. However, I realized
>>>>> that RPC
>>>>> on UDP permits an RPC server to use a different network path to send a
>>>>> Reply
>>>>> than the path the client used to send the matching Call. IIUC a
>>>>> substantial CID
>>>>> is needed to deal correctly with that situation.
>>>>> 
>>>>> 
>>>>> I don't think that matters. The server should always authenticate to the
>>>>> client during the D/TLS handshake, so there should be no ambiguity about
>>>>> the source of the replies.
>>>> 
>>>> The server is free to reply via any of its network interfaces. In other
>>>> words, it can perform the handshake using one 5-tuple, then send replies
>>>> via another (or send them via a mix of 5-tuples).
>>>> 
>>>> A CID is needed to handle NAT rebinding in any case. But IIUC rebinding
>>>> would look like the client's 5-tuple changing, not the server's.
>>>> 
>>>> The question in mind is whether a DTLS session will be perturbed by the
>>>> server's or client's 5-tuple changing. Magnus, can you elaborate on your
>>>> earlier request for a clear statement about this in this section? Is this
>>>> no longer a concern now that the REQUIREMENT to drop an out-of-session
>>>> RPC Call?
>>>> 
>>>> 
>>>>  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.
>>>> 
>>>> Also, I'm not certain if SHOULD is correct here. Instead, "should" or
>>>> "MUST" might be less ambiguous. However, if we all agree the statement is
>>>> totally unnecessary, it can be replaced or dropped.
>>>> 
>>> 
>>> I'm saying that it doesn't matter from what network interface, or indeed
>>> which breed of carrier pigeon the server chooses, The client can still
>>> authenticate the reply as being genuine from the fact that the server
>>> authenticated to it at the start of the DTLS session. As long as this is
>>> still the same session, then the client can ignore any changes to the
>>> network topology.
>> 
>> My reading of draft-ietf-tls-dtls-connection-id suggests that is not
>> the case for DTLS 1.2 and later.
>> 
>> Abstract says:
>> 
>>   A CID is an identifier carried in the record layer header that gives
>>   the recipient additional information for selecting the appropriate
>>   security association.  In "classical" DTLS, selecting a security
>>   association of an incoming DTLS record is accomplished with the help
>>   of the 5-tuple.  If the source IP address and/or source port changes
>>   during the lifetime of an ongoing DTLS session then the receiver will
>>   be unable to locate the correct security context.
>> 
>> Further, the Introduction states:
>> 
>>   In the current version of DTLS, the IP address and port of the peer
>>   are used to identify the DTLS association.  Unfortunately, in some
>>   cases, such as NAT rebinding, these values are insufficient.  This is
>>   a particular issue in the Internet of Things when devices enter
>>   extended sleep periods to increase their battery lifetime.  The NAT
>>   rebinding leads to connection failure, with the resulting cost of a
>>   new handshake.
>> 
>> Unless I'm reading this wrong, if either peer sees a DTLS datagram from
>> a different IP address than was used during the DTLS handshake, it's not
>> going to be able to associate that with a previously established DTLS
>> session... unless there's a CID.
>> 
>> The DTLS handshake and the subsequent DTLS record exchanges are two
>> separate protocols. The CID is exactly the material that the peers need
>> to determine that the remote sender is the same peer that established
>> that DTLS session.
>> 
> 
> Exactly, my understanding was that DTLS without connection IDs uses the 5-tuple
> and that needs to be reversed when replying. This is also definitely true in
> environments with NATs and Firewalls to hit the stateful pinholes. I understand
> that this is not the case in DC deployments. 
> 
> If it is common for RPC over UDP to not use reversed 5-tuples then I think using
> non-zero CIDs is a requirement. I think you should write that little motivation
> into the text to make people aware that this may not be the environment that
> people from outside of NFSv4 are used to. Because that clearly surprises me.

I've made the following changes:

- REQUIRED the use of the connection_id extension, with a justification

- REQUIRED the use of a positive length CID

- Added an RFC Editor's Note to pick up the extension number of the
connection_id extension once that is known

The section now reads:


5.1.2.  Protected Operation on UDP

   RFC Editor: In the following section, please replace TBD with the
   connection_id extension number that is to be assigned in
   [I-D.ietf-tls-dtls-connection-id].  And, please remove this Editor's
   Note before this document is published.

   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.

   Multi-homed RPC clients and servers may send protected RPC messages
   via network interfaces that were not involved in the handshake that
   established the DTLS session.  Therefore, when protecting RPC
   traffic, each DTLS handshake MUST include the "connection_id(TBD)"
   extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC-
   on-DTLS peer endpoints MUST 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