Subject: AW: [Mip6] mip6-aaa frameworks

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 16 Feb 2005 13:53:52 +0100

hi julien, 

i think that framework 1 and 2 do not split the design space particularly
well. draft-chowdhury-mip6-bootstrap-radius-00 and
draft-le-aaa-mipv6-requirements-03.txt have a few things in common. 

i personally would like to see a solution that does not depend on protocols
that do not necessary have to deal with the bootstrapping procedure itself. 

for example, what protocols do you use to provide the bootstrapping
parameters to the end host and how many administrative domains do they
traverse. when you run a bootstrapping procedure for mip6 (or for other
protocols as well) then why do you need to depend on some infrastructure in
the visited network (particularly when want something from the home
network)? 

ciao
hannes
  
> -----Ursprüngliche Nachricht-----
> Von: Julien Bournelle [mailto:[email-masked]] 
> Gesendet: Mittwoch, 16. Februar 2005 13:35
> An: Alper Yegin
> Cc: [email-masked]
> Betreff: Re: [Mip6] mip6-aaa frameworks
> 
> 
> Hi all,
> 
>  more comments concerning framework 1 and 2 inline:
> 
> On Mon, Feb 14, 2005 at 10:44:19PM -0800, Alper Yegin wrote:
> > 
> > Framework 1:
> > ------------
> > Using network access AAA to deliver MIP6 configuration 
> parameters from
> > the AAA server to the MN. 
> > 
> > MIP6 configuration is directly delivered from the AAA 
> server to the MN
> > during network access AAA, in-band with the authentication (e.g.,
> > transported by EAP or EAP methods).
> > 
> > Related I-Ds:
> > 
> > draft-giaretta-mip6-authorization-eap-01
> > draft-le-aaa-mipv6-requirements-03
> > draft-ohnishi-mip6-aaa-problem-statement-00
> > 
> > Discussion:
> > 
> > The end2end transport between the AAA and the MN is the 
> key. Use of EAP
> > for this somewhat network access unrelated "configuration" is not
> > recommended as far as I understand. One can design his own 
> EAP method to
> > do that, yet that would have limited applicability.
> 
> Concerning this framework, it appears that we have 2 possibilities:
> 
>  - define a new EAP method, the EAP server will be in charge of
>    selecting the right method based on NAI for example. The problem is
>    that we could have a user having the mip6 stack but who didn't want
>    to use it. With this approach, it appears that we always configure
>    the mip6 service.
> 
>  - use EAP-TLVs (draft-giaretta-mip6-authorization), the 
> problem here is
>    that EAP hasn't been designed for configuration.
> 
> > Framework 2:
> > ------------
> > Using network access AAA to deliver MIP6 configuration 
> parameters from
> > the AAA server to the NAS. It is assumed that parameters will be
> > delivered from the NAS to the MN via another protocol 
> (e.g., DHCP, PANA,
> > etc.)
> > 
> > Related I-Ds:
> > 
> > draft-chowdhury-mip6-bootstrap-radius-00
> > draft-jang-dhc-haopt-00
> > 
> > Discussion:
> > 
> > This is similar to NAS learning the IP address for the 
> connected host
> > via RADIUS, and delivering it to the host via DHCP.
> > 
> > James had a comment regarding not having to support intra-operator
> > interoperability. I think regardless of the deployment, 
> interoperability
> > between vendors is the important. Also, I was not sure on 
> the complexity
> > argument.
> > 
> > 3GPP2 has already chosen this scheme. Some other SDO(s) may 
> follow the
> > suit.
> 
> Concerning this framework, I also see 2 possibilities:
> 
>  - add mip6 functionalities to exisiting applications: 
> basically add some
>    AVPs and mechanisms to RADIUS EAP/ Diameter EAP (if EAP is in use).
>    This also imply some modifications to 802.1X/PANA/...
> 
>  - define a specific AAA application for mip6.  In this case, 
> we'll have
>    at least two AAA applications used in the access network. 
> The reason
>    is that I guess we won't have only mip6 terminal. Thus the
>    authentication agent will need a way to select the right 
> application.
>   The protocol used between the MN and the authentication agent will
>   also need some modifications to handle this.
> 
> 
> -- 
> [email-masked]
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 16 Feb 2005 16:34:29 +0100

hi hannes,

> draft-le-aaa-mipv6-requirements-03.txt have a few things in common. 

they split the "AAA" approach. 

> the visited network (particularly when want something from the home

the idea is not to depend on some infrastructure. The "AAA" idea is that
we could have this infrastructure available and that in this case it can
be interesting to couple it with the bootstrapping procedure for
authorization and accounting purpose. 

however, we can't assume that we always have a AAA system. In this case,
we need framework 4 (or something else). Does this imply that we should reject
framwork 1-2 ?

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 17 Feb 2005 09:18:45 +0900

Hi Julien.
Please see my comments at the end.

----- Original Message ----- 
From: "Julien Bournelle" <[email-masked]>
To: "Tschofenig Hannes" <[email-masked]>
Cc: "Alper Yegin" <[email-masked]>; "'Julien Bournelle'" <[email-masked]>; <[email-masked]>
Sent: Thursday, February 17, 2005 12:34 AM
Subject: Re: [Mip6] mip6-aaa frameworks

> we need framework 4 (or something else). Does this imply that we should reject

As i know, even framework 4, there is a AAA home server in the MN's home network.
I think in this case, there is no AAA server in the local--visited domain of the MN.
So, no ASP and only with MSP.
I personally want a AAA home server infrastructure which can support MIP6 bootdstrapping
tranparently whether the ASP or IASP is deployed.

I don't think that need of framework 4 can not reject framework 1-2.

Junghoon.

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 17 Feb 2005 12:37:47 +0100

Hi,

 comments inline,

> tranparently whether the ASP or IASP is deployed.

I just said that we can't always assume that it exists a AAA network
access system in the visited network thus, in my opinion, we really need
a solution based on framework 4. 

I'm just wondering if, taking into account that solution 4 is needed, we
can also standardize a solution based on framework 1 or 2.

This does not mean that I'm in favor of solution 4.