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

[David Noveck <[e-mail]>]

On Sun, Oct 2, 2022 at 11:01 AM Trond Myklebust <[e-mail]> wrote:

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

To clarify things, it appears that your comments relate to Chuck's
individual draft.   While I am interested in the fate of that draft, I am
also interested in the SECINFO changes that shared some of the same
motivation in draft-dnoveck-nfs4-security-05 and that I'm planning to
include in draft-ietf-nfsv4-security-00.

It seems to me that your comments primarily apply to use within v3, but I
can't be sure and want to make sure that there is no objection to these
pseudo-flavors in the context of NFSv4 SECINFO.  Plese let me know if there
are any issues.


> First of all, it is mixing the concept of a transport and authentication.
>

That mixing was part and parcel of rpc-with-tls and don't think it is
inherently harmful.


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

I agree.   I think my current text takes this approach, but it would help
if someone checked it to make sure i haven't mixed up i.e and e.g.

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

In the v4 context, we have to account for different fs's (or even different
namespace regions i the same fs) , so that a good connection to access one
piece of the server namespace and it might turn out tnot to be acceptable
in another piece of the namespace.

It might be that if you were designing this now, you wouldn't bother with
SECINFO.  Nevertheless, we can't rip this out in rfc5661bis, and I felt
that the best approach was to augment it to support security provided at
the connection level, rather than limiting it to auth-flavor selection.

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

Again this is different in the v4 context.


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

Still, you might find upon accessing a part of the namespace that you can
only do so with encryption.  That requires SECINFO has a way to require a
secure connection.

> .
>
> Thanks!
>   Trond
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>