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

From: "Avi Lior" <[email-masked]>
Date: Mon, 22 May 2006 11:36:42 -0400

Hi Pasi,

Please see inline.... 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, May 22, 2006 9:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Defining a new Application for mip6-split ?
> 
> 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.

Well this is what is being debated.  So it seems to me that if I have an
server that is doing EAP based authentication as defined in RFC 4072 but
now I need to have some special processing for WiMAX or WiFi and because
of that I need to understand the meaning of Service-Type or
NAS-Port-type then I think I need a new Diameter Application to make
sure I can route to the Implementation that supports this functionality.
Note it can be on the same machine.

If its not imporant that I Hit the server with the correct code, that
is, that I don't need to hit the implementation that understands
NAS-Port-type = WiMAX or WiFi, the we don't need an new Application Id.

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

But if the above is true you have to make sure you route to the correct
implementation.  So how do you do that? I say with an Application ID.

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

It is true of MIPv6 split scenario you may not need to differentiate
because some people think that for Split MIPv6 scenario it is plain EAP
that you are doing. So 4072 the argument is that you don't need to do
any work at all.

> <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
> 
> _______________________________________________
> 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: <[email-masked]>
Date: Tue, 23 May 2006 09:40:19 +0300

Avi Lior wrote:

> Well this is what is being debated.  So it seems to me that if I
> have an server that is doing EAP based authentication as defined in
> RFC 4072 but now I need to have some special processing for WiMAX or
> WiFi and because of that I need to understand the meaning of
> Service-Type or NAS-Port-type then I think I need a new Diameter
> Application to make sure I can route to the Implementation that
> supports this functionality.  Note it can be on the same machine.

I think in most cases this "special processing" can (and should) be
thought of as a part of AAA server's policy. Or in other words: I
don't think the intention of NASREQ was that every time someone
defines a new value for Service-Type or NAS-Port-Type we would need 
a new Diameter application....

<snip>
> But if the above is true you have to make sure you route to the
> correct implementation.  So how do you do that? I say with an
> Application ID.

At least the RADIUS proxy implementations I know of can route 
based on any attribute...

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 23 May 2006 09:54:28 +0300

Having read through the thread, I tend to agree with Pasi on this;
if we use a new Application ID as a way to handle routing for new
service types or other AVPs, we will have a huge mess of applications,
and I don't see how this would aid interoperability.

John

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 23 May, 2006 09:40
>To: [email-masked]
>> Well this is what is being debated.  So it seems to me that 
>if I have 
>> an server that is doing EAP based authentication as defined in RFC 
>> 4072 but now I need to have some special processing for 
>WiMAX or WiFi 
>> and because of that I need to understand the meaning of Service-Type 
>> or NAS-Port-type then I think I need a new Diameter Application to 
>> make sure I can route to the Implementation that supports this 
>> functionality.  Note it can be on the same machine.
>
>I think in most cases this "special processing" can (and 
>should) be thought of as a part of AAA server's policy. Or in 
>other words: I don't think the intention of NASREQ was that 
>every time someone defines a new value for Service-Type or 
>NAS-Port-Type we would need a new Diameter application....
>
><snip>
>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"

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 23 May 2006 12:58:47 +0200

Hi pasi,

> a new Diameter application....

 one could advocate that in the NASREQ case, we are still dealing with
 network access. And Service-Type or NAS-Port-TYpe help the AAA server
 to know what kind of access it is. Here it is not network access
 service, it is Mobile IPv6 service.

> based on any attribute...

 I think avi is talking about routing in the Diameter server between the
 different applications (SIP/EAP/CC...) not in the network. But I may be
 wrong :)

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: <[email-masked]>
Date: Tue, 23 May 2006 15:00:07 +0300

> service, it is Mobile IPv6 service.

I don't think so; Service-Type and other authorization AVPs help the
AAA server to know what is the service being authorized. Given that
NASREQ and Diameter are already suitable for a wide range of services
(from dial-up PPP, fax, IAPP, normal IKEv2-based remote access VPNs to
administrative web interfaces, and so on), I don't think there's
anything so special in Mobile IPv6 that would set it apart from the
other Service-Types...

> I think avi is talking about routing in the Diameter server between 
> the different applications (SIP/EAP/CC...) not in the network. 
> But I may be  wrong :)

Exactly how a particular AAA server implementation is divided into
modules, components, libraries, DLLs, and so on is not traditionally
standardized in IETF...

Best regards,
Pasi

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 23 May 2006 15:24:29 +0200

Hi pasi,

> modules, components, libraries, DLLs, and so on is not traditionally

 yep I know that. I was just saying that the App-Id field may be used by
 the Base Protocol to select the right Application in a Diameter server.

 regards,

 Julien