AW: [Mip6] mip6-aaa frameworks

[Tschofenig Hannes <[e-mail]>]

hi rafa, 

please see a comment inline:

> -----Ursprüngliche Nachricht-----
> Von: Rafa Marin Lopez [mailto:[e-mail]] 
> Gesendet: Dienstag, 15. Februar 2005 18:12
> An: Alper Yegin
> Cc: [e-mail]
> Betreff: Re: [Mip6] mip6-aaa frameworks
> 
> 
> Hi Alper,all
> 
> I think this classification could be summarized in two models (agent 
> sequence and pull sequence) in this sense:
> 
> Taking into account that HA would be service equipment for 
> Mobile IPv6 
> service then:
> 
> if people want pull sequence then they need to know HA address and 
> execute some kind of protocol between MT and NAS(HA) and HA 
> contacts AAA 
> server (framework 4)
> 
> MT------HA------AAA
> 
> if people want (framework 1, framework 2, framework 3) to 
> deliver MIP6 
> configuration parameters with network access, agent sequence 
> could fit 
> in the majority of these cases
> 
> MT-----AAA-----HA

i think that this sequence is not quite right since the mt cannot directly
interact with the aaa protocol, in most cases. 
you might need to rely on pana or specific eap methods to finally contact
the aaa server. 


your two models sound like push and pull model. i think that this is yet
another design aspect that is mostly unrelated to the solutions. since most
mechanisms would support both. 

> 
> 
> note1 : you may want to include 
> draft-ohba-mip6-boot-arch-dhcp-00.txt in 
> framework 2.
> note2 : draft-bournelle-pana-mip6-00 can match with sequences 
> shown by 
> draft-ohba-aaaarch-authorization-delegation-00

ciao
\hannes
> 
> Regards.
> 
> Alper Yegin wrote:
> 
> >This is an attempt to enumerate possible MIP6-AAA 
> frameworks, and start
> >discussions on for which one(s) IETF shall pursue standardization. 
> >
> >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.
> >
> >
> >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.
> >
> >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.
> >
> >
> >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
> >
> >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 am sure I have missed some references, please let us know 
> which ones.
> >
> >Alper
> >
> >
> >
> >
> >_______________________________________________
> >Mip6 mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> >
> >  
> >
> 
> 
> -- 
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: [phone]    e-mail: [e-mail]
> ------------------------------------------------------
> 
> 
> _______________________________________________
> Mip6 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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