Subject: [nfsv4] RPCSEC_GSSv3 procedure numbering

From: <[email-masked]>
Date: Thu, 12 May 2011 14:20:46 -0400

Nico,

At EMC, we're still working through review of your GSSv3 draft, but we turned up something that appears to need prompt attention:

The RPCSEC_GSSv3 draft specifies:

   ///  enum rpc_gss3_proc_t {
   ///          RPCSEC_GSS3_DATA = 0,
   ///          RPCSEC_GSS3_LIST = 1,
   ///          RPCSEC_GSS3_CREATE = 2,
   ///          RPCSEC_GSS3_DESTROY = 3
   ///  };

However, RPCSEC_GSSv2 (RFC 5403) specifies:

   ///   enum rpc_gss_proc_t {
   ///     RPCSEC_GSS_DATA          = 0,
   ///     RPCSEC_GSS_INIT          = 1,
   ///     RPCSEC_GSS_CONTINUE_INIT = 2,
   ///     RPCSEC_GSS_DESTROY       = 3,
   ///     RPCSEC_GSS_BIND_CHANNEL  = 4 /* new */
   ///  };

IMHO, that's not robust - interpreting the procedure number correctly requires looking at the version field in the header, which was not necessary for GSSv1 vs. GSSv2 (e.g., if a RPCSEC_GSS_BIND_CHANNEL procedure is sent to a GSSv1 implementation, that procedure fails cleanly).

I strongly suggest starting the numbering of the GSSv3 procedures with 5, i.e.,

   ///  enum rpc_gss3_proc_t {
   ///          RPCSEC_GSS3_DATA = 0,
   ///          RPCSEC_GSS3_LIST = 5,
   ///          RPCSEC_GSS3_CREATE = 6,
   ///          RPCSEC_GSS3_DESTROY = 7
   ///  };

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 13:38:41 -0500

On Thu, May 12, 2011 at 1:20 PM,  <[email-masked]> wrote:
> [...]

> IMHO, that's not robust - interpreting the procedure number correctly requires looking at the version field in the header, which was not necessary for GSSv1 vs. GSSv2 (e.g., if a RPCSEC_GSS_BIND_CH…

It's always been the case that different versions of any given ONC RPC
protocol have distinct procedure numbering spaces.  RPCSEC_GSS is very
much akin to an ONC RPC protocol, as such what I specified seems
completely fair and within spec.

What am I missing?

Nico
--

---

From: <[email-masked]>
Date: Thu, 12 May 2011 15:09:28 -0400

Nico,

> completely fair and within spec.

I didn't say it violated the spec - I said it wasn't robust - there is a difference ;-).

(1) GSSv2 already set the precedent for how to do this "right":

> > which was not necessary for GSSv1 vs. GSSv2 (e.g., if a RPCSEC_GSS_BIND_CHANNEL
> > procedure is sent to a GSSv1 implementation, that procedure fails cleanly).

(2) Independent of the "distinct procedure numbering spaces", the RPCSEC_GSS procedures for v1/v2/v3 are likely to be implemented in the same or related code modules.  Having the on-the-wire procedure numbers be global to that module or modules improves robustness.

(3) Mixing context handles for multiple versions of RPCSEC_GSS in related operations is going to be a common case for compound authentication (e.g., v1 "parent" handle + v3 "child" handle).  This is not like NFSv3 vs. NFSv4 which are mutually exclusive, hence do not offer this opportunity for potential confusion.

Thanks,
--David

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Thursday, May 12, 2011 2:39 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [nfsv4] RPCSEC_GSSv3 procedure numbering
> 
> > IMHO, that's not robust - interpreting the procedure number correctly requires looking at the
> version field in the header, which was not necessary for GSSv1 vs. GSSv2 (e.g., if a
> RPCSEC_GSS_BIND_CHANNEL procedure is sent to a GSSv1 implementation, that procedure fails cleanly).
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 14:28:29 -0500

> I didn't say it violated the spec - I said it wasn't robust - there is a
difference ;-).

There's an existence proof that what you say is not true (t heh ink of, say,
NIS).

> (1) GSSv2 already set the precedent for how to do this "right":

I'll look at iy later, but even of that were so, I don't agree that it's
precedent setting.

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 15:23:33 -0500

This is what RPCSEC_GSSv2 has

And this is what v1 has:

      enum rpc_gss_proc_t {
              RPCSEC_GSS_DATA = 0,
              RPCSEC_GSS_INIT = 1,
              RPCSEC_GSS_CONTINUE_INIT = 2,
              RPCSEC_GSS_DESTROY = 3
      };

