search

chucklever / i-d-rpcrdma-version-two

An Internet Draft specifying version two of the RPC-over-RDMA transport protocol.
Other
2 stars 2 forks source link

RPC/RDMA v2 should support generic host authentication #2

Closed chucklever closed 4 years ago

chucklever commented 5 years ago

Tom Talpey suggested we wanted to use chained Sends instead of RDMA for large authentication payloads, and that we need to support generic authentication mechanisms that require multiple round trips.

dnoveck commented 5 years ago

There are two separate issues mentioned here. We should look at each one to see if it is essential, highly desirable, or nice to have.

chucklever commented 5 years ago

The host authentication mechanisms we are already familiar with (eg. ones that are built into TLS) can generate multiple challenges and responses (multiple round trips) and some of them may convey chains of trust that are considerably longer than our inline threshold. The latter issue is what might require Send chaining, if we feel that using RDMA_NOMSG is undesirable or unworkable for a host authentication mechanism.

dnoveck commented 5 years ago

From: Chuck Lever notifications@github.com Sent: Saturday, October 26, 2019 3:39 PM To: chucklever/i-d-rpcrdma-version-two i-d-rpcrdma-version-two@noreply.github.com Cc: Noveck, David David.Noveck@netapp.com; Comment comment@noreply.github.com Subject: Re: [chucklever/i-d-rpcrdma-version-two] RPC/RDMA v2 should support generic host authentication (#2)

So it appears that multiple round trips are essential. Conceptually it is simple but there is bunch of writing to do:

OK, but we are working under time pressure which makes it difficult to meet a milestone target when, a few weeks ago, we had a much smaller set of changes in mind. We made this change in response to Tom’s sensible arguments but we have to be aware that Tom is not responsible for getting this done and ghis help, while real, will not be very extensive.

I believe we will have trouble with a milestone more than a year from now. I find the prospect of a 10/20 or 11/20 milestone kind of frightening but am willing to go along if you think it is doable.

If it isn’t doable, we will need an alternative. One thing I have been thinking about is a change in the contents of the certificate property (the one wrapped in a pseudo opaque). I think we could support it being a union with two arms:

I know this isn’t pretty but I think we have to be prepared if it doesn’t look like send chaining is doable in time. I don’t think Magnus is going to accept a milestone target in 2021, so our choice might be to do this in an ugly way or not to do it at all.

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

The host authentication mechanisms we are already familiar with (eg. ones that are built into TLS) can generate multiple challenges and responses (multiple round trips) and some of them may convey chains of trust that are considerably longer than our inline threshold. The latter issue is what might require Send chaining, if we feel that using RDMA_NOMSG is undesirable or unworkable for a host authentication mechanism.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/chucklever/i-d-rpcrdma-version-two/issues/2?email_source=notifications&email_token=ANP2RUMWO3YCX7B6QDMHFLDQQSMD7A5CNFSM4JBLNGF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECKPMJA#issuecomment-546633252, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANP2RUMKADP2K5H3DNBAAODQQSMD7ANCNFSM4JBLNGFQ.

chucklever commented 5 years ago

dnoveck says:

I believe we will have trouble with a milestone more than a year from now. I find the prospect of a 10/20 or 11/20 milestone kind of frightening but am willing to go along if you think it is doable.

Independent of the other process obstacles, I think a 9/20 milestone is achievable.

If it isn’t doable, we will need an alternative. One thing I have been thinking about is a change in the contents of the certificate property (the one wrapped in a pseudo opaque). I think we could support it being a union with two arms:

  • An inline opaque certificate.
  • A read chunk that tells the receiver were to obtain the certificate.

My original proposal for dealing with large certificates was to use RDMA. The problem with that is that the mechanism has to work both ways: client-to-server and server-to-client. The client has no way to predict how large the server's certification material is to set up a Reply chunk.

We could perhaps make that size a transport property so that the server can tell the client "yes, I have certificate material, and it's 9KB in size". That way the client can send its certificate material (possibly via RDMA) and provide a 9KB Reply chunk at the same time.

chucklever commented 4 years ago

The latest revision of rpcrdma-version-two includes support for the exchange of potentially large authentication material.