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

[Trond Myklebust <[e-mail]>]

On Mon, 27 Apr 2020 at 11:45, 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?
>
>
>   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.


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