AW: [Mip6] mip6-aaa frameworks

[Tschofenig Hannes <[e-mail]>]

hi alper, 

thanks for your classification attempt. 

in
http://www.tschofenig.com/drafts/draft-tschofenig-enroll-bootstrapping-saml-
00.txt we also tried to create a classification. you might want to take a
look at section 3. please take a look at this figure:

    +---------------+                      +---------------+
    |               |        (A)           |               |
    | Bootstrapping |<-------------------> | Bootstrapping |
    | Client (BC)   |     Protocol or      | Agent (BA)    |
    |               |     API              |               |
    +---------------+                      +---------------+
                                                  ^
                                                  |
                                      Protocol or |(B)
                                      API         |
                                                  v
                                           +---------------+
                                           |               |
                                           | Bootstrapping |
                                           | Target (BT)   |
                                           |               |
                                           +---------------+

we think that there are three categories to consider:

   o  Which protocol is used between the BC and the BA?

   o  Which protocol is used between the BA and the BT?

   o  What information is bootstrapped?

we have also tried to classify a few proposals (as listed in the draft)
according to these questions. 
to us it seems that the most important question is which protocol is used
between BC and BA (some proposals even use two protocols).

since a number of proposals have been published that want to bootstrap
something we think that a proposal that is a bit more generic would be quite
helpful here. in
http://www.ietf.org/internet-drafts/draft-tschofenig-enroll-next-steps-00.tx
t we argue that this might be job for enroll to look at. 

finally, the protocol used for communication between the BA and the BT is in
many cases interchangeable. 

ciao
hannes


> -----Ursprüngliche Nachricht-----
> Von: Alper Yegin [mailto:[e-mail]] 
> Gesendet: Dienstag, 15. Februar 2005 07:44
> An: [e-mail]
> Betreff: [Mip6] mip6-aaa frameworks
> 
> 
> 
> 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
> 

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