Subject: AW: [Mip6] mip6-aaa frameworks

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 16 Feb 2005 12:05:18 +0100

hi rafa, 

please see a comment inline:

> -----Ursprüngliche Nachricht-----
> Von: Rafa Marin Lopez [mailto:[email-masked]] 
> Gesendet: Dienstag, 15. Februar 2005 18:12
> An: Alper Yegin
> Cc: [email-masked]
> 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
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> >
> >  
> >
> 
> 
> -- 
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: +34968367645    e-mail: [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: Rafa Marin Lopez <[email-masked]>
Date: Wed, 16 Feb 2005 14:12:50 +0100

Hi Hannes ... thanks for your answer please see inline.

>you might need to rely on pana or specific eap methods to finally contact
Well, when I said agent sequence I was not following strictly RFC 2904. 
What I meant that MT contacts with AAA through some means (as you 
correctly point out pana or eap methods for example) and AAA provides 
MIP6 information to MT by using these means. But before to do that AAA 
needs to contact with Service Equipment (HA) in order to set up the 
service. After that further communication take place between MT and HA 
for example to establish IPSec tunnel.

> 
>
>
>your two models sound like push and pull model.
>
Under my understanding , framework 4 is pull model. On the other hand in 
push sequence there is no interaction with HA because of that  I said 
agent sequence.

> i think that this is yet
when you say "mechanisms" = mip6 boostrapping solutions??

On the other hand RFC 2904 defines AAA authorization framework and many 
proposal is based on AAA so I think this is a good reference model. On 
the one hand I agree with you that it could be too high level abstraction.

Regards