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

[Magnus Westerlund <[e-mail]>]

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. 

I think other WG paricipants should provide input here. 

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]
----------------------------------------------------------------------