Subject: [AAA-WG]: Decision time was: Mandatory Vendor-specific AVP's

From: <[email-masked]>
Date: Fri, 14 Jun 2002 11:06:52 +0300

Hi all,

> It's reasonable and isn't it something we have today.
> 
> If a vendor A sends a Vendor specific AVP with the 'M'-bit marked to vendor
> B, vendor B either understands it and is happy or doesn't understand it and
> sends an error back and denies the service. In the latter case, Vendor A is
> then the one to blame and has the option to try to request the service
> without the AVP (ofcourse with a different service as result) 
> or to give up.

I think we are arguing about the wrong thing.  There is concern
by the IESG that vendor extensions may cause interoperability
problems.  I don't think that anyone desires interop problems.

The questions is, do we have the information in the Base Spec
to overcome these concerns.  The 3 possible answers are:

	1) No we don't
	2) Yes we do, but it is not stated well enough
	3) Yes we do and anyone who read the document would know it.

I suggest we are at point 2).  I do think Randy has read the document,
and I think the burden of proof is on us to ensure the document
is clear. Therefore, I suggested improved 
text yesterday.  This text is included at the bottom of the mail.

Please comment.
John

====

1.2  Approach to Extensibility

   The Diameter protocol is designed to be extensible. The extensibility 
   includes:

      - Defining new AVP values.
      - Creating new AVPs
      - Creating new authentication/authorization applications
      - Creating new accounting applications
      - Application authentication procedures

   Reuse of existing AVP values, AVPs, applications and command codes are
   is strongly recommended.  Reuse simplifies standardization effort,
   implentation effort and avoids potential interoperability issues.

1.2.1  Standardized Extensions Versus Vendor-Specific Extensions

   Diameter can be extended by standards track documents in the IETF.
   The benefit of this is that the extensions become Internet standards,
   allowing for wider possible deployment and higher assurance of 
   interoperability.  It is strongly recommended that extensions to
   Diameter be made by standards-track RFCs.

   Vendor-specific extensions are allowed, and MUST be registered through
   IANA (see section 11.2).  However, vendor-specific extensions MUST NOT
   harm interoperability of standards-based Diameter implementations.

   Vendor-specific commands MUST NOT be used where an existing command plus a
   vendor-specific AVPs would the same objective. If this basic precept is 
   followed, then most interoperability problems are solved. Vendor-specific 
   commands MUST NOT be sent in response to standard commands.  Unsolicited VSCs 
   sent from a AAA server to a NAS are to be treated as non-mandatory. All 
   vendor-specific Diameter commands require Informational RFCs documenting 
   the command unless for Private Use as described in Section 11.2.1.

   As a general rule, any errors involving Vendor-specific AVP marked with 
   the 'M' bit are considered the fault of the side setting the 'M' bit (see
   Section 4.1).

1.2.2  Defining New AVP Values

   New applications should attempt to reuse AVPs defined in existing
   applications when possible, as opposed to creating new AVPs. For AVPs
   of type Enumerated, it is possible the application requires a new
   value to communicate some service-specific information.

   In order to allocate a new AVP value, a request MUST be sent to IANA
   [IANA], with a detailed explanation of the value and document on the 
   value.

1.2.3  Creating New AVPs

   When no existing AVP can be used appropriately to communicate some
   service-specific information, a new AVP should be created. The new
   AVP being defined MUST follow one of the types listed in section 4.3.
   In the event that a logical grouping of AVPs is necessary, and
   multiple "groups" are possible in a given command, it is highly
   recommended that a Grouped AVP be used (see Section 4.5).

   In order to create a new AVP, a request MUST be sent to IANA, with a
   detailed explanation of the AVP, its type and possible values.
   Furthermore, the request MUST include the commands that would make
   use of the AVP.

1.2.4  Creating New Authentication Applications

   Should a new application require Diameter support, but it cannot fit
   within an existing application without requiring major changes to the
   specification, it may be desirable to create a new Diameter
   application. Major changes to an application include:

      - Requiring a whole different set of mandatory AVPs to a command
      - Requiring a command that has a different number of round trips
        to satisfy a request (e.g. application foo has a command that
        requires one round trip, but new application bar has a command
        that requires two round trips to complete).
      - The method used to authenticate the user is drastically
        different from any existing application, and the authentication
        information cannot be carried within the AVPs defined in the
        application.

   Note that the creation of a new application should be viewed as a
   last resort.

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

   When possible, a new Diameter application SHOULD attempt to re-use
   any existing Diameter AVP, in order to reduce the possibility of
   having multiple AVPs that carry similar information.

   Every Diameter application specification MUST have an IANA assigned
   Application Identifier (see section 2.4).

