Subject: AW: [Mip6] mip6-aaa frameworks

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 15 Feb 2005 13:28:42 +0100

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:[email-masked]] 
> Gesendet: Dienstag, 15. Februar 2005 07:44
> An: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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

---

From: [email-masked]
Date: Tue, 15 Feb 2005 16:09:41 +0200

Hi Julien,

> >    EAP was designed for use in network access authentication, where IP
> >    layer connectivity may not be available.  Use of EAP for other
> >    purposes, such as bulk data transport, is NOT RECOMMENDED.
> > 
> >    Since EAP does not require IP connectivity, it provides just enough
> >    support for the reliable transport of authentication protocols, and
> >    no more.
> > 
> > So that is why many people feel that using EAP would not be 
> a good idea here.
> 
> In our proposal, we use EAP for network access authentication and after
> the authentication process we piggyback Mobile IPv6 configuration
> information in the exchange. 
> 
> However, some EAP methods can't support this. 

Exactly - and EAP doesn't handle fragmentation well, which can be problematic
depending upon what you want to try to configure.
 
> As you mention EAP is not a configuration protocol but we could also add
> that AAA protocol are not configuration protocol. Thus should we avoid
> using AAA protocol for Mobile IPv6 bootstrapping ?

Well, its a complicated picture and I don't have a clear answer. For example,
PPP does some configuration, like DNS servers - however, the PPPext WG decided
that doing configuration (like DNS servers for PPPv6) is not the right thing
to do.  DHCP is a good potential solution, but what should be done if there isn't
a local DHCP server?  

I'm thinking we need to cover the general problem spaces well, not cover which
protocols to use, yet.

John

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 15 Feb 2005 12:12:29 -0800 (PST)

Hi Alper,

Thanks for providing an analysis of different proposals/framework.

I'd agree with Julien, that draft-chakrabati-mip6-bmip-00.txt
goes with Framework 4 very well for retrieving Home Agent address
and initial security association for bootstrap. 
Although the BMIP draft is not about AAA and MIPv6, it can co-exist
with having a AAA server in the foreign network and a AAA back-end server
tied to HA. So, it makes sense to add this draft to the list for
completeness.

In the next version of the draft we are going to clarify that
the BMIP draft can be used for different types of access networks
(802.1X, PANA, UAM, physical access , Local AAA) in order to gain
access to the local network.

Thanks,
-Samita

> > 
> > 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
> 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
> 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 ?
> 
> -- 
> [email-masked]
>

---

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 17 Feb 2005 11:16:36 +0100

Hi Erik,

please see below...

> 
> Gerardo Giaretta wrote:
> > Hi Erik,
> 
> > I agree that framework 4 should be standardized.
> > draft-chakrabati-mip6-bmip-00 describes a solution based on this
> > framework that allows also dynamic HA discovery. I guess this draft
> > could be a good starting point. Since in this draft the HA 
> acts as a EAP
> > pass-through authenticator, I think we should also investigate if
> > Diameter EAP application is suitable for the HA-AAA 
> communication or we
> > need another draft specifying a new Diameter application or some new
> > MIPv6-specific AVPs.
> 
> Yes, it makes sense to investigate this.
> 
> > However note that this approach is not optimized in case of 
> Integrated
> > ASP: in this scenario, the MN needs to execute two EAP 
> runs, one EAP for
> > network access authentication and the other EAP over IKEv2 
> and, as you
> > mention, the same AAA backend, the same NAI and even the 
> same EAP method
> > could be used for these two cases. For this reason, I think that we
> > should standardize also an optimized approach in which AAA 
> for network
> > access and AAA for mobility service are dependent and only one EAP
> > exchange needs to be executed. Note that here I'm not not 
> advocating any
> > of the solutions proposed so far (e.g. EAP, PANA, Diameter, 
> DHCP), I'm
> > only suggesting to have also an optimized solution that 
> might be useful
> > to mobile operators that would like to deploy MIPv6 in an 
> efficient way.
> 
> The thing that is a bit hard for me to understand is whether 
> and how a 
> MN can cope with both the separate and integrated ones.
> 
> For instance, do we see there being a MN which will perform the 
> integrated approach (if that is used by the access network) 
> and fallback 
> to use the separate approach? Or will there be completely 
> separate MNs 
> so that we don't need to worry about which to try first and 
> the possible 
> interaction between the two different schemes.
> 

