Subject: [nfsv4] Potential session at ietf113

From: David Noveck <[email-masked]>
Date: Sun, 30 Jan 2022 09:32:08 -0500

IETF113 is scheduled for 3/19-3/25 with an onsite component in Vienna,
although it seems likely that remote participation will be heavily used.
 My inclination is not to request a session (deadline is 2/4) as I expect
people are unlikely to want to travel to Vienna for this (Vienna caseloads
don't look bad but air travel is a crapshoot) or have a remote meeting in
Vienna working hours 9GMT+1).   I intend not to request a session.   Please
let me know soon if you think this is the wrong decision.

I don't think we want to go too long  without a working group meeting so we
need to look at our options for interim meeting.
My understanding, based on Zahed's comment that scheduling an
interim meeting within a month of the official meeting is frowned upon.
This leaves us a choice between trying to schedule something before 2/19 or
after 4/25.   So, I'm assuming the latter choice and will send email
about scheduling/contents within the next few weeks.  Again, if  you
have issues with this choice,  please let me and the working group know, as
soon as you can.

---

From: Chuck Lever III <[email-masked]>
Date: Mon, 31 Jan 2022 15:47:30 +0000

> On Jan 30, 2022, at 9:32 AM, David Noveck <[email-masked]> wrote:
> 
> IETF113 is scheduled for 3/19-3/25 with an onsite component in Vienna, although it seems likely that remote participation will be heavily used.   My inclination is not to request a session (deadline is 2/4) as I expect people are unlikely to want to travel to Vienna for this (Vienna caseloads don't look bad but air travel is a crapshoot) or have a remote meeting in Vienna working hours 9GMT+1).   I intend not to request a session.   Please let me know soon if you think this is the wrong decision.

I have no objection to not meeting during IETF 113.

> I don't think we want to go too long  without a working group meeting so we need to look at our options for interim meeting.
> My understanding, based on Zahed's comment that scheduling an interim meeting within a month of the official meeting is frowned upon.  This leaves us a choice between trying to schedule something before 2/19 or after 4/25.   So, I'm assuming the latter choice and will send email about scheduling/contents within the next few weeks.  Again, if  you have issues with this choice,  please let me and the working group know, as soon as you can.

After April for an interim feels better to me. However,
virtual meetings have been poorly attended and I haven't
found them to be entirely successful. It would be best
IMO if we could start moving more work onto the mailing
list.

-----

A couple of status updates:

I have not yet heard from the TSV early reviewer regarding
draft-ietf-nfsv4-rpcrdma-version-two. That review is due
today, I believe.

I recently checked on the publication status of
draft-ietf-nfsv4-rpc-tls:

* draft-ietf-kitten-tls-channel-bindings-for-tls13   NOT-RECEIVED
* draft-ietf-tls-dtls-connection-id   AUTH48
* draft-ietf-tls-dtls13   AUTH48*R

I'm chuffed that that DTLS-related documents are getting
published soon, but the kitten document seems not to be
making any progress. Channel binding is pretty important
for rpc-tls. There isn't much we can do but continue
sitting on our hands.

Linux RPC-with-TLS implementation status:

Regarding Linux prototypes of RPC-with-TLS, we have several
under way. The main focus is still on TLS handshake support.
The community wants a generic handshake solution that can
also work for NVMe/TLS and in-kernel QUIC when it arrives.

We have an in-kernel handshake implementation based on the
mbed TLS implementation that is being prepared to help
prototype server-side RPC-with-TLS. In-kernel handshake is
not favored by our security community because it increases
the kernel's attack surface. However, we don't believe that
a user space handshake mechanism can meet requirements to
support NFSROOT or root fs on an NVMe/TLS device.

As a development scaffold, an nginx module has been con-
structed that provides an RPC-with-TLS front-end for
unmodified NFS servers. This approach is not effective
for client-side RPC-with-TLS.

Thus we are also working on a couple of user space handshake
implementations as a stop-gap. The more permanent solution
will use Linux kernel keyrings to manage both the collection
of authentication materials (certificates and pre-shared
keys) and the handshake upcall. For the moment basic things
like client authentication and session re-key are not
supported.

Some of these prototypes are already on the NFS bake-a-thon
VPN for testing with other RPC-with-TLS implementations.

--
Chuck Lever