Subject: [nfsv4] wg meeting at IETF 111

From: David Noveck <[email-masked]>
Date: Fri, 18 Jun 2021 06:10:23 -0400

I've requested a two-hour session which may turn into two one-hour
sessions.   We won't know exactly when it will be, but it will be scheduled
according to "business hours" in PDT, so the scheduling should not pose
much difficulty for most people in the group.

As far as things that people are already planning to talk about:

   - I expect to spend twenty minutes or so talking about the security
   update that will go along with rfc5661bis.  I expect to have a
   draft-dnoveck-nfsv4-security-00 out by the deadline.
   - Chuck will be giving a talk (I think ten minutes) about the current
   state of RPC-over-RDMA v2.  I think he will have a new draft posted by the
   deadline.   He might have another talk up his sleeve, but I'm not sure.
   - Tom Talpey will be taking up about fifteen minutes.   He will give an
   update  on his proposed iWarp extension.   I'm not sure if he will be able
   to post a draft by the deadline.  He might also spend some time talking
   about the working group's options in defining a data-secure RDMA protocol.

That gives  us a fair amount of available time to talk about other things.
 If there is something you want to talk about, please let me know so you
can be included in the agenda.

---

From: Chuck Lever III <[email-masked]>
Date: Fri, 18 Jun 2021 14:06:22 +0000

> On Jun 18, 2021, at 6:10 AM, David Noveck <[email-masked]> wrote:
> 
> I've requested a two-hour session which may turn into two one-hour sessions.   We won't know exactly when it will be, but it will be scheduled according to "business hours" in PDT, so the scheduling should not pose much difficulty for most people in the group.  
> 
> 	• I expect to spend twenty minutes or so talking about the security update that will go along with rfc5661bis.  I expect to have a draft-dnoveck-nfsv4-security-00 out by the deadline.
> 	• Chuck will be giving a talk (I think ten minutes) about the current state of RPC-over-RDMA v2.  I think he will have a new draft posted by the deadline.   He might have another talk up his sleeve, but I'm not sure.
> 	• Tom Talpey will be taking up about fifteen minutes.   He will give an update  on his proposed iWarp extension.   I'm not sure if he will be able to post a draft by the deadline.  He might also spend some time talking about the working group's options in defining a data-secure RDMA protocol.
> That gives  us a fair amount of available time to talk about other things.   If there is something you want to talk about, please let me know so you can be included in the agenda.

IMO we should discuss how to proceed with RPC (and then NFS) over QUIC.
We need a plan of attack and a possible charter update.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sat, 19 Jun 2021 09:58:37 -0400

On Fri, Jun 18, 2021, 10:06 AM Chuck Lever III <[email-masked]>
wrote:

> >       • I expect to spend twenty minutes or so talking about the
> security update that will go along with rfc5661bis.  I expect to have a
> >       • Chuck will be giving a talk (I think ten minutes) about the
> current state of RPC-over-RDMA v2.  I think he will have a new draft posted
> by the deadline.   He might have another talk up his sleeve, but I'm not
> sure.
> >       • Tom Talpey will be taking up about fifteen minutes.   He will
> give an update  on his proposed iWarp extension.   I'm not sure if he will
> be able to post a draft by the deadline.  He might also spend some time
> talking about the working group's options in defining a data-secure RDMA
> protocol.
> > That gives  us a fair amount of available time to talk about other
> things.   If there is something you want to talk about, please let me know
> so you can be included in the agenda.
>

I agree.

I'm assuming you will have some comments and are prepared to lead the
discussion.  How much time should I allocate?

We need a plan of attack.

I can see that a plan is needed but primarily we need working group
interest and someone to do the work (hint hint).

Maybe I'm blind but I don't any defenders, so maybe combat metaphors are
beside the point.

and a possible charter update.

I don't see the need for this.  It is inconceivable to me how RPC-over-TLS
can be in the charter and rpc-over-quic outside it.

