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

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

Jari,

See inline... 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, May 19, 2006 2:39 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: [Dime] Defining a new Application for mip6-split ?
> 
> 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.

This is unacceptable.

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

Good, cause this is unaccpetable.
 
> - New application ID.

I thought that that was what an application ID is for. No?

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

Good again.  This is unacceptable.

> However, it is far from clear to me why you would really need 
> to route the authentication differently *for the same user*.

We want to use common user credentials.  That is a big plus.
 
> 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?

See above.

Can you please explain why we are not using Diamter Application Id the
way they ought to be used?

> --Jari

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

---

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

>way they ought to be used?
The application ID is indeed designed for routing. Not
questioning that. And I also agree with you about the
undesirability of the other options. And yes, we want
common user credentials. However, what I was asking
about is why this leads to the need to use different
authentication servers.

--Jari

---

From: Santiago Zapata Hernandez <[email-masked]>
Date: Fri, 19 May 2006 23:31:34 +0200

Jari Arkko escribió:
[...snip...]
> about is why this leads to the need to use different
The idea of using different authentication servers is coming from the 
requirement of implementing a specific MIPv6 bootstrapping split 
scenario: Access Service Authorizer (ASA) <> Mobility Service Authorizer 
(MSA). (draft-ietf-mip6-bootstrapping-split-02).

I think we should use the same application ID, but routing by:
- having two different paths (Peers from different paths would not be 
interconnected).
- some proxy should change route (is it RFC compliant?), based in the 
value of a (optional) AVP.
- use different realms (changed by the HA, for example, acting as a 
proxy). I don't understand why it would not be possible (HA could change 
this realm, and boostrapping server could restore it (if it is required)).

Only my two cents,
Santiago

---

From: Jari Arkko <[email-masked]>
Date: Sun, 21 May 2006 13:37:27 +0300

Santiago Zapata Hernandez wrote:

> scenario: Access Service Authorizer (ASA) <> Mobility Service
> Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02).

I have read the draft, but I do not see how it leads to the
requirement that the same user identity needs to be routed
in different ways for different applications. It seems that
the essence of the split scenario is that the access and
mobility services are independent, e.g., acquired from
different providers with different identities. Or from
the same provider (as in when you are in your home
network), but the services are provided in an independent
fashion.

> proxy). I don't understand why it would not be possible (HA could
> change this realm, and boostrapping server could restore it (if it is
> required)).

Avi's new Application ID may be a better approach than these, because
its directly supported by by Diameter as is. (If different routing is
needed.)

--Jari

---

From: Santiago Zapata Hernandez <[email-masked]>
Date: Mon, 22 May 2006 11:03:58 +0200

Hi all,

After thinking in this issue, I'm agree about the identity would be 
different if we are in the scenario ASA <> MSA.

In the other scenario (ASA = MSA), I think a new Application ID is not 
the right solution, because we are managing the same kind of 
functionality (EAP providing authentication/authorization).
I propose to use virtual users for managing this scenarios.

BR,
Santiago

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 22 May 2006 11:55:50 +0200

hi all,

> different if we are in the scenario ASA <> MSA.

 I don't think we should assume that it is different identity. In the
 Integrated scenario, we also use IKEv2-Diameter EAP and as the HA is
 allocated by the AAA, we'll probably reuse the same identity with same
 credentials. And if we do nothing, the AAA server may "think" that it
 is performing Diameter EAP two times for network access.

> functionality (EAP providing authentication/authorization).

 EAP is used for authentication. However, Authorization and Accounting
 is different since in one case it is done for network access while in
 the other case it's for mip6 service. 

 regards,

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: Santiago Zapata Hernandez <[email-masked]>
Date: Mon, 22 May 2006 12:18:28 +0200

Hi,

Julien Bournelle escribió:

hi all,

Hi all,

I mean the same user (same credentials) but different user's identifier
(domain) because we are working (in split scenario) with different
domains. In integrated scenario the server could detect that it is
managing network access or mobility authentication by having a look to
user's identifier (another sub-domain? or maybe by classifying the
identifiers in the server side?)

My proposal is to use different users' identifiers in order to
distinguish (in the servers) between the different EAP functionalities
(Network access or Mobility).

I don't see any problem by using different identifiers but sharing the
same credentials.

My interest is in not creating a new application for each new
functionality to be deployed over Diameter-EAP.

BR,

Santiago

regards,

Julien

BR,
Santiago

Jari Arkko escribió:

--Jari

---

From: Santiago Zapata Hernandez <[email-masked]>
Date: Mon, 22 May 2006 12:54:59 +0200

Hi, (sorry for sending it again, but I sent it in HTML mode by error. 
Doing again in text mode).

BR,
Santiago

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 22 May 2006 13:02:51 +0200

Hi,

> (Network access or Mobility).

 I don't think it's clean to require use of different users'identifiers
 in order to distinguish which services is provided. For me, it looks
 like a 'hack'.

> functionality to be deployed over Diameter-EAP.

 I also don't have any interest in creating new application. But I don't
 see the issue with doing so if it seems necessary.

 regards,

 Julien

---

From: <[email-masked]>
Date: Mon, 22 May 2006 16:32:00 +0300

Julien Bournelle wrote:
> 
> I don't think it's clean to require use of different
> users'identifiers in order to distinguish which services is
> provided. For me, it looks like a 'hack'.

I fully agree -- but having separate user identifiers should not be
necessary. If, for example, an operator wants to perform different
authorizations for WiFi and WiMAX (e.g., some users can access only
WiFi but not WiMAX), that's simple to do: just check Service-Type,
NAS-Port-Type, and other relevant authorization AVPs.  There's
absolutely no need to create a new Diameter application.

If the AAA server is really strict about WiFi vs. WiMAX separation, it
can have a policy that requires the NAS-Port-Type AVP to be present
(if the request does not contain it, access is denied). Although this
in some sense make NAS-Port-Type AVP "mandatory", it's not "mandatory" 
in the sense that would require a new Diameter application.

While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are 
any significant differences from Diameter point-of-view. There's a box 
providing some service; authentication works with EAP; authorization 
AVPs indicate what exactly is being authorized. What's missing is
a document describing how the different authorization AVPs are 
used in this particular situation; sort of like RFC 3580 (IEEE 802.1X 
RADIUS Usage Guidelines), but for Diameter with IKEv2.

<snip>
> I also don't have any interest in creating new application. But I 
> don't see the issue with doing so if it seems necessary.

One important reason NOT to create new applications: proxies. Every
proxy on the path needs new code to handle the new application, while
just adding an extra AVP or new Service-Type value doesn't.

Best regards,
Pasi