I think it depends on the solution used for bootstrapping MIPv6 during
network access authentication.

However, generally I think that during network access authentication,
the AAAH or the NAS (depending on the solution via EAP or a EAP lower
layer) should communicate to the MN if MIPv6 is available (e.g. through
an AVP/TLV). If so, the MN can start bootstrapping MIPv6 using the AAA
infrastructure and the AAA exchange used for network access
authentication.

If the MN is not required to perform the network access authentication
(i.e. in a free network) or it cannot bootstrap MIPv6 in an integrated
way from its current access network location (e.g. the NAS does not
support MIPv6 extensions), the MN will not receive any hint from the
network for MIPv6 bootstrapping and will start bootstrapping MIPv6 in a
non-optimized way through IKEv2.   

--Gerardo

>     Erik

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

---

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 17 Feb 2005 14:49:37 +0100

Hi Vijay,

> 
> this classification is very confusing to me. we are dealing with
> three problems here.
> 
> 1. Access network authentication
> 2. bootstrapping
> 3. MN authenticating to the Home Agent using its NAI/FQDN.
> 
> for 3), it is simple. we need to standardize the interface between
> the HA and the AAAH ASAP. we need both RADIUS attributes and
> DIAMETER AVPs for this. this should be decoupled from the other
> two problems. draft-ietf-mip6-ikev2-ipsec-02.txt already defines
> how to run IKEv2 with EAP once the MN knows the HA's address.
>

I completely agree on that. This is the reason of
draft-giaretta-mip6-aaa-ha-goals, where we tried to identify some design
goals for such an interface. I think we should standardize this
interface at least to enable the usage of a AAA backend authentication
server in draft-ietf-mip6-ikev2-ipsec-02. Then, this interface might be
useful also for other frameworks: as suggested by
draft-giaretta-mip6-aaa-ha-goals, if you try to list the goals for each
framework, they do not differ too much and lots of them are in common.
 
> for 2), we need to standardize *a* solution. this could use/or not
> use AAA. but I dont believe we can develop a solution that will
> be valid in all deployments. for example, I think the mechanism
> used in 3GPP2 is quite okay for 3GPP2 networks.
> 
> for 1), again, I think it is specific to the deployment. but
> doesnt hurt standardizing one solution in the IETF.
> 
> ofcourse, you can develop a solution based on AAA that can
> solve all three problems. (I guess draft-le... does that). but
> the single solution might not work in all deployments. and we
> have to evaluate the complexity involved.
> 

Sure. 

However I think that the WG should decide if an optmized solution for an
Integrated ASP should be standardized other than the IKEv2(+EAP)
framework. I remember that in the boostrapping PS DT we decided to
highlight the Integrated ASP scenario because in such a scenario you can
have some optimizations. In regard to this, I think we should decide
whether a bootstrapping mechanism integrated with network access
authentication should be standardized.

Regards,
--Gerardo 

> my 2 cents.
> 
> Vijay
> 
> 
> Alper Yegin wrote:
> > This is an attempt to enumerate possible MIP6-AAA 
> frameworks, and start
> > The end2end transport between the AAA and the MN is the 
> key. Use of EAP
> > delivered from the NAS to the MN via another protocol 
> (e.g., DHCP, PANA,
> > etc.)
> > 
> > Related I-Ds:
> > 
> > between vendors is the important. Also, I was not sure on 
> the complexity
> > argument.
> >

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 17 Feb 2005 21:31:11 -0500

I'm trying to catch up with this thread. I think fwk 4 is the best
alternative for us to pursue and makes most sense since AAA is basically
used to authenticate BUs. There is also a precedence for this in 3GPP
IMS. On some level though, this will depend on the EAP method used.

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On 
 > Behalf Of
 > Alper Yegin
 > Sent: Tuesday, February 15, 2005 1:44 AM
 > To: [email-masked]
 > Subject: [Mip6] mip6-aaa frameworks
 > 
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================