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

[Chuck Lever <[e-mail]>]

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


  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