Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt

From: "DENG, HUI -HCHIBJ" <[email-masked]>
Date: Thu, 10 Feb 2005 14:27:55 +0800

I support this interface.

But I would like to mention that in scenary 1 of this draft.

                  MN                AAAH            HA

                   <---------- IKEv2(EAP) -------->

                                             <--------->
                                         AAA-HA protocol

       Figure 2 - Dynamic MIPv6 bootstrapping through IKEv2 and EAP

should also consider the one draft:
http://www.ietf.org/internet-drafts/draft-deng-mip6-bootstrap-bcf-00.txt

That is to say, there are one possibility for
           AAAH            HA
                  <--------->
            AAA-HA protocol

change to two stages:
Stage 1:
           AAAH          BCF
                <---------->
           AAA-BCF protocol
Stage 2:
                 BCF
                 /  |  \
                /   |   \
         HA ... HA ... HA
         BCF-HA Protocol

In this possibility, BCF (Bootstrap Control Function) can act as the proxy of
the HA, there are mightbe one BCF for each HA, also one BCF for multiple HAs.

-Hui

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

---

From: John Loughney <[email-masked]>
Date: Thu, 10 Feb 2005 13:23:24 +0200 (EET)

Hi all,

I also think that covering the possible scenarios are important.  I
don't think that means that a solutions need to cover all of these
scenarios.  It might be that a specific scenario may not actually
require any specific solution. 

There have been some discussions about different deployment models on
the list earlier - I'm not sure the working group needs to develop a
solution that covers all of them, as some of these models are fairly
specific - I think we should have WG consensus about which scenario(s)
we want to work on.

John

--- Original Message ---
From: ext Yoshihiro Ohba <[email-masked]>
To: Alper Yegin <[email-masked]>
CC: 'Gerardo Giaretta' <[email-masked]>, [email-masked], [email-masked]
Date: Thu Feb 10  00:33:25 EET 2005
Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt

I agree with Alper that we must identify all possible bootstrapping
frameworks.  I'd like to mention that
draft-ohba-mip6-boot-arch-dhcp-00.txt also contains a framework for
Scenario 2 of draft-giaretta-mip6-aaa-ha-goals-00.txt, and the
framework should be identified.

Regards,

Yoshihiro Ohba

