Subject: RE: [AAA-WG]: Vendor Command Code resolution

From: <[email-masked]>
Date: Tue, 25 Jun 2002 07:17:09 +0300

Hi Glen,

> So is this an actual proposal, a meeting report, or the report of a decision
> (ordinarily I would never suggest the last, since this is the IETF, but it
> has that tone...).

Sorry for the tone, it is a strong proposal.  What I mean by that, is that
the IESG has stated that they are not comfortable with VSCs and this needs
to be resolved before Diameter can be Diameter can be progressed.  3GPP
has 2 Diameter extentions, that use VSCs and so we are working on how to 
resolve the issue with as little pain to all of the parties involved.

> > The main issue is that VSCs generally require understanding in an
> > implementation.  Currently, we have no way to manage communication
> > between implementations where there is not support for VSCs that
> > are sent by a Diameter peer.
> 
> That depends upon how you define "manage communication".  At the risk of
> becoming tediously repetitive, I pointed out on this list more than two
> weeks ago (to thundering silence) that there already exists a well-defined
> method to handle unrecognized commands (vendor-specific or otherwise).  For
> convenience, I'll quote it here: "...if a vendor-specific request is sent to
> a box that doesn't support it, the resulting answer (same command code for
> easy identification) will have the E bit set and a result code of
> DIAMETER_COMMAND_UNSUPPORTED.  How much simpler (sic) can you get?".  

I haven't heard any feedback on this, I don't know if it is OK with the IESG,
but I agree that this is simple & affective.  

> Of course, that doesn't help to avoid sending the inappropriate command in the
> first place.  However, there is an easy way to fix this: simply make the
> relationship between application and command code reciprocal.  Right now, I
> believe that the creation of a new application requires the creation of a
> new command code but not vice-versa please correct me if I'm wrong).  In my
> mind, anyway, this relationship has always been reciprocal (i.e., the
> introduction of a new command _requires_ the use of a new application ID.
> If this is done, then I believe that (presupposing that no lying takes place
> during the capabilities exchange process) that it would be impossible to
> send a command that is unsupported by the peer.

I agree with you on the above.
 
> > There is high-level concern that
> > use of VSCs will great interoperability problems.
> 
> If by "high-level" you mean the IESG, my understanding is  that the concerns
> have more to do with the assignation of blame for lack of  interoperability
> than the interoperability problems themselves (maybe Randy can comment on
> this).  Currently, I believe that it would not be a protocol violation to
> add a VSC to a standard application (say, NASREQ) and claim that the result
> is "Diameter",  This is a problem, but I think that my above proposal closes
> that loophole.

In my personal opinion, standardizing new Diameter applications with new
command codes is OK.  I don't think it bothers the IESG.  The unstandardized
command codes is the bothersome bit.

> > Standardization of
> > command codes are prefered.  Standardization bodies using Diameter
> > extensions are strongly encouraged to standardize these.
> 
> I assume that by "standardize these" you mean "standardize these in the
> IETF".  Unfortunately, standardization in the IETF can be a long process and
> as we have noticed deadlines of organizations outside the IETF (e.g., 3GPP &
> 3GPP2) have little effect upon the speed of the process.  For example, 3GPP2
> has been waiting for the IETF to standardize Diameter for almost 4 years
> now; would they (or 3GPP) be pleased to tie their release to what is
> essentially a nondeterministic process?

I hear you - no reason to preach to the converted.  However, do you think
that new command codes are really needed?  I've heard from folks with
much more Radius experience that new Radius command codes are fairly
in frequent.

> >
> > In summary, what is needed to the base specification is:
> >
> > a. Eliminate vendor-specific commands, but keep 
> vendor-specific AVPs.
> >
> > b. Carve out an "experimental" playpen space within the 
> existing command
> >    space, where vendors can create experimental commands.
> >
> > c. Allow use of Application IDs in a broader set of circumstances:
> >      1. To indicate support for a set of vendor-specific 
> AVPs with the 'M'
> >         bit set
> >      2. To indicate support for an "experimental" command
> >
> > As a result, it will no longer be required that an 
> application have a new
> > command (standard or vendor-specific) associated with it.
> >
> > Some implications of this:
> >
> > d. The CER/CEA exchange should prevent sending of 
> Vendor-Specific AVPs
> >    with the 'M' bit set to peers that do not support those AVPs.
> > This means
> >    that the Diameter peers won't need to retry without 'M' bit
> > AVPs after an
> >    "unrecognized AVP" error.
> >
> > e. Conflicts between "experimental" commands are avoided as 
> long as the
> >    application IDs are unique.
> >
> > f. The Application ID space needs to be partioned between
> >    "applications with new 'M' bit AVPs, but no new commands" and
> >    "applications with commands." Reasons for this are 
> described in g.
> 
> "g." discusses only accounting; since the "standard" accounting service just
> logs stuff, the use of the 'M' bit seems uncessary.  So if 3GPP wants to be
> able to set the 'M' bit on VSAs, why?

Let me look into this.

> > g. Two types of generic advertisement are needed. Today we have the
> >    "Relay" advertisement that implies "all applications." But we
> > also need
> >    an "any AVPs" advertisement for Accounting Servers. This 
> allows an
> >    Accounting Server to advertise that it can accept any AVP,
> > without also
> >    implying that it can handle any "experimental" command 
> thrown at it,
> >    which is difficult or impossible to support in practice.
> 
> There is no need for a new advertisement: simply make the
> Acct-Application-Id AVP required in all accounting and capabilities exchange
> messages, and define a value for it in the base protocol that means
> "Standard".

That might work.

thanks for the comments,
John

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 24 Jun 2002 22:00:13 -0700

[email-masked] [mailto:[email-masked]] writes:

> Sorry for the tone, it is a strong proposal.

OK, thanks for the clarification.

> What I mean by that, is that

Better yet, it's already in the protocol!

> command codes is the bothersome bit.

But if non-standard command codes are _never_ included in standard
applications, where is the problem?  If I define a new app that reuses
everything from accounting, say, but adds a VSC, it's still a new app...

> much more Radius experience that new Radius command codes are fairly

Well, RADIUS doesn't really have "command codes" (the analagous construct is
the "Packet Type").  While it's true that no new RADIUS Packet Types have
been standardized, that fact has less to do with the lack of need for them
than other factors.  Several (vendor-specific, non-standard,
non-interoperable) new Packet Types _have_ been defined, though, and are in
widespread use today (see RFC 2882 for an overview).  When you really _need_
a new command code, nothing else will substitute.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Jun 2002 22:19:50 -0700 (PDT)