1.2.5  Creating New Accounting Applications

   Services that have an Application Identifier MUST use the same
   identifier also to identify the service when Diameter accounting is
   used.

   There are services that only require the use of Diameter accounting.
   Such services need to define the service specific AVPs that must be
   carried in the Accounting-Request/Answer messages, but do not need to
   define command codes. Application Identifiers are, however, still
   required for accounting due to the Diameter capability discovery
   process. Every accounting application MUST have either an IANA
   allocated Application Identifier, or a vendor specific Application
   Identifier.

   Note that the creation of a new application should be viewed as a
   last resort and should be used only when Vendor-Specific AVPs are
   insufficient. In most cases, reusing an existing Application ID with
   Vendor-Specific AVPs should work. For example, many accounting
   servers are set up to write AVPs to disk, so they can handle even
   mandatory vendor-specific AVPs that they don't understand.

   This is why "disk writing" accounting servers should advertise
   themselves as "Relays" that can handle any Application ID, including
   Vendor-Specific.

   When possible, a new Diameter accounting application SHOULD attempt
   to re-use any existing Diameter AVP, in order to reduce the
   possibility of having multiple AVPs that carry similar information.

   Every Diameter accounting application specification MUST have an IANA
   assigned Application Identifier (see section 2.4).

1.2.6  Application Authentication Procedures

   When possible, applications SHOULD be designed such that new
   authentication methods MAY be added without requiring changes to the
   application. This MAY require that new AVP values be assigned to
   represent the new authentication transform, or any other scheme that
   produces similar results. When possible, authentication frameworks,
   such as Extensible Authentication Protocol [EAP], SHOULD be used.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Jun 2002 06:10:46 -0700 (PDT)

>    implentation effort and avoids potential interoperability issues.

change "are is strongly recommended" to "is RECOMMENDED."
change "implentation" to "implementation"

>    harm interoperability of standards-based Diameter implementations.

Don't understand meaning of "extensions" here. Is this VSCs? VSAs?
Registration through IANA can't be mandatory for private extensions and
the sentence above seems to contradict text below. Recommend deleting the
above paragraph.

>    vendor-specific AVPs would the same objective. If this basic precept is

change "would the same" to "would meet the same"

>    followed, then most interoperability problems are solved.

change "are solved" to "can be avoided".

>    Vendor-specific commands MUST NOT be sent in response to standard
>    commands.  Unsolicited VSCs

Change this to:

"Vendor-specific commands MUST NOT be sent except where they are known to
be supported as a result of capabilities negotiation between the peers.
Even where they are supported, Vendor-Specific commands MUST NOT be sent
in response to standard commands."

>    the 'M' bit are considered the fault of the side setting the 'M' bit (see

Add:

"A Diameter peer sending a command containing Vendor-Specific AVPs marked
with the 'M' bit, and receiving indication from its peer that this AVP is
not supported, SHOULD retry the command with the Vendor-Specific AVP
removed, if this is feasible. This enables interoperability for standard
applications extended with Vendor-Specific AVPs marked with the 'M' bit."

>    application. Major changes to an application include:

Add "Another reason to create a new Diameter application is if an
extension cannot be implemented merely by adding AVPs to the dictionary,
requiring new code to be implemented on both both Diameter peers."

>       - Requiring a whole different set of mandatory AVPs to a command

Not clear whether this means "AVPs marked with the 'M' bit" or "AVPs
required to be included within the command." I don't believe that a new
command is required just if some AVPs marked with the 'M' bit are added to
a command.

>         information cannot be carried within the AVPs defined in the

Don't agree that this should require a new command. For example, why
should a NAS adding support for a new PPP authentication method require an
entirely new NASREQ application? This is particularly true since we
recommend the opposite and discuss use of EAP as an alternative later in
the section. Recommend deletion.

>    required for accounting due to the Diameter capability discovery

This might create some interoperability problems as discussed below.

>    mandatory vendor-specific AVPs that they don't understand.

Change "mandatory vendor-specific AVPs that they don't understand" to
"even Vendor-Specific AVPs marked with the 'M' bit that are unsupported."

>    themselves as "Relays" that can handle any Application ID, including

Recommend adding:

"Note that even when an accounting server advertises the "Relay"
application it cannot be assumed it can handle unsupported Vendor-Specific
Commands. For example, while an accounting server can handle
Vendor-Specific AVPs within an ACA by writing them to disk, it cannot
assume that a Vendor-Specific Command is equivalent to an ACA, and
carry out the same operation."

>    authentication methods MAY be added without requiring changes to the

Note that this contradicts earlier text which was requested to be removed.

>    This MAY require that new AVP values be assigned to

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 14 Jun 2002 17:56:55 +0200

Perhaps a small modification can be in place to make it even clearer what
messages are possible to send to what peer.

Today a peer can advertise support for a number of different applications,
e.g. nasreq, mobile ip or it can advertise itself as a relay node meaning
that it can relay all messages without having to understand them. This also
means that it can relay all future messages since they must follow the
routing procedures determined by the base protocol. But there is no way to
determine if such a node can support anything locally. And it is still
possible that it can not relay a message unless it in its turn has a
neighbour advertising relay.

If we instead say that a peer can advertise which application it supports
locally or know where to relay on a per application basis it can advertise
it via the application specific IDs. It can also advertise relay if it has
the possibility to relay any message, i.e. it in its turn has a peer
advertising relay that it can send the message to.

By doing this a peer will definitely know if a peer can either handle a
message or pass it thru to another peer. Not just that it might be able to
handle it locally or pass it thru, but there might be an error message
coming back.

Comments?

/Fredrik

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: den 14 juni 2002 15:11
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Decision time was: Mandatory Vendor-specific AVP's
>
>