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

Chuck Lever <chuck.lever@oracle.com> Tue, 14 April 2020 20:53 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E913A0FB3 for <nfsv4@ietfa.amsl.com>; Tue, 14 Apr 2020 13:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level:
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1kIFXGTkx3o for <nfsv4@ietfa.amsl.com>; Tue, 14 Apr 2020 13:53:34 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83C13A0FB2 for <nfsv4@ietf.org>; Tue, 14 Apr 2020 13:53:32 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03EKqc0H100152; Tue, 14 Apr 2020 20:53:30 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2020-01-29; bh=RRd79RIgdmzqxXV+CFm/OnLTbeyVGXBXpLMTi74HrqM=; b=NWtf81aKySoZPR1Xp5j+gYLjKt6RG6WmPNBjXo04yb6ZlX9+vP1MbSxpClmE2pyMzZNY pbrsGtkNRrdly3hQGY4DS7o9TfL/mlJz5Nsl40KFCZaGhKFmaAeov6Np2AAquhC1F4Hd Q4Ygq4tuVkrgaaCZrWkVeAYBgEetFFKAXaGL20LFm337+VpFoUCeg+BHE/SmXs1izRfh yA3uC4AGWhUzhP6U7+fe2UkgBiOqjNykKTPsZWSLcI7BrEQY1IkN5EIbdV9AfEEm52gf tuBRTij42O13bzIoDxDeqVIET/SJfMZOAhZp+s1P45TnLznMLQll4knIjGTsWAXtGXtp Uw==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 30b5ar7ajj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Apr 2020 20:53:30 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03EKl7Jc075539; Tue, 14 Apr 2020 20:51:29 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 30ctab4tj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Apr 2020 20:51:29 +0000
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03EKpSR4024968; Tue, 14 Apr 2020 20:51:28 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Apr 2020 13:51:28 -0700
From: Chuck Lever <chuck.lever@oracle.com>
Message-Id: <138825BC-D5EE-4B35-A311-FC865F977763@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6192FBEF-421C-42C6-A26D-CA7A21CE9F9B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 14 Apr 2020 16:51:27 -0400
In-Reply-To: <CADaq8jeQDYDShhHAaRc-LOPX=93fo_WuaDADRyKZUYiu3g07VA@mail.gmail.com>
Cc: Trond Myklebust <trondmy@gmail.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
To: David Noveck <davenoveck@gmail.com>
References: <VI1PR0702MB3775838FD12AB8A89392C17B95C90@VI1PR0702MB3775.eurprd07.prod.outlook.com> <FA2D661E-A787-4772-8F9D-A7594AE82F38@oracle.com> <CADaq8jciLWhL_FMmPcsdrVVS=9Gee8SYAsqi36H5v9iuNo7Pgw@mail.gmail.com> <E414F060-532B-4017-AC7E-5869884B2153@oracle.com> <e5796752c6204ffdd78503b1a9c9045cfd761e52.camel@gmail.com> <F9AC44CE-750E-416A-944D-E2382524020E@oracle.com> <19d2513b1093fc71223e361afca90d1a1ad6183a.camel@gmail.com> <E8D24949-C2A3-463A-953F-FAE7F46D4D23@oracle.com> <CADaq8jeQDYDShhHAaRc-LOPX=93fo_WuaDADRyKZUYiu3g07VA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9591 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 spamscore=0 adultscore=0 mlxscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004140147
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9591 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 phishscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004140148
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/HFCXo0oEVaiBD8zECe5ynJsoKfk>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2020 20:53:42 -0000


> On Apr 14, 2020, at 3:05 PM, David Noveck <davenoveck@gmail.com> wrote:
> 
> I think your updates are fundamentally right but I will suggest some wording changes that
> I hope will clarify things. 
> 
> > The mechanism described in the current document interoperates fully
> > with RPC implementations that do not support TLS.  Depending on
> > policy, the use of TLS is automatically disabled in these cases.
> 
> First of all, if the server does not suport TLS, its use is disabled regardless of
> policy,  which is confusing.  "automatically" adds to the confusion.
> 
> Suggest the following replacement text:
> 
> The mechanism described in the current document is capable of
> interoperating fully with RPC implementations that do not support 
> TLS.  Subject to client or ULP-mandated policy, the use of the connection
> is continued without TLS protection or the connection is discarded in
> such cases.  