v2 added a procedure.  If its procedure namespace were the same as v1
one would have to ask whether that's allowable.  But the procedure
namespaces are different for different versions of the same program.
We are free to use procedure numbers 0, 1, 2, and 3 as we wish in v3,
as well as to add more.  If your ONC RPC implementation makes this
difficult or not robust, then your RPC implementation is deficient :)

The real question here should be whether my approach to creation of v3
handles is a good one.  I think it is.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 15:48:32 -0500

> (3) Mixing context handles for multiple versions of RPCSEC_GSS in related operations is going to be a common case for compound authentication (e.g., v1 "parent" handle + v3 "child" handle).  This i…

These two go together.

IMO mixing handles from v1 and v2 is a good feature to have: it allows
clients to start with v1 and move up to v3.  I don't know what's
confusing here.  Another objection along the lines of yours might be
that v3 requires either v1 or v2, thus it cannot stand alone, but why
would that be a problem?  I don't know.

I'll grant that this approach does increase the number of round-trips
needed (by one).  This is a much more serious objection, IMO.  I
traded protocol and implementation complexity for a round-trip.  I
think a round-trip is a fair price for this simplification, but maybe
the WG would disagree.

If we want to optimize for fewer round-trips then making use of v1/2
handles in v3 becomes pointless, and v3 then needs to gain an
equivalent of INIT/CONTINUE procedures, only here those would bear
context tokens for up to two contexts at once, and use of the GSS-API
channel bindings input would be made to do the compound and channel
binding operations in one go and without extra round-trips.

Nico
--

---

From: <[email-masked]>
Date: Thu, 12 May 2011 16:46:01 -0400

> one would have to ask whether that's allowable

Kindly stop changing the subject.  My concern is not "allowable" - my concern is "robust."

> handles is a good one.  I think it is.

Gee, that was obvious :-).  Needless to say, I continue to disagree.

Thanks,
--David

> Sent: Thursday, May 12, 2011 4:24 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 16:05:43 -0500

> Kindly stop changing the subject.  My concern is not "allowable" - my concern is "robust."

But I don't see any robustness issue.  You'd not send one program
version's RPCs to the wrong program version.  It's that simple.  It's
not like it happens often that RPCs go to the wrong destination in
this way, nor that it matters then whether the receipient then handles
the wrong message as if it'd gone to the right place.  Seriously, that
doesn't concern me in the least.

The code commonality argument you made is much stronger.  My approach
to code re-use had been to make use of v1/v2 handles in v3.  If
there's consensus to make v3 stand alone I can absorb v1 (but not v2
-- there would be no point) into v3.

Then there's the additional round-trip issue.  Any comments on that?

> Gee, that was obvious :-).  Needless to say, I continue to disagree.

Well, so I dismiss the argument that I find weakest (the robustness
argument).  Don't give up on the others if you feel strongly.

Nico
--

---

From: <[email-masked]>
Date: Thu, 12 May 2011 17:18:22 -0400

I think that I would prefer to see RPCSEC_GSSv3 made its own entity and not depend upon RPCSEC_GSSv1.  That round trip will add up over the years...  :-)

The format and structs can be as close to the same as appropriate, which might make it easier to implement.

		ps

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Thursday, May 12, 2011 4:49 PM
To: Black, David
Cc: [email-masked]
Subject: Re: [nfsv4] RPCSEC_GSSv3 procedure numbering

These two go together.

Nico
--
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Thu, 12 May 2011 17:02:14 -0400

> would that be a problem?  I don't know.

We agree that mixing handles from v1, v2 and v3 is good, including the ability
to use a v3 "child" handle with a v1 or v2 "parent" handle.

My view is that having the meaning of the procedure number not depend on the
version of the handle would be better.

The "round-trips" discussion is a red herring ...

Thanks,
--David

> > (2) Independent of the "distinct procedure numbering spaces", the RPCSEC_GSS procedures for
> v1/v2/v3 are likely to be implemented in the same or related code modules.  Having the on-the-wire
> procedure numbers be global to that module or modules improves robustness.
> >
> > (3) Mixing context handles for multiple versions of RPCSEC_GSS in related operations is going to
> be a common case for compound authentication (e.g., v1 "parent" handle + v3 "child" handle).  This
> is not like NFSv3 vs. NFSv4 which are mutually exclusive, hence do not offer this opportunity for
> potential confusion.
> 
> These two go together.
>

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 12 May 2011 14:26:47 -0700

