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

From: Bernard Aboba <[email-masked]>
Date: Mon, 5 Jul 2004 17:55:59 -0700 (PDT)

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: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Jul 2004 11:21:04 -0400

Hi Bernard,

Your interpretation totally makes sense to me.

Yoshihiro Ohba