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

[Chuck Lever <[e-mail]>]

Sorry, I'm not sure how Magnus got dropped.


> On Apr 27, 2020, at 11:45 AM, Chuck Lever <[e-mail]> wrote:
> 
>> On Apr 27, 2020, at 11:11 AM, Trond Myklebust <[e-mail]> wrote:
>> 
>> On Mon, 27 Apr 2020 at 10:21, Chuck Lever <[e-mail]> wrote:
>> 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 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?

"to drop an out-of-session RPC Call has been removed from this section?"


>  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 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
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever