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

From: "Avi Lior" <[email-masked]>
Date: Fri, 19 May 2006 14:15:52 -0400

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 <[email-masked]>
To: Gerardo Giaretta <[email-masked]>; Jari Arkko <[email-masked]>
CC: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
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:[email-masked]] 
Envoyé : vendredi 19 mai 2006 14:30
À : Jari Arkko
Cc : [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>

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

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 May 2006 21:38:48 +0300

Avi,

> 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.
>
Ah, but that is a new requirement. If you believe that you need
to route EAP authentication from a 802.11 AP differently
than from IKEv2/MIPv6, then you need one of these:

- Use different user/domain names for the users of
  the different services.

- Point to different servers from the AP and SGW (but
  this works less well if you have proxies and roaming).

- New application ID.

- Some weird form of Diameter and RADIUS source routing
  based on what type of node sent the message.

However, it is far from clear to me why you would really
need to route the authentication differently *for the same
user*. Many authentication mechanisms can also have state,
which would imply that at the end they need to end up in
the same device anyhow. Can you expand on why you need
to handle the same users in different authentication
servers?

--Jari

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 19 May 2006 14:21:22 -0400

[.. snip ..]
>   based on what type of node sent the message.
[TOLGA]Or a proxy, which would route the initial requests for sessions based
on the absence/presence of certain AVPs -in addition to applicationId-.