Subject: RE: [nfsv4] More on CCM

From: [email-masked]
Date: Wed, 12 Mar 2003 10:38:52 -0500

> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 7:17 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [nfsv4] More on CCM
> 
> 
> > > 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:

Sorry I may have missed this. My response is below.

> 
> 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

I don't see how they can declare using iSCSI model without
modifying their existing model.

> that they are tying the CCM context to the TCP connection?
> 

There is a difference between ONC RPC and iSCSI in the layering
and intended use. The former is a layer between the transport and
the RPC ULPs; while the latter is a ULP itself. The iSCSI model
may not be the best model for all RPC ULPs.

To use an example to illustrate my point, one RPC ULP may consider
TCP connection a rare resource. Whenever the connection has been
idle for a short amount of time, it has to be reclaimed. If CCM is
tied to such a connection, it will have to established every time
the client reconnects. Tying it to the underlying channel (such as
IPSec P2 association) will not have the same problem.

The goal is to allow existing ONC RPC ULPs to be able to use CCM
with minimal changes, if any, including changes to the connection
model in use; and to allow future ONC RPC ULPs to pick whatever
connection model deemed best by the ULP, not by ONC RPC, and yet
still be able to use CCM.

> 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