Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Is sue

From: "Carolina Canales Valenzuela (ECE)" <[email-masked]>
Date: Thu, 13 Jun 2002 11:21:39 +0200

Hi,
perhaps with all this discussion I've lost the point and I don't see something that is very obvious but...why should a NAS send a Vendor-specific command to a AAA server that doesn't understand it, or vice-versa?
What do we have the whole CER/CEA mechanism for? (I thought this was used to reach an agreement about the applications that each peer understands, even if they are Vendor-specific)...

Thank you!
Carolina

>-----Original Message-----
>From: Bernard Aboba [mailto:[email-masked]]
>Sent: Thursday, June 13, 2002 6:39 AM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands
>Issue
>
>
>> 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.
>
>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: Bernard Aboba <[email-masked]>
Date: Thu, 13 Jun 2002 05:43:48 -0700 (PDT)

> What do we have the whole CER/CEA mechanism for? (I thought this was used to reach an agreement about the applications that each peer understands, even if they are Vendor-specific)...

As constituted, the CER/CEA mechanism does not prevent this. For example,
the draft states that an accounting server may advertise the "Relay
application." However, that doesn't mean the accounting server can handle
any VSC that is thrown at it.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 13 Jun 2002 07:35:54 -0700

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

> > Hi,
> > perhaps with all this discussion I've lost the point and I
> don't see something that is very obvious but...why should a NAS
> send a Vendor-specific command to a AAA server that doesn't
> understand it, or vice-versa?
> > What do we have the whole CER/CEA mechanism for? (I thought
> this was used to reach an agreement about the applications that
> each peer understands, even if they are Vendor-specific)...
> >
> > Thank you!
> > Carolina
>

Actually, I think it does.  Section 2 says "Diameter Relays and Redirect
agents are, by definition, protocol transparent, and MUST transparently
support the Diameter base protocol, which includes accounting, and all
Diameter applications.", and section 1.2.4 says,

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

Since what exemplifies a Diameter application is the definition of "at least
one Command Code", it sure sounds like the hypothetical accounting server
better be able to handle anything; either that, or we redefine the term
"relay".

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Jun 2002 15:36:21 -0700 (PDT)

> better be able to handle anything; either that, or we redefine the term

Yes, I agree that this is what the hypothetical accounting server must be
able to do to advertise the relay application. However, I'm saying that,
unlike a relay, an accounting server can't actually fulfill that
requirement. While a relay can forward commands it doesn't understand, an
accounting server can't carry out command it doesn't understand, although
it *can* write to disk Vendor-Specific AVPs it doesn't understand.