Subject: RE: [AAA-WG]: Application IDs for EAP

From: "Christopher Richards" <[email-masked]>
Date: Tue, 22 Jun 2004 16:26:50 -0400

But from RFC 3588, section 3:-

Application-ID
      Application-ID is four octets and is used to identify to which
      application the message is applicable for.  The application can be
      an authentication application, an accounting application or a
      vendor specific application.  See Section 11.3 for the possible
      values that the application-id may use.

      The application-id in the header MUST be the same as what is
      contained in any relevant AVPs contained in the message.

From that, I take it that if the Acct-Application-Id AVP contained value x,
then the command header will also contain value x. And if the command
contained AVPs that were relevant to application y, then the command header
would contain application-id = y also.

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: June 22, 2004 4:02 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: Application IDs for EAP

> But how does the other end know that the advertised application 
> support is limited to a message(s) only and the support is not for the 
> application as a whole?

It doesn't.  But that's not an issue if we are talking about advertising
support for Diameter Base Common Messages.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2004 16:51:34 +0300

Christopher Richards wrote:
> From that, I take it that if the Acct-Application-Id AVP
> contained value x, then the command header will also contain
> value x. And if the command contained AVPs that were relevant
> to application y, then the command header would contain
> application-id = y also.

If the Auth/Acct-Application-Id AVP and command header always
contain the same value (except for CER/CEA, where the same AVPs 
are used for a completely different purpose), this makes me wonder 
why the AVP was included at all? 

Or are there cases where the values could be different?

Best regards,
Pasi

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 24 Jun 2004 11:08:00 -0400

Exactly. 

>   application the message is applicable for.   

This statement makes sense. Why would any application put a different
applications Id in the message? It would make the Application-Id in the
message header useless.

>   contained in any relevant AVPs contained in the message.

Again. This makes sense.

CER and CEA must by definition use the base application-id (0) in the
message header because these messages are polling the peer for applications
supported - so the CER must be sent to the "base application". 

But for all other messages sent by an application to a peer application, the
application-id only makes sense (and complies to RFC 3588) if it uses the
application-id of the application that sent the message. It makes no sense
(and violates 3588) if it contains anything else.

Now I agree, that the inclusion of the Acct-Application-Id or
Auth-Application-Id AVPs are then redundant in all messages except CER/CEA
since it will be the same as the value in the message header.

Cheers,
Chris

Tel:	+1 613 763 8031
ESN:	393 8031

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: June 24, 2004 9:52 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Subject: RE: [AAA-WG]: Application IDs for EAP

Christopher Richards wrote:
> From that, I take it that if the Acct-Application-Id AVP contained 
> value x, then the command header will also contain value x. And if the 
> command contained AVPs that were relevant to application y, then the 
> command header would contain application-id = y also.

If the Auth/Acct-Application-Id AVP and command header always contain the
same value (except for CER/CEA, where the same AVPs 
are used for a completely different purpose), this makes me wonder 
why the AVP was included at all? 

Best regards,
Pasi

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 25 Jun 2004 09:38:13 -0400

Hi Bernard, Jari, Pasi, Joe,

So are we all in agreement that the application-id in the message header is
the application-id of the application to which it needs to be handled by
(i.e. the one that generated the message) as per 3588 requirements.

And the only time that the application-id in the message header will be
different from that contained in any optional auth-application-id or
acct-application-id AVPs is in the CER/CEA messages.

Cheers,
Chris 
Tel:    +1 613 763 8031
ESN:    393 8031 

