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

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Thu, 13 Jun 2002 11:31:14 +0200

Exactly. Isn't the faulty case that a peer responds to a standard command with a VSC, identical to the faulty case where a peer responds to a standard command with a respond not corresponding to the request? 

VSCs are not different to any other standard command with respect to interoperability.

BR/Miguel

-----Original Message-----
From: Carolina Canales Valenzuela (ECE)
[mailto:[email-masked]]
Sent: jueves, 13 de junio de 2002 11:22
To: 'Bernard Aboba'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands
Is sue

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