Re: [nfsv4] Comments on minutes of wg meeting at IETF114

[Trond Myklebust <[e-mail]>]

On Tue, Sep 13, 2022 at 12:38 PM Chuck Lever III <[e-mail]>
wrote:

>
>
> On Sep 13, 2022, at 5:29 AM, David Noveck <[e-mail]> wrote:
>
> On Mon, Sep 12, 2022, 12:25 PM Chuck Lever III <[e-mail]>
> wrote:
>
>
>> The conclusion of this discussion was to let the RDMA and ULB documents
>> expire and remove the charter milestone.
>>
>
> Regardless of that, we would have to ascertain consensus to do that.
> Decisions at working group meetings always have to be confirmed on the wg
> mailing list.
>
>
> Fwiw, the co-chair and area director in the room at the time did not state
> that requirement. The co-chair stated that the charter change was implied
> by the decision to allow the documents to expire, so I assumed that meant
> that no further bureaucratic actions were necessary.
>
>
> That should have been done a month ago, but we might as well have that
> discussion now.
>
>
>> A version 2 of RPC/RDMA is not in demand by any customer.
>>
>
> Fair enough.  It is a shame we have an RDMA approach so inferior to SMB.
> Sigh!
>
> >  I feel it’s time to let it rest,
>
> If you don't want to push this to a conclusion, then we have to live with
> what we have.
>
>
> It's not a matter of not wanting to push this to conclusion. It is simply
> not possible for me to finish this by myself: proper protocol development
> requires two independent implementations.
>
> After Linux, where is the second implementation? (Answer: there isn't one)
>
> Who is bringing RPC/RDMA v2 implementations to our testing events?
> (Answer: no one)
>
> Which vendors truly want to bring a second implementation of RPC/RDMA to
> market? (Answer: I have yet to hear of one that has the resources to do
> this)
>
> What customers are demanding it? (Answer: I have yet to hear of any; the
> demand has come exclusively from complaints made by protocol architects)
>
> Improving security for MPA/RDMAP is an approach that lifts all boats. What
> few resources the WG has is better spent on that instead of RPC/RDMA v2.
>
>
> > Unless or until there are sufficient resources to attack the addition of
> transport-layer security to MPA/RDMAP.
>
> That sounds to me too much like "We'll do it when we get around to it."
>
>
> You can spin it any way you like, but that's always the way it's been.
> When we have the energy and enthusiasm for an idea, it will get done
> somehow. We have more enthusiasm for what is essentially iWARP on QUIC than
> for RPC/RDMA v2.
>
>
> Because of the importance of security, we cannot simply wait for such
> resources to drop into our laps.
>
>
> It's not clear what motivated this remark, but no-one has suggested that
> we ignore the security requirements of RPC/RDMA.
>
>
> Chuck has informed me that a wg decision was made to abandon this document
>> but that does nĺ⁰ot appear in the minutes.
>>
>>
> I'm perplexed by this and expect to remain so even if a 3-D 4K-resolution
> video were discovered.
>
> Given that this was an individual draft, the decision was not a wg
> decision and does not have to be confirmed on the list.
>
> Instead, it is Chuck's decision to make but I'd like to understand why he
> made it.
>
> Let me give people some background.  Chuck objected to the treatment of
> SECINFO in some earlier security-0x draft.  He thought it was to
> complicated so we agreed that he would publish his approach, as he did in
> rpc- tls-pseudoflavors and I  would refer to that in the next security
> draft.
>
> Now it appears that Chuck has changed his mind and I'd appreciate knowing
> why <http://why.ch/>.
>
>
> Rick told me he is not going to implement it. Trond stated that the
> proposed mechanism is a hack, which I take to mean he will not accept it in
> the Linux client.
>
>
 Chuck recently reminded me that I haven't commented publicly on this
draft. I did explain my reasoning in an email to him a while back, so let
me just quote that:

First of all, it is mixing the concept of a transport and authentication.
While TLS can provide authentication of the client to the server, the only
thing that should matter conceptually to the SECINFO operation and its ilk
is that there is some form of trusted channel that is able to underpin the
otherwise weakly authenticated RPC operations. How that channel is created,
whether it is by TLS, QUIC, or even krb5i / krb5p using the machine
principal, …. should be irrelevant to the NFS client.

Secondly, we always send a NULL ping on connecting to the server anyway. If
we’re going to negotiate TLS, then why shouldn’t we just use that NULL ping
to immediately deduce whether or not TLS is supported? As long as the
server replies with something (error or not) then we know that the
connection to the server is good.

Thirdly, there is the fact that you’re learning this information after
connecting. So what is the point? If you are already connected via TLS,
then the information that TLS is supported is known. If you connected
without TLS, then how can you trust the reply? This is the whole
bootstrapping problem that causes us to prefer to always try krb5i first
for SETCLIENTID/EXCHANGE_ID if we have access to it, even if the NFS mount
has specified sec=sys.

Thanks!
  Trond