This section applies to TCP (connected) and UDP (connectionless) operation, thus
stating that "the use of the connection is continued ... or ... is discarded" is out of place
here. I'll try to adjust the second sentence.


> > RPC over UDP is protected using DTLS [I-D.ietf-tls-dtls13].  As soon as a client initializes 
> > a UDP socket for use with an unfamiliar server.
> 
> As written, this raises the issue of a UDP connection on a server that one is familiar with.  I 
> think your intention is that clients always do the same thing so I suggest changing "an 
> unfamiliar" to "a".

Fixed.


> On Tue, Apr 14, 2020 at 11:39 AM Chuck Lever <chuck.lever@oracle.com <mailto:chuck.lever@oracle.com>> wrote:
> 
> 
> > On Apr 9, 2020, at 6:51 PM, Trond Myklebust <trondmy@gmail.com <mailto:trondmy@gmail.com>> wrote:
> > 
> > On Thu, 2020-04-09 at 18:01 -0400, Chuck Lever wrote:
> >>> On Apr 9, 2020, at 5:42 PM, Trond Myklebust <trondmy@gmail.com <mailto:trondmy@gmail.com>>
> >>> wrote:
> >>> 
> >>> On Thu, 2020-04-09 at 17:02 -0400, Chuck Lever wrote:
> >>>>> On Apr 9, 2020, at 4:53 PM, David Noveck <davenoveck@gmail.com <mailto:davenoveck@gmail.com>>
> >>>>> wrote:
> >>>>> 
> >>>>>> Therefore with RPC-on-TLS we do not allow multiple RPC
> >>>>>> programs
> >>>>>> to share
> >>>>>> a TLS session. And we do not allow multiple RPC-on-TLS
> >>>>>> sessions
> >>>>>> per TCP
> >>>>>> connection.
> >>>>> 
> >>>>> That was my impression reading the document.  However, as you
> >>>>> point
> >>>>> out, the
> >>>>> document never clearly atated that. 
> >>>>> 
> >>>>>> For DTLS, the STARTTLS probe has to be done for each RPC
> >>>>>> program
> >>>>>> on each
> >>>>>> server. Only that one RPC program can use the established
> >>>>>> DTLS
> >>>>>> session.
> >>>>> 
> >>>>> OK with me.
> >>>>> 
> >>>>>> This means RPC-on-TLS robs us of some TCP connection sharing
> >>>>>> opportunities.
> >>>>> 
> >>>>> I'm unaware of any actual use of these opportunities, in the
> >>>>> absence of RPC-TLS .  If there
> >>>>> is little use of these, than the deprivation of sharing
> >>>>> opportunities is purely formal.
> >>>> 
> >>>> The particular use case is that both the Linux and Solaris NFSv3
> >>>> implementations use the same connection for NFS and NFSACL
> >>>> traffic,
> >>>> which are two distinct RPC programs.
> >>>> 
> >>>> It's an ongoing concern for NFS clients that use privileged
> >>>> source
> >>>> ports to conserve the number of connections they make to a
> >>>> particular server.
> >>>> 
> >>>> Not a problem for NFSv4, or NFS with Kerberos which can use an
> >>>> ephemeral source port without any consequences. We could probably
> >>>> even stipulate in an NFS-on-TLS or NFS security document that an
> >>>> NFS server should not require a privileged source port, but
> >>>> that's
> >>>> a rat hole.
> >>> 
> >>> That's only OK if you can trust the client itself to enforce user
> >>> identities. The main reason for requiring the privileged port is to
> >>> ensure that the server is either talking to the kernel on the
> >>> client,
> >>> or that it is talking to a privileged process. You don't normally
> >>> want
> >>> to trust an unprivileged RPC client not to lie to you about
> >>> AUTH_SYS
> >>> credentials...
> >>> I can't see that TLS changes that trust model unless the client
> >>> also
> >>> authenticates to the server to prove it is running a trusted RPC
> >>> program.
> >> 
> >> So, does that mean in cases where TLS host authentication is used,
> >> the server MAY ignore the client's source port?
> > 
> > I'm saying that if I were the sysadmin, then the case where the client
> > identifies itself strongly is the only one where I would relax the
> > requirement on the source port.
> > 
> >>>>>> Is there consensus on this, or should these design points be
> >>>>>> revisited? 
> >>>>> 
> >>>>> I'd prefer not but we need to give working group members who
> >>>>> feel
> >>>>> differently, the
> >>>>> opportunity to raise their concerns.
> >>>> 
> >>>> +1
> >>> 
> >>> That proposal essentially bans the backchannel on NFSv4.x (which
> >>> uses a
> >>> program number assigned by the client), so it is not acceptable.
> >> 
> >> As Dave said, what I described is what is already implied by or
> >> stated
> >> in rpc-tls. It's possible that either rpc-tls or my understanding is
> >> not correct.
> >> 
> > 
> > I'm saying if that is how the protocol currently reads, then we've made
> > a mistake, and we need to correct it.
> > 
> > I don't see any reason why we need to add RPC layer restrictions when
> > we're effectively just adding a new underlying transport protocol. RPC
> > already has its own mechanisms for rejecting unsupported programs and
> > program versions.
> > 
> > What we might want to stipulate is that _if_ the server rejects your
> > program on the established channel, then that does not automatically
> > imply that it would also reject it on a different connection. However,
> > I'd first like to understand why it is desirable to treat TLS/DTLS
> > differently from ordinary TCP/UDP in that situation.
> > 
> >> I am open to alternative proposals or corrections to my
> >> understanding.
> >> But do note that the situation has to be clarified as part of our
> >> response to the AD review.
> >> 
> >> 
> >>> Furthermore, as already pointed out, there are use cases for other
> >>> side-band protocols that share the same connection to the server as
> >>> the
> >>> main protocol.
> >>> 
> >>>>> if there is no objection, why don't you include
> >>>>> explicit langusge about your non-sharing model in the next
> >>>>> revision
> >>>>> and the
> >>>>> working group discssion of the chamges in that document will
> >>>>> serve
> >>>>> as the basis
> >>>>> for determining whether we have a continued onsensus on those
> >>>>> point.    
> >>>> 
> >>>> Excellent suggestion, I will do that.
> >>> 
> >>> I object.
> >> 
> >> To what? Do you mean that you would prefer we work this out here on
> >> the
> >> mailing list rather than through the draft revision process? That's
> >> fine with me too.
> > 
> > I'd prefer that we work it out here. As I said, I consider this to be a
> > potential protocol error, if indeed the current text can be interpreted
> > in the suggested manner.
> 
> To address AD review comments 6, 7, and 8, here's what I propose for
> Section 4.1:
> 
> 
> 4.1.  Discovering Server-side TLS Support
> 
>    The mechanism described in the current document interoperates fully
>    with RPC implementations that do not support TLS.  Depending on
>    policy, the use of TLS is automatically disabled in these cases.
> 
>    To achieve this, we introduce a new RPC authentication flavor called
>    AUTH_TLS.  This new flavor signals that the client wants to initiate
>    TLS negotiation if the server supports it.  Except for the
>    modifications described in this section, the RPC protocol is unaware
>    of security encapsulation at the transport layer.
> 
>    When an RPC client is ready to begin a TLS session, it sends a NULL
>    RPC procedure with an auth_flavor of AUTH_TLS.  The value of AUTH_TLS
>    is defined in Section 8.1.  The NULL request is made to the same port
>    as if TLS were not in use.
> 
>    The length of the opaque data constituting the credential sent in the
>    RPC Call message MUST be zero.  The verifier accompanying the
>    credential MUST be an AUTH_NONE verifier of length zero.
> 
>    The flavor value of the verifier in the RPC Reply message received
>    from the server MUST be AUTH_NONE.  The length of the verifier's body
>    field is eight.  The bytes of the verifier's body field encode the
>    ASCII characters "STARTTLS" as a fixed-length opaque.
> 
>    If the RPC server replies with a reply_stat of MSG_ACCEPTED and an
>    AUTH_NONE verifier containing the "STARTTLS" token, the RPC client
>    follows with a "ClientHello" message.  The client MAY proceed with
>    TLS session establishment even if the Reply's accept_stat is not
>    SUCCESS (for example, if the accept_stat is PROG_UNAVAIL).  Once the
>    TLS handshake is complete, the RPC client and server have established
>    a secure channel for communicating.
> 
>    If the Reply's reply_stat is MSG_ACCEPTED but the verifier does not
>    contain the "STARTTLS" token, or if the Reply's reply_stat is
>    MSG_DENIED, the RPC client MUST NOT send a "ClientHello" message.
>    RPC operation can continue, but in the clear.
> 
>    If, after a successful RPC AUTH_TLS probe, the subsequent TLS
>    handshake should fail for any reason, the RPC client reports this
>    failure to the upper-layer application the same way it reports an
>    AUTH_ERROR rejection from the RPC server.
> 
>    If an RPC client uses the AUTH_TLS authentication flavor on any
>    procedure other than the NULL procedure, or an RPC client sends an
>    RPC AUTH_TLS probe within an existing TLS session, the RPC server
>    MUST reject that RPC Call by setting the reply_stat field to
>    MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat
>    field to AUTH_BADCRED.
> 
> 
> And for Section 5.1:
> 
> 
> 5.1.  Base Transport Considerations
> 
> 5.1.1.  RPC-on-TLS Operation on TCP
> 
>    The use of TLS [RFC8446] protects RPC on TCP connections.  Typically,
>    once an RPC client completes the TCP handshake, it uses the mechanism
>    described in Section 4.1 to discover RPC-on-TLS support for that
>    connection.  If spurious traffic appears on a TCP connection between
>    the initial clear-text AUTH_TLS probe and the TLS session handshake,
>    receivers MUST discard that data without response and then SHOULD
>    drop the connection.
> 
>    The protocol convention specified in the current document assumes
>    there can be no more than one concurrent TLS session per TCP
>    connection.  This is true of current generations of TLS, but might be
>    different in a future version of TLS.
> 
>    Once a TLS session is established on a TCP connection, no further
>    clear-text communication can occur on that connection until the
>    session is terminated.  When operation is complete, an RPC peer
>    terminates a TLS session by sending a TLS Closure Alert and then
>    closes the TCP connection.
> 
>    Furthermore:
> 
>    o  The use of TLS does not alter RPC record framing used on TCP
>       transports.
> 
>    o  If an RPC server responds with PROG_UNAVAIL to an RPC Call within
>       an established TLS session, that does not imply that RPC server
>       will subsequently reject the same RPC program on a different TCP
>       connection.
> 
>    o  If a client uses an ephemeral source port for a TCP connection and
>       does not present authentication material to initiate TLS host
>       authentication, the server MUST abort the TLS handshake with a
>       handshake_failure alert.
> 
>    Backchannel operation occurs only on connected transports such as
>    TCP.  To protect backchannel operations, an RPC server uses the
>    existing TLS session on that connection to send backchannel
>    operations.  The server does not attempt to establish a TLS session
>    on a TCP connection for backchannel operation.
> 
> 5.1.2.  RPC-on-TLS Operation on UDP
> 
>    RPC over UDP is protected using DTLS [I-D.ietf-tls-dtls13].  As soon
>    as a client initializes a UDP socket for use with an unfamiliar
>    server, it uses the mechanism described in Section 4.1 to discover
>    DTLS support for an RPC program, and then negotiate a DTLS session
>    for that program.  Connected operation is RECOMMENDED.
> 
>    Once an RPC client establishes a DTLS session for an RPC program, the
>    RPC server MUST reject UDP-transported Calls in that RPC prgram from
>    that RPC client that are not protected by the established DTLS
>    session.
> 
>    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.
> 
>    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.  Using DTLS does not
>    introduce reliable or in-order semantics to RPC on UDP.  The use of
>    DTLS record replay protection is REQUIRED.
> 
> 5.1.3.  RPC-on-TLS Operation on Other Transports
> 
>    Transports that provide intrinsic TLS-level security (e.g., QUIC)
>    need to be addressed separately from the current document.  In such
>    cases, the use of TLS is not opportunistic as it can be for TCP or
>    UDP.
> 
>    RPC-over-RDMA can make use of transport layer security below the RDMA
>    transport layer [RFC8166].  The exact mechanism is not within the
>    scope of this document.  Because there might not be other provisions
>    to exchange client and server certificates, authentication material
>    exchange needs to be provided by facilities within a future RPC-over-
>    RDMA transport protocol.
> 
> 
> 
> >>>>> On Thu, Apr 9, 2020 at 3:28 PM Chuck Lever <
> >>>>> chuck.lever@oracle.com <mailto:chuck.lever@oracle.com>>
> >>>>> wrote:
> >>>>> 
> >>>>>> On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <
> >>>>>> magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>> wrote:
> >>>>>> 
> >>>>>> 8. Section 5.1.2:
> >>>>>> 
> >>>>>>  As soon as a client
> >>>>>>  initializes a socket for use with an unfamiliar server, it
> >>>>>> uses the
> >>>>>>  mechanism described in Section 4.1 to discover DTLS support
> >>>>>> and then
> >>>>>>  negotiate a DTLS session.
> >>>>>> 
> >>>>>> So first of all is the usage of TLS for TCP completely
> >>>>>> separate
> >>>>>> from using DTLS over UDP? So having determined TLS support
> >>>>>> for
> >>>>>> TCP does not indicate the same for UDP? And is it in any
> >>>>>> cases
> >>>>>> possible to skip the initial RPC null request with AUTH_TLS
> >>>>>> authentication and go directly to negotiate TLS after support
> >>>>>> has
> >>>>>> been determined with a server? 
> >>>>> 
> >>>>> There seems to be a high-order bit here that rpc-tls does not
> >>>>> currently
> >>>>> address. Leaving it unaddressed could introduce significant
> >>>>> interoperability issues.
> >>>>> 
> >>>>> Our new STARTTLS RPC NULL probe carries an RPC program. Does a
> >>>>> successful
> >>>>> probe mean that the RPC server supports TLS for every RPC
> >>>>> program
> >>>>> on that
> >>>>> that host? on that port? Or just for the program used in the
> >>>>> probe?
> >>>>> I think
> >>>>> it means TLS can be used only with the RPC program used in that
> >>>>> probe,
> >>>>> and only for the lifetime of that connection. (ie each
> >>>>> connection
> >>>>> has to
> >>>>> do the probe).
> >>>>> 
> >>>>> Since the STARTTLS RPC NULL probe is always done in clear-text,
> >>>>> that means
> >>>>> a second probe cannot be done once a TLS session has been
> >>>>> established on
> >>>>> a connection. (A separate connection must be established to
> >>>>> initiate a
> >>>>> second TLS session).
> >>>>> 
> >>>>> Therefore with RPC-on-TLS we do not allow multiple RPC programs
> >>>>> to
> >>>>> share
> >>>>> a TLS session. And we do not allow multiple RPC-on-TLS sessions
> >>>>> per
> >>>>> TCP
> >>>>> connection.
> >>>>> 
> >>>>> For DTLS, the STARTTLS probe has to be done for each RPC
> >>>>> program on
> >>>>> each
> >>>>> server. Only that one RPC program can use the established DTLS
> >>>>> session.
> >>>>> 
> >>>>> 
> >>>>> This means RPC-on-TLS robs us of some TCP connection sharing
> >>>>> opportunities.
> >>>>> Is there consensus on this, or should these design points be
> >>>>> revisited?
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org <mailto:nfsv4@ietf.org>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>

--
Chuck Lever