Subject: RE: [Dime] Defining a new Application for mip6-split ?

From: "Avi Lior" <[email-masked]>
Date: Fri, 19 May 2006 21:17:40 -0400

Hi Jari,

I now want to respond to this email. Please see inline...

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, May 19, 2006 4:18 AM
> To: Avi Lior
> Cc: Yoshihiro Ohba; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [Dime] Defining a new Application for mip6-split ?
> 
> I would prefer using the existing application, and adding 
> optional AVPs to carry information related to the IKEv2 (and 
> possibly MIPv6) service, and possibly some additional values 
> for the NAS-Port-Type field.

BTW in the context of the original question raised, the attribute(s)
will not be optional. Here is the snippet:

>>  In our case, the AAA server must perform AAA functionality for the  
>> Mobile IPv6 service. The AAA server must know that it has to  
>> authorize the mip6 service and the accounting (ASR/ASA) is also for
>>  mip6 and not for network access. 

If the Diameter message comes from the HA then the HA MUST include the
NAS-Port-type attribute. So the command ABNF is being changed. Also the
behavior is being changed of the Server.  It MUST recognize the (new)
value of the NAS-Port-Type.

> One of the reasons why an existing application would be 
> preferred is that then a AAA server that does not care about 
> the type of service can be used without changes. Yet servers 
> that do care can look at the AVPs and make more detailed 
> authorization decisions.

Yes so if the behavior is optional then the attributes are optional then
may be okay. But that is not the case here.

> RFC 3588 states that  "Creation of a new application should 
> be viewed as a last resort." and that "In order to justify 
> allocation of a new application identifier, Diameter 
> applications MUST define one Command Code, or add new 
> mandatory AVPs to the ABNF." 

BTW that should be cleaned up to say "...Diameter applications MUST
define at least one new Command Code, or add new mandatory AVPs to the
ABNF.

We should clean the last ABNSF part to read:
"or add new mandatory AVP(s) that may be included in any command used by
the application."

> Note that mandatory AVPs can be 
> viewed in different ways, and that we should not be too 
> strict about them.
> For instance, Framed-Protocol is an optional AVP in RFCs 4005 
> and 4072. Yet, you could argue that if you are doing PPP then 
> you need to use this attribute and set it to PPP. But that 
> didn't make the attribute mandatory.

Mandatory does not mean required in the Command.  It means that it must
be understood by the receiver.  We need to clarify that.

> Do we have a similar situation for the IKEv2/MIPv6 attributes 
> and values? They are not necessary from the NASREQ/EAP 
> perspective, but in the specific context you need to use the 
> attributes. In my mind, this does not make the attributes 
> mandatory from a Diameter application point of view. 

This is correct and is my understanding of 3588.  But  I think 3588 got
it wrong.

As I pointed out (in an email to Yoshi) for the MIPv6 Application (or HA
application) we have to change the ABNF of the command.  We have to make
the NAS-Port-Type mandatory in the DEA answer.  So under what context do
we make that.

> If we 
> start creating new applications for every different 
> situation, we'll have lots of applications and 
> interoperability problems. Its better to add new optional 
> AVPs and describe in text when they should be used. The only 
> exception that I see is security related AVPs that must be 
> understood by the other side or else the session should be terminated.

I don't think that every situation requires a new application. I see
other exceptions.  In essence if the application has new "mandatory"
behavior changed then we need to use a different application Id.  As a
minimum we need to make sure that we can route to the correct
application -- the application that correctly acts on the command.

We only have Application ID to do this with. While I agree that we could
have lots of application ids fortunately it's a 32 bit unsigned int.

 Optional behavior is one case.  But when the behavior difference is
mandatory then we do need a new Application ID.

If folks are concerned about too many application ids, perhaps Diameter
should have used version numbers.  

> See also
> http://www.arkko.com/publications/draft-arkko-radext-multi-ser
vice-decisions-02.txt
> for related discussion about Service-Type, NAS-Port-Type, and so on.
> 
> --Jari
> 
> 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 22 May 2006 11:14:31 -0400

I don't have a strong opinion on the mip6 discussion but it seems to me 
that in general the bar for defining new application IDs has been set 
too high or that the 3588 recommendation cited by Jari has, in some 
cases, been taken to an extreme that's not really helpful.

Take the 3GPP's Gq spec as an example. It "reuses" the AAR/AAA NASREQ 
command but completely redefines the messages and does so without 
reusing *any* of the NASREQ AVPs and without reusing the semantics of 
the command (or at least only in a very loose sense). The Gq spec also 
defines its own app ID for use in the Auth-Application-Id AVP. AFAICT 
the only thing actually reused from the NASREQ version of the command is 
the app ID used in the message header (0) and the message names used in 
the specification. IMHO it would be much preferable if they just dropped 
the pretense and properly defined a new application and stuck the Gq app 
ID in the message header also.

Anders