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

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

Hi,

Our understanding of the whole issue is that interoperability must be guaranteed by clarifications in the base protocol, not by putting requirements on vendors implementing extensions. The mechanisms defined in the protocol must be robust enough. Recommendations for at least informal documentation are acceptable, but we don't think they should be mandated.

Carolina and I have checked the interoperability scenarios prepared by Bernard, and come to the following conclusions:

Case 1: VSC sent from NAS to AAA server.

1a and 1c are situations in which both ends support a vendor-specific applicaton of name Frobnitz. Commands are understood and authrorazion is handled by the application.

1b. AAA server does not support Frobnitz. The client should not send Frobnitz commands, because the server has not indicated support of such application in CER/CEA. Anyway, if it does, we have the Result-Code = DIAMETER_COMMAND_UNSUPPORTED and the 'E' bit, which use is described in 7.2.

No changes required.

Case 2: VSC sent from AAA server to NAS.

2a. We would generalize this interoperatility problem saying that a peer sends a command and its counterpart responds with a command that is not the command expected as a response (given that the receiving side supports the request). This is independent of whether the application to which the command belongs is standard or vendor-specific.

CHANGE 1.

We think that it is implicit that the command code of a request and the corresponding response are always identical. This is how all the commands are defined in the base and the different applications. We could include the following clarifying text in 6.2 Diameter Answer Processing, as a new bullet:

"- The same command code in the request is used in the answer."

By doing this, we guarantee that a peer cannot respond with a different command.

CHANGE 2

2b. We consider this case identical to 1b. Anyway, the change proposed by Bernard making clear that unsolicited VSCs sent from AAA server to NAS are to be treated as non-mandatory adds even more clarity.

2c represents no interoperability problem.

To summarize, in order to solve potential interoperability problems, it is to the base protocol itself where we have to add clarifications. Mandating informal documentation is acceptable, but in the end it is the protocol who must be robust enough.

Best regards,
Carolina & Miguel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: jueves, 13 de junio de 2002 11:41
To: [email-masked];
[email-masked]
Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands
Is sue

Hi,

We have no text in the current document that says this.
Please submit text.

John

> -----Original Message-----
> From: ext Miguel-Angel Pallares-Lopez (ECE)
> [mailto:[email-masked]]
> Sent: 13 June, 2002 12:31
> To: Carolina Canales Valenzuela (ECE); 'Bernard Aboba'; Loughney John
> (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor 
> Specific Commands
> Is sue
> 
> 
> 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.
> >
>

---

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

Miguel-Angel Pallares-Lopez (ECE)
[mailto:[email-masked]] writes:

> Hi,
>
> Our understanding of the whole issue is that interoperability
> must be guaranteed by clarifications in the base protocol, not by
> putting requirements on vendors implementing extensions. The
> mechanisms defined in the protocol must be robust enough.
> Recommendations for at least informal documentation are
> acceptable, but we don't think they should be mandated.
>
> Carolina and I have checked the interoperability scenarios
> prepared by Bernard, and come to the following conclusions:
>
> 1a and 1c are situations in which both ends support a
> vendor-specific applicaton of name Frobnitz. Commands are
> understood and authrorazion is handled by the application.
>
> 1b. AAA server does not support Frobnitz. The client should not
> send Frobnitz commands, because the server has not indicated
> support of such application in CER/CEA. Anyway, if it does, we
> have the Result-Code = DIAMETER_COMMAND_UNSUPPORTED and the 'E'
> bit, which use is described in 7.2.
>
> No changes required.
>
> 2a. We would generalize this interoperatility problem saying that
> a peer sends a command and its counterpart responds with a
> command that is not the command expected as a response (given
> that the receiving side supports the request). This is
> independent of whether the application to which the command
> belongs is standard or vendor-specific.
>
> CHANGE 1.
>
> We think that it is implicit that the command code of a request
> and the corresponding response are always identical. This is how
> all the commands are defined in the base and the different
> applications.

It is more than implicit, it's explicit.

> We could include the following clarifying text in
> 6.2 Diameter Answer Processing, as a new bullet:
>

I'm not sure that this would help.  After all, section 3.1 of the current
draft begins: "Each command Request/Answer pair is assigned a command code,
and the sub-type (i.e. - request or answer) is identified via the 'R' bit in
the Command Flags field of the Diameter header", and section 3.3 says "Both
the request and the answer for a given command share the same command code.
The request is identified by the R(equest) bit in the Diameter header set to
one (1), to ask that a particular action be performed, such as authorizing a
user or terminating a session.  Once the receiver has completed the request
it issues the corresponding answer...".  These passages seem to me to say
almost exactly the same thing as your suggested text, and quite clearly.  I
guess it's not clear to me how even further repetition is going help.

>
> CHANGE 2
>
> 2b. We consider this case identical to 1b. Anyway, the change
> proposed by Bernard making clear that unsolicited VSCs sent from
> AAA server to NAS are to be treated as non-mandatory adds even
> more clarity.

I'd _really_ like it if someone could show where in base-11 it even suggests
that a VSC can be "mandatory".
> To summarize, in order to solve potential interoperability
> problems, it is to the base protocol itself where we have to add
> clarifications. Mandating informal documentation is acceptable,
> but in the end it is the protocol who must be robust enough.
>
> Best regards,
> Carolina & Miguel
>