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

["Avi Lior" <avi at bridgewatersystems.com>]

Title: Re: [Dime] Defining a new Application for mip6-split ?

It may not be that simple.

If I have two EAP based application in my network, one that is handling pure EAP application, the other is extended to handle the new behavior then I need a way to route the (same) command correctly.

How will I achieve that?


--------------------------
Avi Lior  Bridgewater Systems
cell +1 613 796-4183
work +1 613 591-9104 x 6417



-----Original Message-----
From: MORAND Lionel RD-CORE-ISS <lionel.morand at francetelecom.com>
To: Gerardo Giaretta <gerardo.giaretta at gmail.com>; Jari Arkko <jari.arkko at piuha.net>
CC: Pasi.Eronen at nokia.com <Pasi.Eronen at nokia.com>; hannes.tschofenig at gmx.net <hannes.tschofenig at gmx.net>; dime at ietf.org <dime at ietf.org>
Sent: Fri May 19 12:33:27 2006
Subject: RE: [Dime] Defining a new Application for mip6-split ?

I agree with Jari also ;)

Year after year, we have the same discussion on this specific topic. And, as I said in previous discussions, as soon as the use of optional AVPs at the Diameter protocol level is  enough to fulfil service requirements, even if those optional AVPs are required at the service level - I said "service" and not "application", we should avoid resorting to systematically allocate a new application id while we reuse the same functionalities of an existing diameter application.

Lionel

-----Message d'origine-----
De : Gerardo Giaretta [mailto:gerardo.giaretta at gmail.com]
Envoyà : vendredi 19 mai 2006 14:30
à : Jari Arkko
Cc : dime at ietf.org; hannes.tschofenig at gmx.net; Pasi.Eronen at nokia.com
Objet : Re: [Dime] Defining a new Application for mip6-split ?

I agree with Jari.

The most important thing we need for MIPv6 is that the AAA server understands that the authentication/authorization request is performed through Diameter EAP application but it is related to the mobility service and not to network access service. This is a clear requirement for an operator. But the presence of some optional AVPs may be sufficient to fulfill this requirement, imo.

--Gerardo

On 5/19/06, Jari Arkko <jari.arkko at piuha.net> wrote:
> 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.
>
> 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.
>
> 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." 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.
> 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. 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.
>
> See also
> http://www.arkko.com/publications/draft-arkko-radext-multi-service-dec
> isions-02.txt for related discussion about Service-Type,
> NAS-Port-Type, and so on.
>
> --Jari
>
>
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime