Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions

From: <[email-masked]>
Date: Thu, 13 Jun 2002 07:06:42 +0300

HI Glen,

> Please define the term "work". 

Continue operation - i.e. - not crash, and preferably not abort.  Basically,
try to have fall back operation.  

I think the scenario would be that I am roaming and trying to be authenticated,
if the visited network implenents a vendor extension which prevents communication
to my home network because my home network does not implement the vendor 
extension, then this is a bad thing.

John

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Jun 2002 21:39:29 -0700 (PDT)

> extension, then this is a bad thing.

I think that it is not very hard to go through the possible cases here,
identify the potential interoperability problems with Vendor-Specific
Commands, and fix them. An analysis follows.

The first important thing to understand (which should already be clear
from the spec), is that VSCs MUST NOT be used were an existing command and
vendor-specific AVPs would do the job. If this basic precept is followed,
then many of the possible interoperability problems evaporate and the
analysis becomes relatively simply.

If this premise can be accepted, then presumably the vendor specific
command is used to provide a fundamentally different service from
existing Diameter applications.  Otherwise, an existing application
would be used with vendor-specific AVPs, which could be mandatory or non-mandatory.

For example, addition of vendor-specific AVPs to the existing ACR/ACA
commands does not require a vendor-specific command. However, if you
wanted to authenticate the Frobnitz service, which requires Frobnitz
authentication and authorization AVPs, AS WELL AS NEW CODE ON THE AAA
SERVER, then a new command MAY be appropriate. "NEW CODE" is in upper case
because in my mind this is what differentiates VSCs from vendor-specific
AVPs.

Given this basic understanding of when VSCs are needed, there are two
major cases to analyze:

1. VSC sent from NAS to AAA server.
2. VSC sent from AAA server to NAS.

Case 1: VSC sent from NAS to AAA server.

If the NAS then sends a vendor-specific Frobnitz command to the AAA
server, and Frobnitz is fundamentally different service, several outcomes
are possible:

a. The AAA server supports Frobnitz, but the user isn't authorized for
Frobnitz.

b. The AAA server doesn't support Frobnitz.

c. The AAA server supports Frobnitz, and the user is authorized for it.

In case a, the server will respond to the Frobnitz command, but the user
will not be authorized.

In case b, the command won't be recognized, and as a result, the user will
not be allowed to access the Frobnitz service. From the user perspective,
the result is indistinguishable from case a, but from the NAS perspective
the difference is between receiving a Reject and receiving an Error
Message.

In case c, the user may gain access to the Frobnitz service, depending on
the outcome of the authentication.

Assuming that Frobnitz is really a new application, not just an existing
application adorned with a VSC, then I'd claim that there is no
interoperability problem in outcomes a-c. It would make little difference
if instead of a VSC, the NAS sent an existing command with a NAS-Port-Type=Frobnitz.

If the AAA server doesn't understand what Frobnitz is, it probably shouldn't be
blindly authorizing access to it. Most AAA servers I've seen are set up
with policies that vary for bu NAS-Port-Type (e.g. different for PPP, VPN,
802.11, Mobile IPv4, etc.), so as to reject services that the home server
isn't explicitly set up for.

Case 2: VSC sent from AAA server to NAS.

There are several cases here:

a. NAS sends a standard command to AAA server, which responds with the
Frobnitz VSC.

b. AAA server sends an unsolicited Frobnitz command to the NAS.

c. NAS sends a Frobnitz Request to the AAA server, which responds with a
Frobnitz Answer.

I'd claim that case a) is a legitimate interoperability problem and should
be prohibited. That would require language saying "In response to an ACR,
the AAA server MUST send an ACA..." I'd suggest we make sure that we have
this language for all standard Diameter commands.

Case b) is only an interoperability issue if the NAS were to change user
state as a result of not understanding the Frobnitz command. If the NAS
can silently discard Frobnitz without change of state, then this is
effectively a "non-mandatory VSC" and there is no interoperability
problem. I'd suggest that we add some language about processing
unsolicited VSCs.

Case c) is not an interoperability issue, since both peers support
Frobnitz.

Based on this analysis, it would seem to me that the issue can be resolved
with a few small changes:

a. Language to make it crystal clear that VSCs MUST NOT be sent in
response to standard commands.

b. Language to make it crystal clear that unsolicited VSCs sent from AAA
server to NAS are to be treated as non-mandatory.

c. Language to make it clear that VSCs MUST NOT be used when
vendor-specific AVPs could be added to standard commands instead,
achieving the same objective.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 13 Jun 2002 04:03:56 -0700

> try to have fall back operation.

Isn't that behavior already defined in the document?

> extension, then this is a bad thing.

Maybe, maybe not: if for some reason the visted network needs the extension
to operate correctly (not that I can think of such a circumstance, but it's
hard to imagine your example, too), I would prefer denial of access to
unexplained, bizarre behavior (crash failure is almost always preferable to
Byzantine failure).