Subject: RE: [nfsv4] More on CCM

From: Mike Eisler <[email-masked]>
Date: Tue, 11 Mar 2003 16:16:43 -0800 (PST)

> > Following Dai Peng's and David Black's comments, and considering
> > that useful (NAT-less) GSS channel bindings don't really 
> > exist, my thinking
> > is to specify the use of RPCSEC_GSS over CCM to limit its use
> > for the duration of the ULP's session. Most ULPs that use ONC 
> > RPC don't
> > have a session, but most ONC RPC ULPs do work over
> > connection oriented transports. So this effectively means that
> > sessionless ONC RPC ULPs must bind a particular CCM context to
> > a particular TCP or SCTP (whenever the wg gets around to
> > defining ONC RPC semantics for SCTP) connection.
> > 

> ONC RPC did not specify a network model to begin with. Instead,
> it is completely up to the ULPs to choose transport protocols
> and do connection management. For a particular ULP, requiring
> CCM/TCP binding may not always be the right thing to do.

Agreed. Which is why I wrote "effectively". If there is an
ONC RPC Upper Layer Protocol [ULP] (e.g. NIS, NFS, NIS+, etc.)
that wants to use CCM, then it has to make a decision. Either
use any ULP specific method for connection management, or if there
isn't one, pick one. Binding a CCM context such that it belongs
to one and only one TCP connection is one method. BTW, binding a
CCM context to one connection does not imply binding a TCP connection
one CCM context; multiple CCM contexts can and should continue to
share a TCP connection.

> It makes more sense to bind the CCM to the IPSec phase-2 association.

It's elegant. It also buys one nothing if one is using non-IPsec
(e.g. SSH, TLS ) as the secure channel.

> This way, the CCM can be used for multiple TCP connections as long
> as they are over the same IPSec association. It offers the same
> secure binding at the network level without impacting the transport.

I'm all for it. And when there's a ubiquitous way to get
hashed key info from arbitrary secure channels in a general form,
I can see adding it to CCM.

> > (If it is good enough for iSCSI, it is good enough for ONC RPC).

You didn't respond to this, so I'll quote what you wrote on
3/4/2003:

dp> I think the answer to your question lies in that there is no tying between
dp> RPC and the underlying TCP connection, unlike in iSCSI. In RPCSEC_GSS, the
dp> initiator authenticates once (user authentication) and is able to use the
dp> context handle in a subsequent request over any TCP connection, existing or
dp> new. As David pointed out, the channel binding is implicitly done in iSCSI
dp> because the network/auth model there is each TCP connection has to be
dp> individually authenticated.

I found the above to be a clear explanation of difficulties
David Black and you had with CCM as written down in the i-d.
So why can't ONC RPC ULPs that want to use CCM, without
modifying their existing (non-existent) connection model,
simply declare that they are using the iSCSI model? I.e., declare
that they are tying the CCM context to the TCP connection?

BTW, something to consider for a future minor version of NFSv4
is the capability to assoviste a "session" with multiple transport
connections. 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4