-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH] 
Sent: June 24, 2004 11:08 AM
To: [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: Application IDs for EAP

Exactly. 

Again. This makes sense. 

Cheers, 
Chris 
Tel:    +1 613 763 8031 
ESN:    393 8031

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 25 Jun 2004 10:28:12 -0400

Hi John,

Thanks for the reply.

I understood that the command code space is shared for all applications so
any application defining a new command cannot re-use an existing command
code (It's also managed by IANA). I.e. command codes are unique across all
applications.

Any application that generates a message must indicate the peer application
for which the message is destined. Additionally my understanding is that the
Diameter base definition (app-id 0) is not a true application. I.e. you
cannot implement and instantiate a Diameter base peer. 

RFC 3588 section 3.1 states that the "is used to determine the action that
is to be taken for a particular message.". I don't think the command code is
used to discriminate the application for which the command is destined for -
that's the purpose of the application-id.

Besides, the AVPs in the message are specific to the application to which
the message is destined (e.g. session-id which has no meaning or association
outside the application that the message is destined for).

Cheers,
Chris 

Tel:    +1 613 763 8031
ESN:    393 8031 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: June 25, 2004 9:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]; [email-masked]'
Subject: RE: [AAA-WG]: Application IDs for EAP

Hi Chris, 

In this case, I believe it is implicit that the implementation of an
application must not use commands defined by any other application, except
base commands. 

Otherwise, if the application ID is other than that of the application that
defined the command how would the recipient understand what command
definition to use to interpret it. 

Regards, 

John. 

"Christopher Richards" <[email-masked]> 
Sent by: [email-masked] 
25/06/2004 14:38 
        
        To:        "Christopher Richards" <[email-masked]>,
"[email-masked]'" <[email-masked]>, [email-masked] 
        cc:         
        Subject:        RE: [AAA-WG]: Application IDs for EAP

-----Original Message----- 
From: Richards, Christopher [RICH2:2Q40:EXCH] 
Sent: June 24, 2004 11:08 AM 
To: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: Application IDs for EAP 
Exactly. 
Again. This makes sense. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: June 24, 2004 9:52 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked] 
Subject: RE: [AAA-WG]: Application IDs for EAP 

****************************************************************************
**

The content of this e-mail may be confidential or legally 
privileged. If you are not the named addressee or the intended
recipient please do not copy it or forward it to anyone. If you have 
received this email in error please destroy it and kindly notify the 
sender and [email-masked]. Email cannot be
guaranteed to be secure or error-free, it is your responsibility
to ensure that the message (including attachments) is safe
and authorised for use in your environment.
Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK), 
Pauline Best (UK), Paul Donovan Chief Executive (UK), 
Gerry Fahy, Dermot Griffin, David Boorman (UK),
David Smithwhite (UK), Patrick Teahon, Alfred Kane.
Registered in Ireland at MountainView, Leopardstown, Dublin 18. 
Co Reg No.: 326967 VAT Reg No. IE6346967G

****************************************************************************
**

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 25 Jun 2004 11:46:30 -0400

Hi John,

Unfortunately there is no definitive statement for the re-use or not of
command codes by applications. I've tried to extract some relevant text from
section 1.2 in RFC3588:-

1.2:-

   "It is expected that command codes are reused; new command codes can only
be
   created by IETF Consensus..."

Presumably this applies to command codes defined by applications other than
RFC3588.

1.2.3 and 1.2.4:-

   "An implementation MAY add arbitrary non-mandatory
   AVPs (AVPs with the "M" bit not set) to any command defined in an**
   application, including vendor-specific AVPs, without needing to
   define a new accounting application.  Please refer to Section 11.1.1
   for details."

Note: ** I presume that "an" means "any".

Is there a technical reason why application X cannot re-use a command from
application Y. 

Cheers,
Chris 
Tel:    +1 613 763 8031
ESN:    393 8031 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: June 25, 2004 10:51 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]'; [email-masked];
[email-masked]'

Hi Chris, 

Thanks for your reply. 

I was thinking of the possibility of an entire command definition bein
borrowed from another application.  My interpretation is that this is not
permissible.  If a command is to be used by an application (base commands
excepted) then it must be defined by that application and use the
application-ID of that application. 

Is that your understanding too? 

Regards, 

John. 

25/06/2004 15:28 
        
        To:        "[email-masked]'" <[email-masked]>

        cc:        [email-masked], [email-masked],
"[email-masked]'" <[email-masked]> 
        Subject:        RE: [AAA-WG]: Application IDs for EAP

Hi John, 
Thanks for the reply. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: June 25, 2004 9:47 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH];

Hi Chris, 

-----Original Message----- 
From: Richards, Christopher [RICH2:2Q40:EXCH] 
Sent: June 24, 2004 11:08 AM 
To: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: Application IDs for EAP 
Exactly. 
Again. This makes sense.

---

From: <[email-masked]>
Date: Tue, 29 Jun 2004 10:05:41 +0300

Bernard Aboba wrote:

> > The rules in RFC 3588 that cause new applications to be 
> > created lead me to believe that there will eventually be 
> > a number of applications that inherit commands from earlier 
> > applications, however there doesn't seem to be a clear
> > definition of how an application should inherit commands.
> 
> RFC 3588 is very explicit on this point -- new application 
> IDs can only be used if the command is fundamentally changed, 
> such as by changing the round-trips, or adding a new mandatory AVP.  
> Otherwise the existing command definition (and application ID) is 
> used.  Doing anything else breaks Diameter interoperability.

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

Best regards,
Pasi