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

[Chuck Lever <[e-mail]>]

Hi Magnus-

> On Apr 27, 2020, at 4:47 AM, Magnus Westerlund <[e-mail]> 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 think other WG paricipants should provide input here.

I agree, comments welcome.


> Cheers
> 
> Magnus 
> 
> On Thu, 2020-04-23 at 11:48 -0400, Chuck Lever wrote:
>>> On Apr 23, 2020, at 3:27 AM, Magnus Westerlund <
>>> [e-mail]> 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
>> 
>> 
>> 
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------

--
Chuck Lever