Subject: Re: [rddp] rddp security and nfsv4

From: Brent Callaghan <[email-masked]>
Date: Sun, 24 Nov 2002 18:44:21 -0800

Currently there's an NFS/RDMA working group within SNIA that's
tasked with a protocol to run NFS over RDMA.  The group's name
is a bit of a misnomer, since the effort is focused exclusively
on the RPC layer.  Hence all RPC-based protocols will be RDMA
enabled: NFS versions 2, 3 and 4.

NFS version 4 brings "mandatory to implement" security to NFS.
It's a requirement that any conforming NFSv4 implementation
come with security built-in.  However, it's use is optional.
NFSv4 security is defined within the RPC layer, specifically,
as RPCSEC_GSS mechanisms: required in RFC3010 are Kerberos v5
and LIPKEY (a public key scheme designed for Internet use).

RPCSEC_GSS security operates at the level of an RPC session.
It's not bound to a transport.  Hence multiple users sharing
a common transport connection between client and server can
be independently authenticated.  RPCSEC_GSS also throws in
message integrity or privacy if required.

Good news is that RPCSEC_GSS will work just fine even if the
RPCs are over an RDMA transport.  This will be true for all
versions of NFS.  But there's bad news too: if integrity protection
or privacy are used, then the direct placement advantage will likely
be lost since an extra payload copy is almost inevitable.

I'm hopeful that RDMA NICs will also be able to include IPsec
so that security too can be offloaded and direct placement can
be preserved.

	Brent

[email-masked] wrote:
 >
 > (snip)
 >
> NFSv4 might be a good place to start in exploring appropriate
> security mechanisms for RDDP, as NFSv4 has its own security mechanisms
> built into the protocol, and there is little point in duplicating them
> at a lower layer in the protocol stack.  Hence use of RDMA with NFSv4
> raises some interesting security concerns:
> 
> 	- Ensure that NFSv4 can still secure its payloads in the
> 		manner it currently does.
> 	- Consider how to protect the RDMA and DDP headers
> 		that NFSv4 doesn't currently grok.
> 
> Use of IPsec for the latter initially strikes me as akin to using
> a sledgehammer to kill an ant (yes, a dead ant does result, but
> accompanied by a lot of unnecessary noise and collateral damage ... ).
> 
> I've cc:'d the NFSv4 WG list in the hope of sparking some interest
> in that community to work on this issue, as I believe the nfsv4
> WG charter is in the process of being revised to include work on
> NFSv4 over RDDP (hmm ... I wonder if they understand what they're
> getting themselves into?).

---

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Nov 2002 14:35:22 -0800

> be lost since an extra payload copy is almost inevitable.

Why is this inevitable? As you say below, NICs that are smart enough
to understand RDMA might also be smart enough to understand IPsec.
In the end, existing NICs that understand IPsec are just keeping 
a session key per security association around and encrypting/decrypting stuff
based on a cached session key.

If NFS/RDDP included hints as to where the encrypted and/or decrypted payload
lived, then this seems feasible to do in the NIC.

---

From: Brent Callaghan <[email-masked]>
Date: Mon, 25 Nov 2002 15:08:11 -0800

> lived, then this seems feasible to do in the NIC.

Yes, with new APIs, hints and NIC support it's possible, but
I don't think the added function is worth the complexity.

You get much the same effect with an RDMA device if you do the
authentication with RPCSEC_GSS in the host RPC layer and have
IPsec handle encryption/integrity in the RDMA NIC.

	Brent

---

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Nov 2002 15:28:14 -0800

> IPsec handle encryption/integrity in the RDMA NIC.

With limitations. Say the NFS server protects some data with RPCSEC_GSS privacy and
other data with just integrity. I know of no way to tell IPsec implementations to
encrypt some TCp segments and not others; the granularity is at the entire port.
So now all the traffic to the server has to be encrypted.

If RDDP is a case of pick one: security or performance, then don't be
surprised if people say: "neither, thanks, I'll used something that isn't RDDP".

	-mre