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

[Chuck Lever III <[e-mail]>]

On Oct 4, 2022, at 10:33 AM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:



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


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


On Sep 13, 2022, at 5:29 AM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:

On Mon, Sep 12, 2022, 12:25 PM Chuck Lever III <[e-mail]<mailto:[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,

I don't read Trond's comments that way at all -- the objection is to changes to both NFSv4 and NFSv3.

I disagree however that the WG shouldn't bother with improving the security of NFSv3. It's obviously still a widely deployed protocol, and maintaining RFC 1813 is part of our charter, I thought. The NFSv4 security document can't make any normative or informative statements about NFSv3, but we are still well within our charter to publish independent documents that informatively describe conventions that NFSv3 implementations can employ when making use of RPC-with-TLS or any other variety of transport-layer security.


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.

I think I objected pretty strongly to the pseudoflavor proposal that was initially a part of security-xx, that's why I took the trouble of proposing the RPC-with-TLS pseudoflavors alternative. I would prefer publishing none of the original p-flavor proposal over publishing what was in the original security document.


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.

I'm not quite sure what you mean, but to be clear, user authentication is explicitly not part of RPC-with-TLS.

What I think you are trying to describe is a security policy that is applied by NFS servers based on the presence or absence of transport-layer security.


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.

It would be easy to make the following stipulation: When a server's security policy requires transport-layer security to enable access via AUTH_SYS/NONE, then a SECINFO on a protected transport should continue to list SYS/NONE, and a SECINFO on an unprotected transport would not. If the client uses AUTH_SYS in a way that does not conform with a server's security policy, the server rejects the request with AUTH_TOO_WEAK.

In my opinion, if a server has an RPC-with-TLS implementation and sufficient authentication material, it should force the use of transport layer security everywhere it can. I don't see the value in permitting unprotected AUTH_SYS on some filesystems and requiring protection to access others with SYS. Is there a real use case today where a server administrator would want to enable such a policy?

Taking a step back, it seems like we're putting the cart before the horse by trying to design protocol for which there is yet no implementation. I thought the working group's role was to codify existing implementation practice, not invent new protocol and then ask people to go and build it. Shouldn't we wait until either a) SecDir complains there's something missing from the security document, or b) someone has actually implemented protocol that should be shared?


--
Chuck Lever