Re: [Mip6] mip6-aaa frameworks

[Julien Bournelle <[e-mail]>]

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.


-- 
[e-mail]

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