On Wed, Feb 09, 2005 at 10:59:57AM -0800, Alper Yegin wrote:
> Hi Gerardo,
> 
> > > > >Before we get to listing the requirements, we (MIP6 WG) should
> > > identify
> > > > >different frameworks where "mip6" gets mixed up with
> > > "aaa". Following
> > > > >that, we can discuss which one of the frameworks we'd like to
> > > > >standardize in IETF, and drive the requirements based on that.
> > > >
> > > > Okay. I think it is possible to have a discussion of the
> frameworks
> > > > based on your I-D on the ML in a constrained timeframe and
> > > proceed to
> > > > the next step of identifying what are the requirements for
> AAA-MIP6
> > > > network elements interactions.
> > >
> > > The implications of some of the frameworks are not confined
> > > to a AAA-HA
> > > interface. For example, delivery of MIP6 information to NAS calls
> for
> > > new attributes for AAA server-to-NAS communication (as opposed to
> AAA
> > > server to HA, which requires a new AAA application). We shall
> capture
> > > those in the WG document as well.
> > >
> > 
> > I agree that some frameworks imply requirements also on AAAH-NAS
> > communication. In draft-giaretta-mip6-aaa-ha-goals-00 we list only the
> > requirements on AAA-HA interface because the goals for such an
> interface
> > seem to be independent from the protocol used between MN, NAS and AAA
> > server (e.g. EAP, PANA, RADIUS/Diameter).
> > 
> > I think the WG should decide if we need a draft that lists all
> AAA-MIP6
> > requirements or for the moment only a draft listing the goals for the
> > design of an interface between AAA and HA.
> 
> I think the MIP6 WG should discuss all "mip6" and "aaa" work needed in
> IETF. Once we agree on the work, documentation strategy can be worked
> out.
> 
> Framework 2 should be standardized at IETF. I know at least one SDO is
> using that framework in a vendor-specific way. I anticipate more users
> (SDOs, deployments).
> 
> > If the WG draft has to cover all AAA-MIP6 requirements, before listing
> > the goals we surely need to decide which framework(s) we want to
> > address. Otherwise, if we accept to limit the scope of the WG draft to
> > the AAA-HA interface, it might be possible to identify the design
> goals
> > for this interface in a way to address any possible framework.
> 
> I think we must identify all possible frameworks, but not necessarily
> standardize all of them at IETF. 
> 
> Alper
> 
> 
> > 
> > 
> > Regards,
> > --Gerardo
> > 
> > > > >
> > > > >This was the motivation behind writing
> > > draft-yegin-mip6-aaa-fwk-00.txt.
> > > > >4 different frameworks are mentioned in that I-D, with one being
> > > > >detailed.
> > > >
> > > > The I-D can be a good source for the discussion itself and
> > > then we can
> > > > simply choose to incorporate the one that we agree on as
> > > the basis for
> > > > the goals I-D.
> > > >
> > > > >
> > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend
> we
> > > > >capture the framework discussions. For that, my
> > > recommendation is to
> > > > >produce a WG I-D combining both individual I-Ds.
> > > >
> > > > Not sure if we really need to do a merge of the I-Ds here.
> > > I think we
> > > > can have a discussion on the list about the frameworks that you
> > > > propose in your I-D and then based on consensus we can
> > > incorporate the
> > > > one that we agree on in the giaretta draft as a section.
> > >
> > > I'm not suggesting a full merge or anything, but to make sure
> > > we address
> > > various issues and angles thoroughly. If someone wants to rewrite
> > > things, I don't mind :-)
> > >
> > > > >Besides, mip6-aaa-fwk has detailed discussions on call
> > > flow (good for
> > > > >finding out the exact requirements), EAP considerations,
> > > why we need
> > > a
> > > > >new AAA application, and relation to mip6 bootstrapping --
> > > which are
> > > > >worth capturing in the WG I-D.
> > > >
> > > > Some of this can go in an appendix of the giaretta draft.
> > >
> > > I think some of these discussions are for the main text. For
> example,
> > > the relation to MIP6 bootstrapping must be spelled out. Some parts
> of
> > > the mip6-aaa-ha draft gives the impression that such an interface
> > > handles the MIP6 bootstrapping single-handedly. That's not always
> the
> > > case. Also, I think we need some words on why we need a new AAA
> > > application when we already have MIP4 and EAP applications.
> > >
> > > For framework classification, here are my slides:
> > > http://yegin.org/IETF/MIP6-AAA-fwk.ppt. This is what I missed
> > > to present
> > > at IETF 61.
> > >
> > >
> > > Alper
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > >
> > > > >Alper
> > > > >
> > > >
> > > > -Basavaraj
> > >
> > >
> > >
> > 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: [email-masked]
Date: Wed, 16 Feb 2005 06:08:43 +0200

Hi James,

> OK, then how about "inter-administrative domain roaming"? If two operators
> merge and originally used some kind of inter-operator solution because they
> are two different administrative domains, then they could continue to use
> that.

Thanks for the clarification, I just wanted to check on whether this was supported
or not in your scenario.  It seems it is; I'm otherwise not so hung-up on terminalogy.

thanks,
John

---

From: [email-masked]
Date: Wed, 16 Feb 2005 06:52:29 +0200

Hi James,

> I think the issue is administrative boundaries from the network operator
> perspective. If an operator manages multiple kinds of networks separated by
> administrative boundaries, then these are, effectively, separate
> administrative domains, and the boundaries should be respected. It is
> basically a question of managability. Issues such as exposure of detailed
> topology information (not only for security purposes, but also for purposes
> of effective routing information and address management) need to be kept
> within an administrative boundary inside which the network operator can
> effectively manage. That's why there are two types of routing information
> distribution protocols, one for inside an administrative domain and one for
> outside. Exposing detailed address and topology information outside an
> administrative domain through protocols that were originally designed for
> configuring hosts within an administrative domain is not such a good idea in
> my opinion, because it adds more complexity to the management task.
> Naturally, others have different opinions.