> a new command code, nothing else will substitute.

Sure. I'd say that RFC 2882 is a good example of justifiable new command
codes. Still, a few new command codes in 7+ years isn't much.

> > > able to set the 'M' bit on VSAs, why?

I have assumed that the 'M' bit is set on accounting AVPs for accounting
servers that drop AVPs they don't understand. That way they can know
whether the AVP is critical or not. However, I have never understood why
an accounting server should behave this way, rather than just writing a
record to disk, in which case the 'M' bit is irrelevant.

Note that even a "disk writing" accounting server cannot handle commands
it doesn't support, since presumably those commands are doing something
different than ACA/ACR (if they aren't, then a new command probably isn't
appropriate).

> > > messages, and define a value for it in the base protocol that means

Unfortunately, there is some confusion about whether it is possible to
advertise the "standard" Acct-Application-ID if a new authentication
application ID is used. Also, there may be some accounting servers that
can't handle any accounting AVPs, and some that can -- and it's necessary
to differentiate them, no?

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 25 Jun 2002 08:50:44 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Glen Zorn
> Sent: den 25 juni 2002 07:00
> To: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Vendor Command Code resolution
>
>

Thanks Glen,
This is something that's been discussed since the interim meeting in Santa
Clara (May-01, if I'm not misstaken)
With the negotiation we have in the protocol today (with the clarification
Glen mentions further down) there is no way a VSC will be sent to a peer
unless the one sending the command is missbehaving. It's also obvious who is
at fault if a standard command code is sent with a vendor specific AVP with
the 'M'-bit set is sent, it's the sender. And it's up to the sender to
decide wether to try again with a modified request/response or to just
realize that it could not get the service requested.

> > > is "Diameter",  This is a problem, but I think that my above

I agree, a new VSC should require a new application id so it can be
negotiated. If we mandate that, I don't see what problem the IESG should
have with a protocol that has nativ support for VSC and vendor specific
AVPs. I would be much more concerned if the protocol didn't have it. As it
is now, we have a way to handle vendor specific applications which doesn't
jeopardize interoperability.

/Fredrik

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 24 Jun 2002 23:54:33 -0700

> codes. Still, a few new command codes in 7+ years isn't much.

True, except that even one breaks interoperability completely.

> different than ACA/ACR (if they aren't, then a new command probably isn't

Of course.

> application ID is used.

Hmm.  Accordin to -11,
   "Application Identifiers are advertised during the capabilities
   exchange phase (see section 5.3). For a given application, there are
   two different ways of advertising support. First, advertising support
   of the application via the Auth-Application-Id implies that the
   sender supports all authentication and authorization command codes,
   and the AVPs specified in the associated ABNFs, described in the
   specification. Second, advertising support of the application via the
   Acct-Application-Id implies that the sender supports the Accounting
   command codes defined in this specification, as well as the
   accounting AVPs defined in the application's specification."

> Also, there may be some accounting servers that

Sorry, but I can't parse that sentence: if an accounting server can't handle
any accounting AVPs, is it still an accounting server?

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 25 Jun 2002 09:06:37 +0200

> Bernard Aboba
> Sent: den 25 juni 2002 07:20
> To: Glen Zorn
> Cc: [email-masked]; [email-masked]

I thought that the base protocol says that each new application must define
it's own accounting specific avps to be sent in accounting requests and
responses. See base 1.2.3

"New Diameter applications MUST define at least one Command Code, the
   expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY
   also define new AVPs. If the Diameter application has any accounting
   requirements, it MUST also specify the AVPs that are to be present in
   the Diameter Accounting messages (see section 9.3)."

I.e. it's possible to advertise support for accounting for each individual
application since we have the accouting-application-id, it's even possible
to advertise support for vendor specific accouting applications. Be
definition, in order to call itself a diameter server one must suport the
base protocol, what you then can do to differentiate the server for
authentication from the ones for accounting is to set the accounting
application id's in the negitiation to say wether you would like to receive
accounting data or not.

/Fredrik

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Jun 2002 05:22:14 -0700 (PDT)

> application id's in the negitiation to say wether you would like to receive

The problem is that some have interpretted the above text to mean that
in order to use a new application ID, they MUST create a new Command
Code, even if one wouldn't otherwise be needed. For example, if they
define a new set of Vendor-Specific AVPs with the 'M' bit set, and would
like to only send those AVPs to a compatible peer. This requires a new
Application ID, but the above text also indicates it requires a new
Command Code. This doesn't make sense.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Jun 2002 05:27:09 -0700 (PDT)

> any accounting AVPs, is it still an accounting server?

The text above is contradictory - it implies that Acct-Application-Ids
only imply support for new accounting AVPs in the application spec, as
well as the "standard" accounting command codes ("this specification").
However, elsewhere it indicates that a new application ID requires a new
command code.

If an accounting server can't handle non-supported AVPs with the 'M' bit
set, it is still an accounting server. However, I'd claim that it is
better to have a new Application ID defined (without a new command code)
to enable capabilities negotiation so those 'M' AVPs are not sent, than it
is to send them and get an error message back.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 25 Jun 2002 16:38:33 +0200

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: den 25 juni 2002 14:22
> To: Fredrik Johansson
> Cc: Glen Zorn; [email-masked]; [email-masked]
> Code, even if one wouldn't otherwise be needed.

I can't realy see what you mean, from the above text I believe it's obvious
that a command code is required when a new application id is defined.  On
the other hand, if one can coupe with just adding VSAs no an existing
command code, no application id is required.

For example, if they
> Command Code. This doesn't make sense.

Do you mean that it doesn't make sence that you can't negotiate to whom you
may send VSAs?

/fredrik

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Jun 2002 07:07:59 -0700 (PDT)

> Do you mean that it doesn't make sense that you can't negotiate to whom
> you may send VSAs?

Yes. The inability to know whether a peer supported VSAs was the supposed
limitation of RADIUS that Diameter capabilities negotiation was supposed
to fix. And vendors do appear to want to fix this -- since they're using
Application IDs (and adding unnecessary command codes) in order to address
the issue.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 25 Jun 2002 17:08:33 +0200

I can agree that it's a nice to have feature, but awfully hard to get. E.g.
it's hard to advertise support for Vendor A's VSA within the mobile ip
application without saying that also all future VSA's from vendor A within
mobile ip is also supported.

but if someone can come up with a easy way of differentiate the VSA's
available today from the ones defined in the future, I'm all for it.
Perhaps having version numbers on the VSA within a specific application,
then one can say in the negotiation that I support vendor A's mobile ip VSA
up to version nr X. Hmm, gets complicated

/fredrik

> Sent: den 25 juni 2002 16:08
> To: Fredrik Johansson