I agree with David.

To simply implementation allocate new proc
numbers.  I cannot fathom the reason to
reuse proc numbers between revs of rpcsec_gss.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 12 May 2011 14:26:51 -0700

I agree with David.

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 17:07:08 -0500

> reuse proc numbers between revs of rpcsec_gss.

I don't see what difference that could make.  But if there's consensus
for it, it's a trivial change to make.  Personally I'm not for this
change just because some find it offensive :)

(Also, I sure hope the one implementor we've heard from so far hasn't shipped!)

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 17:08:23 -0500

> The format and structs can be as close to the same as appropriate, which might make it easier to implement.

Well, I could post what the XDR would look like if there was zero
dependency on v1/v2, and if that additional round-trip was optimized
away.

---

From: Jim Rees <[email-masked]>
Date: Thu, 12 May 2011 20:22:47 -0400

Nico Williams wrote:

I'm with David on this one.  I see no reason to overload the op id even if
they are in separate name spaces.  I envision myself poring over a tcpdump,
looking at the id and trying to remember which op goes with which name
space.  Why make life more difficult than it has to be?  Are we in danger of
running out of proc numbers?

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 19:37:04 -0500

> running out of proc numbers?

Look, let's not be silly.  There's no significance to these numbers.
They don't make life difficult for anyone.  If left to my own devices
I'd as soon use large prime numbers, but I bet that wouldn't please
anyone either.  This is what we call bikeshedding.

In any case, I'll be too busy until the second week of June, so if
there's any urgency you'll have to rely on the I-D editor to make any
changes.

Nico
--

---

From: "Spencer Shepler" <[email-masked]>
Date: Thu, 12 May 2011 17:54:40 -0700

One possible reason to choose non-overlapping numbers is
to deal with implementations in the field that do not
currently check the version and thus would respond incorrectly
to a client sending RPCSEC_GSSv3.

For that reason, it may be wise make this non-overlapping choice.

Spencer

btw: my color choice is blue

> Sent: Thursday, May 12, 2011 5:37 PM
> To: Jim Rees
> Cc: [email-masked]
> > I'm with David on this one.  I see no reason to overload the op id
> > even if they are in separate name spaces.  I envision myself poring
> > over a tcpdump, looking at the id and trying to remember which op goes
> > with which name space.  Why make life more difficult than it has to
> > be?  Are we in danger of running out of proc numbers?
> 
> They don't make life difficult for anyone.  If left to my own devices I'd
> as soon use large prime numbers, but I bet that wouldn't please anyone
> either.  This is what we call bikeshedding.
> 
> In any case, I'll be too busy until the second week of June, so if there's
> any urgency you'll have to rely on the I-D editor to make any changes.
> 
> Nico
> --

---

From: "Matthew N. Dodd" <[email-masked]>
Date: Thu, 12 May 2011 21:46:22 -0400

> reuse proc numbers between revs of rpcsec_gss.

I'm wrapping up one and a half implementations and can't see how it
would simplify things.

If you're going to complain about procedure numbers I'd expect you guys
to have noticed the more serious 'handle_version' in the GSSv3 cred
appearing before the handle and causing implementation issues, but so
far nobody has said anything about that.

>>>> v2 added a procedure. Â If its procedure namespace were the same as v1
>>> Kindly stop changing the subject. Â My concern is not "allowable" - my
>>> concern is "robust."
>>
>>>> handles is a good one. Â I think it is.
>>>
>>> Gee, that was obvious :-). Â Needless to say, I continue to disagree.
>>

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 21:13:47 -0500

> For that reason, it may be wise make this non-overlapping choice.

Are there any such?  I'd like to make fun of them :)  But finally, a decent
reason for such a change!

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 12 May 2011 21:14:59 -0500

> far nobody has said anything about that.

Do you want that changed?

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 21:33:41 -0500

wrote:
> Are there any such?  I'd like to make fun of them :)  But finally, a
decent reason for such a change!

Actually, that's not a good reason.  Servers that do that should be found
and fixed, and hopefully they handle what they think is. garbage correctly.

---

From: "Matthew N. Dodd" <[email-masked]>
Date: Thu, 12 May 2011 22:41:35 -0400

> Do you want that changed?

Well, a possible justification is that the current ordering is sure to
expose implementations that are non-conformant.

Reordering would probably eliminate a bunch of messy union accessor
macros and case statements.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 12 May 2011 22:10:25 -0500

> macros and case statements.

Then propose the set of changes you would like to see.