I basically agree; so let's drop the inter/intra-operator discussions and
speak about administrative boundries.  I was slightly confuses after reading
your original mail, but I think if we just discuss from administrative
boundries perspective, it would be clearer.

John

---

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

Hi James, Yoshi,

please see a comment at the end...

> 
> Yoshi,
> 
> > This seems to be a general problem that is common to any roaming
> > scenario, not specific to MIP6 bootstrapping scenario.  The IETF
> > already defines a similar framework for Mobile IPv4 
> bootstrapping with
> > having a MN-FA-AAA interface and I don't see a problem in 
> general (in
> > terms of complexity for roaming support) with replacing FA with
> > NAS/DHCP in the case of Mobile IPv6 bootstrapping.
> >
> 
> Yes, but configuration is a different problem from network 
> access/mobility
> auth/authz.. The information distributed by any network 
> access/mobility
> roaming consists of a yes/no indication about whether someone 
> can enter the
> network, together with possibly a master key associated with that
> permission.
> 
> What your draft is talking about is distributing detailed 
> configuration
> about the topology and services in the home administrative 
> domain. There is
> much more that can go wrong in that case.
> 
> 
> > > The other alternative is that the AAA-H itself 
> communicates with the
> AAA-F
> > > to obtain the local HA address, then sends it back in the 
> EAP reply. In
> that
> > > case, there is an additional round trip on the back end, 
> but, again
> there
> > > would be no need for the IKEv2 transaction if the EAP is used to
> configure
> > > the IPsec SA.
> >
> > But both of these would need to push IKE credentials of the MN from
> > the AAA server in the home domain to the local HA in the visited
> > domain, to avoid the second EAP run.  On the other hand, if we allow
> > the delivery of IKE credentials to the local HA across 
> administrative
> > domains, I think we can certainly allow the framework of 
> carrying a HA
> > address to the local NAS/DHCP across administrative domains.
> >
> 
> The difference is that the delivery is end to end, between 
> the MN and the
> AAA-H with EAP. So the security can be end to end, between 
> the home network
> operator and the client. If the NAS is in the middle, as in 
> your proposal,
> there is a weak point where compromise of security, or 
> network management
> problems are more likely to occur.
> 

I completely agree on this. 

In particular this is also the reason why I think the second alternative
suggested by James is more attractive: the AAA-H communicates with the
AAA-F to obtain the local HA address, then sends it back to the MN in
the EAP reply. In this way, the MN-AAAH interface is the same both if
the HA is assigned locally or in the home operator network and this
seems to reduce the complexity of the system; the difference is in the
AAAH-AAAF interface and might be handled with specific Diameter AVPs.

--Gerardo

>             jak

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

---

From: [email-masked]
Date: Wed, 23 Feb 2005 09:13:20 +0200

James,

> >I have one more question.
> >If we apply DHCP solution to the well managed network, it doesn’t cause
> >problem?
> 
> Like I said, for telephony-style networks, where both the home and visited
> networks believe they can trust each other, might be OK with such a
> solution. But it is not a solution for the Internet as a whole.

Well, I think that this sollution isn't completely restricted to telephony-style
networks, unless you consider wireless ISP-style roaming as part of telephony-style
networks.  There is considerable interest in providing managed roaming, even
with non-telecom providers.  In RADext, we are seeing a number of organizations
and ISPs wanting better roaming infrastructure.  I think this represents a fairly
significant potential deployment model for (M)IPv6, even if it isn't exactly
the traditional IETF model.

So, I partly agree with you that this is a complex case, but I still think it
is a realistic case that should be addressed, just how to ensure the level
of complexity isn't too large.

On the other hand, I would like to see a solution for the case where this trust
is not present.

John