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

From: "Christopher Richards" <[email-masked]>
Date: Mon, 28 Jun 2004 09:08:06 -0400

Hi John,
 
That's a good description and example of the issue. I've inlined some
comments below.

Cheers,
Chris 

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

Hi Chris, 

That's the scenario I was trying to work out.  Imagine a hypothetical
application x with three commands.  Those commands would use an application
ID - let's call that x too. 

Someone wants to add a new command so, as clearly delineated by RFC 3588,
that leads to a new application, y.  This application is effectively
application x plus one new command.  The new command definitely would use
it's own application ID.  Again, for simplicity, let's use the value y. 

The big question I think you have all been discussing is what application ID
is used within application y for the commands inherited.  My first thoughts
were that the original commands should use an application ID of x.  Your
proposal, as I understand it, is that they should include an application ID
of y. 

[[Chris Richards] ] Yes. And to put it the other way: How would application
x deal with messages and AVPs generated and destined for application y?
Application x probably does not know about application y. The peer cannot
make any assumptions about how the applications are implemented on the
destination device.

What needs to be clear is how the implementor of application y should cope
with commands from application x.  An initial assumption is that if the
capabilities exchange is completed only for application y, then the
recipient shouldn't acept commands with an application ID of x. 

On the otherhand, if application y doesn't define those commands an
application y client or server wouldn't necessarily implement support for
them. 

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.  Should there be a
new RFC to clarify that? 

Regards, 

John. 

	"Christopher Richards" <[email-masked]> 
Sent by: [email-masked] 

25/06/2004 16:46 

        To:        "[email-masked]'" <[email-masked]>

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

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]>
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]' 
Subject: RE: [AAA-WG]: Application IDs for EAP 

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. 

"Christopher Richards" <[email-masked]> 
Sent by: [email-masked] 
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. 
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]>
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 

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. 
>   Application-ID is four octets and is used to identify to which 
>   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. 

>   The application-id in the header MUST be the same as what is 
>   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]>
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: 
> 
> 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. 
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 
****************************************************************************
** 
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: Bernard Aboba <[email-masked]>
Date: Mon, 28 Jun 2004 08:57:05 -0700 (PDT)

> proposal, as I understand it, is that they should include an application ID

RFC 3588 is fairly clear on what is required.  Changing the application ID
of existing commands and AVPs to "y" from "x" unecessarily will break
interoperability with existing implementations of those commands.

> An initial assumption is that if the capabilities exchange is completed
> only for application y, then the recipient shouldn't acept commands with
> an application ID of x.

A Diameter peer should advertise *all* applications that it supports.  So
if commands with application X and commands with application Y are being
used, then *both* should be advertised.

> application y client or server wouldn't necessarily implement support for

That's also true -- a Diameter application document needs to explicitly
state what commands MUST, SHOULD or MAY be implemented for that
application.  It also needs to state what application-IDs must be used for
those commands.

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