Anyone can raise charter issues during the discussion.  I think our
scheduling approach should not be based on the assumption that this is a
substantial issue.

---

From: Chuck Lever III <[email-masked]>
Date: Sat, 19 Jun 2021 15:00:37 +0000

> On Jun 19, 2021, at 9:58 AM, David Noveck <[email-masked]> wrote:
> 
>> On Fri, Jun 18, 2021, 10:06 AM Chuck Lever III <[email-masked]> wrote:
>> 

Do we need a separate presentation regarding NFS on TLS in specific?

 - implementation status
 - a document strategy for NFS with TLS
 - other technical issues (Rick?) that need interactive group discussion
 - in particular, concerns about performance impact limiting deployment
 - anything else?

> I'm assuming you will have some comments and are prepared to lead the discussion.  How much time should I allocate?

Let's say 10 minutes.

> I can see that a plan is needed but primarily we need working group interest and someone to do the work (hint hint).

I can present a couple of slides that propose a document strategy, and
give some room for any debate about charter issues. I don't foresee
surprising or voluminous technical issues to address via specification,
so I can volunteer to wrangle/author/edit documents.

> Maybe I'm blind but I don't any defenders, so maybe combat metaphors are beside the point.
> 
> I don't see the need for this.

Yeah, I did say "possible". I'd just like to ensure we've brought up
any charter issues in a public meeting.

> It is inconceivable to me how RPC-over-TLS can be in the charter and rpc-over-quic outside it.

Again, let's not conflate a security feature with a full-blown RPC
transport. I feel -TLS and -QUIC will be distinct technologies.
QUIC utilizes TLS, as does both TCP and UDP.

> Anyone can raise charter issues during the discussion.  I think our scheduling approach should not be based on the assumption that this is a substantial issue.

Agreed. I don't expect it to be substantial.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Jun 2021 17:34:58 -0700

> QUIC utilizes TLS, as does both TCP and UDP.

QUIC v1 uses the TLS handshake for authentication and key agreement, but
does not use the TLS record layer or record-protection schemes.

The TLS 1.3 handshake is quite robust as a cryptographic key-agreement
mechanism, but as we have seen with RPC-over-TLS, the TLS handshake is not
always a perfect fit for what we want for RPC authentication.  It's
consistent with the QUIC architecture to be able to drop in a different
cryptographic handshake that provides authentication and key agreement, and
I think we should be willing to consider whether doing so is appropriate
for RPC usage.  For example, at a high-level "put the building blocks
together" perspective, it would be fairly straightforward to use the same
GSS mechanisms that RPCSEC_GSS uses for peer authentication, and
GSS_pseudo_random() to extract keys usable for QUIC record protection.
There are probably other ways to combine things as well, depending on what
form of credentials are expected to be readily available for NFS servers,
clients, and users.

-Ben

---

From: Chuck Lever III <[email-masked]>
Date: Wed, 23 Jun 2021 01:28:44 +0000

> On Jun 22, 2021, at 8:34 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Ah, hm. I expected that QUIC would use the TLS record layer via DTLS (on UDP).
Does this mean QUIC v1 cannot utilize the current class of TLS offload hardware?

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Jun 2021 20:24:22 -0700

> Ah, hm. I expected that QUIC would use the TLS record layer via DTLS (on UDP).

Nope, QUIC sits directly on top of UDP.

> Does this mean QUIC v1 cannot utilize the current class of TLS offload hardware?

I believe that's correct.  QUIC v1 goes to some length to make as much as
possible of its messages indistinguishable from random noise to a casual
observer, even to the extent of requiring a second pass over the packet to
use the ciphertext of the payload as input to a header protection process
that hides lengths and packet numbers.  Current offload hardware is not
going to be of much use as-is, though I have a vague memory of some offload
engines allegedly being flexible enough that they could be adapted to help
some with QUIC.

-Ben