AW: [Mip6] mip6-aaa frameworks

Tschofenig Hannes <hannes.tschofenig@siemens.com> Wed, 16 February 2005 12:58 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05271 for <mip6-web-archive@ietf.org>; Wed, 16 Feb 2005 07:58:46 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1P6j-00035r-DX for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 08:20:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Ok4-0005X5-Vh; Wed, 16 Feb 2005 07:57:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Oi6-00056J-Ut for mip6@megatron.ietf.org; Wed, 16 Feb 2005 07:55:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04987 for <mip6@ietf.org>; Wed, 16 Feb 2005 07:55:17 -0500 (EST)
Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1P3M-00030n-Ec for mip6@ietf.org; Wed, 16 Feb 2005 08:17:16 -0500
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j1GCtGFF011764; Wed, 16 Feb 2005 13:55:16 +0100
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1GCtFiQ010357; Wed, 16 Feb 2005 13:55:15 +0100
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRJQ7H>; Wed, 16 Feb 2005 13:55:15 +0100
Message-ID: <D2E490BD3F24C24598C4605E40024D150A7951@mchp9gma.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: 'Julien Bournelle' <julien.bournelle@int-evry.fr>, Alper Yegin <alper.yegin@samsung.com>
Subject: AW: [Mip6] mip6-aaa frameworks
Date: Wed, 16 Feb 2005 13:53:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Content-Transfer-Encoding: quoted-printable
Cc: mip6@ietf.org
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Content-Transfer-Encoding: quoted-printable

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:julien.bournelle@int-evry.fr] 
> Gesendet: Mittwoch, 16. Februar 2005 13:35
> An: Alper Yegin
> Cc: mip6@ietf.org
> 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.
> 
> 
> -- 
> julien.bournelle@int-evry.fr
> 
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
> 

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6