Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage

From: "Christopher Richards" <[email-masked]>
Date: Tue, 6 Jul 2004 10:55:43 -0400

Hi Bernard, All,

I still have a problem with the use of an application-id of a different
application in a command. 

Firstly, there is section 3 of RFC 3588. It states that the application-id
in the header of any command MUST be the same as the application id in any
relevant AVPs.

Secondly, what if a Diameter peer does not want to use a base application
but only wants to use some other application. It wants to advertise support
for application X but does not want to be used for a base application
(regardless of it's ability to support the base applications). For example,
an operator may want to disable a node's Diameter Accounting application
while maintaining some other application(s). The Diameter protocol should
not force the node to advertise support for an application that is not
enabled.

Regardless of which spec a command is defined, a command is only relevant to
the application to which the command is destined. E.g. if a management node
wants to Abort a DCCA session on the DCCA client, it only makes sense to
send the ASR to the DCC client application - since it is the DCC client
application which is handling the session.

Cheers,
Chris

Tel:	+1 613 763 8031
ESN:	393 8031

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: July 5, 2004 8:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: [AAA-WG]: Issue 464: Application-Id Usage

Pasi Eronen noted:

>This seems to imply that a new application can't borrow only
>a subset of mandatory commands from an existing application..?
>
>Otherwise we could get a conflict. Let's assume that application X has 
>commands C1 and C2, and application Y defines a new command C3 and 
>borrows C1 from X (without any new mandatory AVPs).

>It seems that a Diameter server implementing only Y can't advertise 
>support for X, since it does not implement C2. But using application 
>identifier of X for C1 is not allowed either, since this seems to 
>contradict the text saying that "When a request is routed, the target 
>server MUST have advertised the Application Identifier (see Section 
>2.4) for the given message.

>Another related issue is whether two different applications could use 
>the same AVP (in the same command and with the same application ID) for 
>slightly different purposes.  At least this happens all the time with 
>RADIUS, but perhaps the different uses can be distinguished even if the 
>application ID is the same..."

If application Y defines a new command C3, then it needs to advertise
application Y, since otherwise it can't be guaranteed that Diameter peers
will select a path that will allow command C3 to be sent from Diameter
client to server.

The question is whether it should also advertise the application that it
inherited command C1 from, even though it doesn't support command C2.

If the application-Id in question is Diameter Base (Application-ID 0) I
think there is no issue, since this is mandatory-to-implement for all
Diameter peers.

However, if we are talking about multiple inheritance (e.g. inheriting
commands from an Application-Id other than Base authentication and
accounting) I think we have a problem.  I'd interpret RFC 3588 as allowing
an out for this, since the number of round-trips is changed (e.g. the common
is disallowed altogether).

Does this make sense?

In this particular case, is there any issue with advertising Diameter Base
Common Messages as well as EAP?  I think there isn't because EAP supports
all Base commands.  However, there might be an issue with advertising NASREQ
where the NAS or server doesn't support PAP/CHAP (AAR/AAA).

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 6 Jul 2004 10:27:32 -0700

[email-masked] <mailto:[email-masked]> writes:

> Hi Bernard, All,
> 
> I still have a problem with the use of an application-id of a
> different application in a command. 
> 
> Firstly, there is section 3 of RFC 3588. It states that the
> application-id in the header of any command MUST be the same as the
> application id in any relevant AVPs.  
> 
> Secondly, what if a Diameter peer does not want to use a base
> application but only wants to use some other application. It wants to
> advertise support for application X but does not want to be used for
> a base application (regardless of it's ability to support the base
> applications). For example, an operator may want to disable a node's
> Diameter Accounting application while maintaining some other
> application(s). 

While I can certainly understand the desire of some operators to treat
RFCs as if they were ala carte menus ("I'll take the authentication and
authorization with a side of credit control, hold the accounting" ;-),
that doesn't match my understanding of how the documents are meant to be
used.  This is certainly an issue in the purview of the IESG, but my
understanding is that unless an implementation adheres to all of the
MUSTs in a Standards-Track RFC, it cannot be said to conform to that RFC
(RFC 2026).

> The Diameter protocol should not force the node to
> advertise support for an application that is not enabled. 

I don't think that accounting is an application, from a Diameter
perspective.  As I read RFC 3588, accounting is an integral part of the
Diameter base protocol which _all_ Diameter peers must support.  In
other words, if a "Diameter" peer doesn't support accounting, it's not a
Diameter peer.  This is not to say that a Diameter peer has to _do_
anything with accounting data, for example, but it must not reject it.
    
> 
> Regardless of which spec a command is defined, a command is only
> relevant to the application to which the command is destined. E.g. if
> a management node wants to Abort a DCCA session on the DCCA client,
> it only makes sense to send the ASR to the DCC client application -
> since it is the DCC client application which is handling the session.

Yes, but only if the semantics of a "session" are the same for DCCA as
Diameter base; it's not clear to me that this is the case.

>> Otherwise we could get a conflict. Let's assume that application X
>> has commands C1 and C2, and application Y defines a new command C3
>> and borrows C1 from X (without any new mandatory AVPs).
> 
>> the same AVP (in the same command and with the same application ID)
>> for slightly different purposes.  At least this happens all the time
>> with RADIUS, but perhaps the different uses can be distinguished
>> even if the application ID is the same..."
> 
> application Y, since otherwise it can't be guaranteed that Diameter
> peers will select a path that will allow command C3 to be sent from
> Diameter client to server.   
> 
> The question is whether it should also advertise the application that
> it inherited command C1 from, even though it doesn't support command
> C2.  
> 
> If the application-Id in question is Diameter Base (Application-ID 0)
> I think there is no issue, since this is mandatory-to-implement for
> all Diameter peers.  
> 
> However, if we are talking about multiple inheritance (e.g.
> inheriting commands from an Application-Id other than Base
> authentication and  
> 
> accounting) I think we have a problem.  I'd interpret RFC 3588 as
> allowing an out for this, since the number of round-trips is changed
> (e.g. the common is disallowed altogether).  
> 
> Does this make sense?
> 
> In this particular case, is there any issue with advertising Diameter
> Base Common Messages as well as EAP?  I think there isn't because EAP
> supports all Base commands.  However, there might be an issue with
> advertising NASREQ where the NAS or server doesn't support PAP/CHAP
> (AAR/AAA).    

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire