Re: [Mip6] mip6-aaa frameworks

[Julien Bournelle <[e-mail]>]

hi alper, all,

 thanks for this enumeration. I've just added some references to your
 proposed framework and some comments.

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

I'd like to understand why this is not recommended. Because it has not
been designed for this purpose ?

> 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

we can add:
draft-jee-mip6-bootstrapping-pana-00.txt

(PANA between MN and PAA and a specific Diameter Mobile IPv6 application
between PAA and AAA)

> 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.
> 
> Framework 3:
> ------------
> Piggybacking MIP6 signaling (BU) with network access AAA. In-band with
> the network access authentication execution, the MN delivers
> (piggybacks) a BU to the AAA server. The AAA server may have to relay
> the BU to the HA (unless collocated).  
> 
> Related I-D:
> 
> draft-le-aaa-mipv6-requirements-03
> 
> Discussion:
> 
> While the performance benefits are clear, limited applicability (not
> always the network access and mobility services are bundled) and
> complexity are concerning.

I'm not sure that this is a particular framework since the BU is carried
in the AAA protocol. This piggybacking can be done with Framewrok 1 and
2.

> 
> 
> Framework 4:
> ------------
> A backend AAA protocol is executed between the HA and the AAA server in
> response to the MIP6 signaling between the MN and the HA. Similar to the
> use of AAA protocols with MIPv4 co-located care-of address case.
> 
> Related I-Ds:
> 
> draft-giaretta-mip6-aaa-ha-goals-00.txt
> draft-yegin-mip6-aaa-fwk-00.txt

I would add:
draft-chakrabati-mip6-bmip-00.txt
(DNS to discover HA + IKEv2 and AAA-HA)

draft-tschofenig-mip6-bootstrapping-pana
(needs to relax PANA on the one IP hop between PaC and PAA) assumption

> Discussion:
> This one appears to be the most needed framework. It is assumed that MN
> already knows the HA address. 
> 
> 
> Are there other frameworks to add?

I also wrote a proposition draft-bournelle-pana-mip6-00. This
proposition rely on PANA. The PAA is in charge of allocating the HA and
of providing necessary information to HA and MN. The problem with this
approach is that the HA allocation is only in the visited domain.
However, the idea is that the AAA server explicitely authorize the service but
delegate configuration process to an agent.

Do you think that we can make a framework with this ?

-- 
[e-mail]

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