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

From: [email-masked]
Date: Fri, 4 Feb 2005 11:54:11 -0600

The goals/reasons for a standardized interface between the HA and AAA
were discussed at IETF61 in Gerardo's I-D :
draft-giaretta-mip6-aaa-ha-goals-00.txt 
Such an interface is required from the perspective of bootstrapping a
MN in operator owned network environments. 

We would like to make this I-D a working group document that captures
the goals and requirements for the interface between the HA and AAA
and is used as input in the design of the bootstrapping solution that
relies on AAA.

Please comment if you do not agree to making this a WG document and
your reasons by Feb 10th, 05. 

-Basavaraj

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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 04 Feb 2005 14:27:04 -0800

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.

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. 

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.

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.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Sent: Friday, February 04, 2005 9:54 AM
> To: [email-masked]
> Subject: [Mip6] Consensus call:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 07 Feb 2005 16:03:24 -0500

> and is used as input in the design of the bootstrapping solution that

I agree on making the I-D as a WG document, but I think the I-D needs
to be revised in terms of Scenario 2.

Scenario 2 would need more discussion, considering potential
variations and complexity in integrating MIPv6 bootstrapping and
network access authentication.  Especially, I don't think there is a
WG consensus as to whether piggybacking MIPv6 parameters in EAP, or
carrying them in some other ways (using AAA protocol, EAP lower layer
and/or DHCP), or both should be supported.

Having said that, I think Scenario 2 should be described in most
generic way at this moment, perhaps with integration of Figures 3 and
4 without mentioning piggybacking MIPv6 parameters in EAP, RADIUS or
L2 specific extensions.

Best regards,

Yoshihiro Ohba

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 10 Feb 2005 01:28:25 +0900

Hello, Basavaraj and ALL.

I don't agree to making this I-D as a WG documents at this time
though this I-D captures the MIPv6 bootstapping problems very well.

I agree with you that this I-D can be used as input in the design of the bootstrapping
solution relying on AAA.

However, IMHO, we need to have a consensus about bootstrapping framework using AAA.
In this I-D, there are four bootstrapping scenarios.
In my opinion, the scenario 3 and 4 are not within the scope of MIPv6 bootstrapping.
Regarding the scenario 1, we don't have a secure home agent discovery mechanism yet.
So I'd say that only the scenario 2 has a meaning at this time.

My suggestion about MIPv6 bootstrapping is that,
Let's first focus our discussion on the MIPv6 bootstrapping framework works.

After that, we can proceed to the work about defining the interface between the AAA server and HA.

Junghoon.

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Saturday, February 05, 2005 2:54 AM
Subject: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt

-Basavaraj

---

From: Mayumi Yanagiya <[email-masked]>
Date: Thu, 10 Feb 2005 20:02:42 +0900

Hi all,

I agree to discuss about the interface between HA and AAA.
But I’m not sure that we should describe all scenarios in one draft.

IMHO, it seems to me that the purpose of mip6-aaa-ha-goalsis is not to 
identify general framework, but to classify existing bootstrapping 
solutions. And it seems to me that most goals except goals related with 
bootstrapping are common to all scenarios.

In order to simplify discussion, I think that we should describe 
goal/requirement based on simple scenario at the start. After making 
consensus of general goals, we should discuss requirement and solutions 
which depend on each bootstrapping solution.

Best Regards,
--Mayumi

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 10 Feb 2005 14:53:30 +0100

Hi all,

> I agree with you that this I-D can be used as input in the design of the bootstrapping

As its name implies, the aim of this I-D is to discuss needs and
requirements on the AAA-HA communication. It does not propose a solution
to the boostrapping problem. However, the solution for the bootstrapping
problem will certainly include a AAA-HA communication.

> In my opinion, the scenario 3 and 4 are not within the scope of MIPv6 bootstrapping.

you are right, however  even in these scenarios you can see that we may
need a communication between HA and AAA. 

This is why I think that we can work on the AAA-HA independently of a
solution to the bootstrapping problem.

-- 
[email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Thu, 10 Feb 2005 11:24:09 -0800

> > I agree with you that this I-D can be used as input in the design of
the
> bootstrapping
> > However, IMHO, we need to have a consensus about bootstrapping
framework
> using AAA.
> > In my opinion, the scenario 3 and 4 are not within the scope of
MIPv6
> bootstrapping.

There is significant overlap between MIP6-AAA work and solving the MIP6
bootstrapping problem. Depending on the specific MIP6-AAA framework
used, any one or more of the HA address, home address, or MN-HA SA can
be setup using the AAA facilities. For example please see Section 4 of
mip6-aaa-fwk for a relevant discussion.

While doing the MIP6-AAA work, we shall keep an eye on what part of the
bootstrapping problems are already solved, and tackle the rest
elsewhere.

Alper

---

From: "James Kempf" <[email-masked]>
Date: Mon, 14 Feb 2005 14:23:06 -0800

So far as I can tell, the only comments on this concensus call have been
from authors of similar drafts. Here's my 0.02 yen (I'm not an author of a
similar draft).

As I high level comment, I think we need to consider exactly what the
purpose of defining any requirements for standardization of the HA-AAA
interface are, and similarly for any other AAA interfaces (like
HA-AAA-NAS/DHCP server). From a service provider perspective, I believe the
top level goal should be to facilitate inter-operator roaming. That is, the
interface is primarily defined so that a roaming user can obtain mobility
service on a foreign network by being able to bootstrap on the foreign
network (both HA and IPsec SA). The reason is because we need to have
interoperability between operators' networks; otherwise, roaming isn't
possible. I don't think the primary motivation should be to define an
interface within a service provider's network. Modulo vendor
interoperability, a service provider should be able to use any protocols
they want to provision within their own network (including those between
networks), and we should make sure data models such as MIBs reflect this
goal, but we shouldn't define protocols for it.

With that in mind, I think draft-giaretta does a good job of breaking out
the different scenarios and provides a good collection of requirements of
sufficient specificity. I support the call for making it a WG draft.
Something I think it is lacking and that should be added for each of the
scenarios is the high level, functional protocol flows in draft-yegin, for
example, Fig. 2. This should give a better idea about what protocols are
involved and which need modification or enhancement, especially from an
optimization standpoint.

Personally, I don't see the need to define a HA-AAA-NAS/DHCP interface, as
draft-ohba recommends, because I believe this is and should remain an
intra-operator interface that should not cross administrative boundaries. As
I mentioned in San Diego and Washington, DC, I don't believe inter-domain AA
A flows to the DHCP server or NAS should be used for inter-domain
bootstrapping due to the complexity involved in carrying the configuration
information between network operator domains and making sure it is
consistent. I don't believe anything needs to be standardized for
intra-domain bootstrapping using DHCP except for the format of the record in
DHCP for the MIP6 information, which impacts the MN-DHCP server interface.
In a roaming situation, a home IMSP can indicate during the network access
authentication that the MN should bootstrap off the local DHCP server, if a
local HA, is available through the AAA-H to MN protocol (i.e. end to end),
without having to do anything through the local DHCP server itself. For a
nonintegrated MSP, the mobility service is being provided by the MSP itself,
it becomes a bit more difficult to do local HA service, since there is no
way the DNS SRV RR can be specialized to the local domain, but there are
some other possibilities (like preprovisioning the MN with domain names
where local service is available, like iPASS does with telephone numbers of
NASes).

            jak

---

From: Alper Yegin <[email-masked]>
Date: Mon, 14 Feb 2005 22:44:19 -0800

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

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 15 Feb 2005 12:05:04 +0100

hi alper, all,

 thanks for this enumeration. I've just added some references to your
 proposed framework and some comments.

On Mon, Feb 14, 2005 at 10:44:19PM -0800, Alper Yegin wrote:
> recommended as far as I understand. 

I'd like to understand why this is not recommended. Because it has not
been designed for this purpose ?

> Framework 2:

we can add:
draft-jee-mip6-bootstrapping-pana-00.txt

(PANA between MN and PAA and a specific Diameter Mobile IPv6 application
between PAA and AAA)

> 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the

I'm not sure that this is a particular framework since the BU is carried
in the AAA protocol. This piggybacking can be done with Framewrok 1 and
2.

> Framework 4:

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

> Are there other frameworks to add?

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 ?

---

From: "Junghoon Jee" <[email-masked]>
Date: Wed, 16 Feb 2005 00:31:36 +0900

Hi Julien and ALL.
Please see my comments inline.

> draft-jee-mip6-bootstrapping-pana-00.txt

Thank you for pointing out this.

> in the AAA protocol. This piggybacking can be done with Framewrok 1 and

Right, I agree with you.
This is not a separate framework but a possible optimzation case about framwork 1 and 2.

One more thing about this.
Piggybacking the BU meessage to the AAA request was previously proposed by
the previous expired draft, draft-le-aaa-diameter-mobileipv6-03.txt.
This approach inherits this feature from the previous MIPv4 + AAA work which can be found in the draft-ietf-aaa-diameter-mobileip-20.txt
But in case of MIPv6, the feasibility of the piggybacking the BU message to the AAA request depends on the varying situation.
As one example about this, 
In case of bootstrapping, if we use the IPsec SA to protect the BU following the RFC 3775, 
it is not possbile to piggybacks the BU to the AAA request message because the IPsec SA can be setup after the
bootstrapping process.
I think configuration of a CoA and IPsec SA can be an issue related with this.

Regards,
Junghoon

---

From: "Junghoon Jee" <[email-masked]>
Date: Wed, 16 Feb 2005 01:12:03 +0900

Hello Alper.

> Framework 4:

About the assumption of knowing the HA address,
Could we deal with this only through the assumption ?
As I know, dynamic HA assignment is owing to the issues of the home agent discovery,
independent network management, local home agents and ease of deployment
as specified in the draft-ietf-mip6-bootstrap-ps-01.txt. Also it is very related with the home address assignment.

Junghoon.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 15 Feb 2005 18:12:24 +0100

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

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

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Tue, 15 Feb 2005 10:06:47 -0800

Hi Alper,

Overall comment:

I think this is a good way of classifying the proposed solution space, but I
like the scenario approach in draft-giaretta-mip6-aaa-ha-goals better for
classifying the problem space. I think what we need now is some matching of
solutions to problem space, to see where there are gaps or overlaps.

Specific comments below.

> discussions on for which one(s) IETF shall pursue standardization.

Consider the following. Suppose RADIUS is used to transfer operator A's HA
addresses from operator A's AAA server to operator B's NAS. First question
is whether the addresses are delivered every time a roamed host makes a DHCP
request for the HA address? If not and there is any caching going on, then
the addresses could get stale. Second question is how the NAS differentiates
which home operator to ask for the addresses? Presumably an NAI but is that
separate or combined with DHCP? This is a big change in the basic IETF DHCP
architecture, IMHO. Managing DHCP configuration information within an
operator's domain is difficult enough.

> 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the

Can someone provide more details here? As far as I know, in the current
3GPP2 MIP4 system, the PDSN is both home and foreign agent (please correct
if this is wrong), so I don't see how DHCP would come into the picture. How
are they planning on changing that for MIP6? Are they really planning on
distributing the addresses of home agents between operators or just within a
single operator?

        jak

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 Feb 2005 14:44:35 -0800

> discussions on for which one(s) IETF shall pursue standardization. 

Good summary.

FWIW I think that framework 4 is the key one to standardize, because it 
allows the network access AAA being decoupled from the MIP6 AAA.

Not that it doesn't require that they be completely separate, since the 
same AAA backend and the same NAI (and perhaps even EAP method) could be 
used for the cases when the same identity is used for noth the network 
access and for MIP6. And AFAIK it is this backend infrastructure concern 
that is key for the operators.

I think that degree of separation is the right thing for an IETF standard.

    Erik

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 15 Feb 2005 17:41:13 -0800

Alper,

Thanks for summarizing this.  A few comments below.

> Framework 1:
Perhaps, you don't need a new method. But something like EAP-TLV (there was
a draft around sometime back) is sufficient i guess. Anyway, the key issue
is using EAP for configuration.

> Framework 3:
Can you elaborate on the complexity issue ?

> Framework 4:
Agreed.  We can always use a simpler mechanism e.g. DNS to discover the
HA address i suppose. 

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 15 Feb 2005 23:26:27 -0500

On Mon, Feb 14, 2005 at 02:23:06PM -0800, James Kempf wrote:

(snip)

> consistent. 

I think that the complexity of a HA-AAA-NAS/DHCP interface is not much
different between inter-domain and intra-domain bootstrapping cases.
I mean that the complexity is basically about state synchronization on
configuration parameters between a AAA server, a DHCP server and a
DHCP server and is common to both inter-domain and intra-domain cases.

> I don't believe anything needs to be standardized for
> without having to do anything through the local DHCP server itself. 

I agree that this is a simple model.  On the other hand, this provides
a less optimized solution in that the MN might need to execute two EAP
runs, one EAP for network access authentication (and to get a local HA
assigned to the MN) and the other EAP over IKEv2 between the MN and
the HA.  Some operators may desire a more optimized solution in which
AAA for network access and AAA for mobility service are dependent and
only one EAP needs to be executed.

Thanks,

Yoshihiro Ohba

> For a

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 16 Feb 2005 13:34:56 +0100

Hi all,

 more comments concerning framework 1 and 2 inline:

> Framework 1:

Concerning this framework, it appears that we have 2 possibilities:

 - define a new EAP method, the EAP server will be in charge of
   selecting the right method based on NAI for example. The problem is
   that we could have a user having the mip6 stack but who didn't want
   to use it. With this approach, it appears that we always configure
   the mip6 service.

 - use EAP-TLVs (draft-giaretta-mip6-authorization), the problem here is
   that EAP hasn't been designed for configuration.

> Framework 2:

Concerning this framework, I also see 2 possibilities:

 - add mip6 functionalities to exisiting applications: basically add some
   AVPs and mechanisms to RADIUS EAP/ Diameter EAP (if EAP is in use).
   This also imply some modifications to 802.1X/PANA/...

 - define a specific AAA application for mip6.  In this case, we'll have
   at least two AAA applications used in the access network. The reason
   is that I guess we won't have only mip6 terminal. Thus the
   authentication agent will need a way to select the right application.
  The protocol used between the MN and the authentication agent will
  also need some modifications to handle this.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Feb 2005 07:04:12 -0800

(Catching up with e-mail... )

> is whether the addresses are delivered every time a roamed host makes
a
> DHCP
> request for the HA address? 

Since network access AAA happens before DHCP takes place, the HA address
should be delivered via RADIUS even before MN asks for it.

> If not and there is any caching going on, then
> the addresses could get stale. 

It'd be as fresh as the network access session.

> Second question is how the NAS
> differentiates
> which home operator to ask for the addresses? 

NAS gets what AAA home server (for network access) delivers.

> Presumably an NAI but is
> that

I don't see that. Please see newly issued RFC 4014. Or,
Framed-IP-address attribute as defined in RFC 2865.

> if this is wrong), so I don't see how DHCP would come into the
picture.
> How
> distributing the addresses of home agents between operators or just
within
> a

I'll let 3GPP2 folks comment on that. 

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Feb 2005 08:04:11 -0800

> Can you elaborate on the complexity issue ?

- By the time network access AAA is executed:
  - MN must know its HA (may not be possible if the HA 
    discovery is done after the access is authorized -- e.g., 
    DHCP, DNS-based schemes)
  - MN must know its care-of address. (may not be possible if the
    CoA allocation depends on the network access authentication.
- AAA_home server must decapsulate the BU and forward it to the HA. What
is the source address in BU packets? (may be a ingress-filtering
concern).
- The BUack from the HA: is it sent back to MN directly, or forwarded to
AAA_home and piggybacked in the AAA response to MN?
- The results of mobility management and access authorization may need
to be coordinated? What happens when one succeeds and other fails?
- What is the transport for BU? EAP, or EAP lower layers, PPP+RADIUS, ?

I don't claim these are impossible to answer, but clearly each answer
would lead to additional complexity.

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 16 Feb 2005 09:29:46 -0800

>     discovery is done after the access is authorized -- e.g., 

The access network most likely allows DNS requests to pass through.
Perhaps i am biased by how WLAN hotspots work today..

>     CoA allocation depends on the network access authentication.

Good point. 

> AAA_home and piggybacked in the AAA response to MN?

These two steps are part of Diameter Mobile IPv4 application today and don't
know how to asses their complexity. And you need this as part of option 4 also.

> - What is the transport for BU? EAP, or EAP lower layers, PPP+RADIUS, ?
You mean the transport on the access link (between MN and access router).
Yes, that needs to be decided. 

> would lead to additional complexity.
My concern is on how we assess that something is complex :-)

-mohan

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Feb 2005 10:06:02 -0800

Yoshi,

> DHCP server and is common to both inter-domain and intra-domain cases.

The complexity can be illustrated by the following scenario. Suppose
something goes wrong on the interface and I am the manager in charge of
network management. If it is an intra-administrative domain interface, I
call up my network management people on their cell phone and they rush right
out and fix it, since I pay them to be on duty 24 hours a day with cell
phones hot to make sure our roaming customers get good service. Now, suppose
it is an inter-domain interface. I call or send email to the equivalent
person at the management level of the other domain. Maybe they answer the
phone, maybe they don't and I end up playing telephone tag with them for 3
days until we finally manage to talk. Then it takes their people and my
people a couple days to diagnose and fix the problem. Meanwhile, our roaming
customers are not getting service.

That, in a nutshell, is the problem.

> only one EAP needs to be executed.

There need not be two EAP round trips if there is a flag in the EAP reply
from the AAA-H which says that the MN should simply use DHCP to find a local
HA address. The EAP reply configures the IPsec SA, avoiding the need for the
IKEv2 transaction.

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.

Both of these have been discussed in the context of the draft-giaretta
proposal for using EAP to do bootstrapping. I think you may be confusing
draft-giaretta with draft-chakrabarti-bmip. The latter does propose using
IKEv2, but there the initial EAP transaction for bootstrapping may or may
not use AAA/EAP.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Feb 2005 10:46:56 -0800

> Framed-IP-address attribute as defined in RFC 2865.

Ok, but this is not for inter-domain transfer of configuration information
AFIKT.

        jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Feb 2005 14:04:43 -0500

Hi James,

> That, in a nutshell, is the problem.

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.

> would be no need for the IKEv2 transaction if the EAP is used to configure

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.

Regards,

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Feb 2005 13:19:42 -0800

Yoshi,

> 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.

> 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.

            jak

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Feb 2005 13:29:35 -0800

> > > Presumably an NAI but is
> > > that
> > > separate or combined with DHCP? This is a big change in the basic
IETF
> Ok, but this is not for inter-domain transfer of configuration
information

In this case, RADIUS runs inter-domain, DHCP intra-domain. Is there a
specific protocol limitation or explicit recommendation against this
usage?

Alper

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Feb 2005 13:41:53 -0800

> specific protocol limitation or explicit recommendation against this

No, but I don't see anything in this draft or any other about running RADIUS
interdomain with configuration to then be distributed intradomain by DHCP.
Are you aware of any such draft, other than those being discussed on this
list in the context of MIP6 bootstrapping?

            jak

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Feb 2005 13:41:44 -0800

> know how to asses their complexity. 

True. Though that does not mean we shall do the same with MIP6. And, not
everyone is happy about the associated complexity.

> And you need this as part of option 4
> also.

You mean for "framework 4"? That's not the case. The flow is different:
MN<---->HA<--->AAA, vs. MN<---->AAA<---->HA
> Yes, that needs to be decided.

No, I mean from MN all the way to HA.

> My concern is on how we assess that something is complex :-)

I'm glad I didn't call this "complex", otherwise I'd had to answer your
question :-) I identified these as additional complexity. The hard
question is, how much additional complexity is justified before we give
up on standardizing a mechanism.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Feb 2005 15:02:24 -0800

> list in the context of MIP6 bootstrapping?

Luckily, yes:
http://ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt

I said luckily, because this is not a protocol issue but an
architecture/systems issue which may not be commonly captured in I-Ds.

Alper

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Feb 2005 15:19:52 -0800

> architecture/systems issue which may not be commonly captured in I-Ds.

Yes, it is an architecture issue.

>From a quick glance at this draft, it looks like an attempt to support the
3GPP2 architecture. As I've argued elsewhere on this list, I am not
convinced that this architecture is such a good idea for IP networks in
general, and thus that it is suitable for an Internet standard.

            jak

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 16 Feb 2005 15:52:50 -0800

> everyone is happy about the associated complexity.
Sure, we don't have to repeat. But this is based on the assumption/reality that
something is complex. 

> MN<---->HA<--->AAA, vs. MN<---->AAA<---->HA
Ok,  agreed that HA-AAA might be simpler than AAA-HA interaction.

> No, I mean from MN all the way to HA.
Hmm, you already have RADIUS or DIAMETER between the NAS and AAA.
Hence,  we just have to decide between EAP or EAP lower layer for the first hop
i guess.

> up on standardizing a mechanism.
Ok.

-mohan

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Feb 2005 17:32:25 -0800

James Kempf wrote:

> if this is wrong), 

3GPP2 uses different mechanisms for MIPv4 and MIPv6.

for MIPv6, there is no foreign agent. the PDSN is just a NAS. the Home
Agent is in the Operator's home link.

> so I don't see how DHCP would come into the picture. How

both.

at the end of access network authentication, the HA address is delivered
to the PDSN (which is a NAS). the PDSN then sends the HA address to the
MN via DHCP.

works pretty well and I happen to think that this is a good bootstrap
mechanism.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Feb 2005 17:47:48 -0800

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.

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.

my 2 cents.

Vijay

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Feb 2005 20:57:04 -0500

> much more that can go wrong in that case.

So do you think that the existing solution for Mobile IPv4
bootstrapping is not a good solution to follow when defining a Mobile
IPv6 bootstrapping solution?

> problems are more likely to occur.

I don't understand the security threat because the HA address is
somehow exposed to the operator of the visited domain when the MN
sends a BU to the HA (I mentioned this several months ago).  Also I
don't understand the network management problems, because even in the
end-to-end delivery model you mentioned above, some information such
as IKEv2 credentials would need to be passed to the local HA in the
visited domain from the home domain (it's not a pure end-to-end
delivery in that sense) in order for the MN to perform IKEv2 with the
local HA without running EAP over IKEv2.  I really don't see a major
difference between managing IKEv2 credentials and managing HA address
across administrative domains.

Regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Feb 2005 21:29:20 -0800

Vijay,

> this classification is very confusing to me. 

This is one way to look at various MIP6-AAA interactions. If you have
different ways to look at it, please share. 

> we are dealing with
> two problems. 

Well, isn't dynamically generating the MN-HA SA for [3] part of the
bootstrapping problem [2]?

> draft-ietf-mip6-ikev2-ipsec-02.txt already defines

I agree.

> doesnt hurt standardizing one solution in the IETF.

Are you talking about plain network access auth/z? Or, something also
related to MIP6?

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Feb 2005 23:53:11 -0800

> bootstrapping problem [2]?

not always. see draft-ietf-mip6-ikve2-ipsec. ( I think Gerardo
also had a draft on using EAP). if EAP is used with IKEv2 with a 
AAAH backend, then the MN and the HA can setup the required SAs
dynamically. in this case, the MN just needs the HA's address 
before running IKE. the MN can even acquire a Home Address when
it runs IKEv2 with the HA (section 7 of 
draft-ietf-mip6-ikev2-ipsec-00). this falls into framework 4 in 
your classification.

> Are you talking about plain network access auth/z? Or, something also

plain network access.

Vijay

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 Feb 2005 00:31:13 -0800

Hi Julien,

>   also need some modifications to handle this.

I don't think we'd need a new AAA application. It is the same NAS
application carrying additional configuration parameters. One can design
a solution where MN can indicate its desire to learn MIP6 parameters
during network access AAA. (or, if AAA home server is sending a piece of
information that does not generate or change state, e.g., HA address, it
can do that anyways, and MN can toss it away if not needed)

Alper

---

From: Mayumi Yanagiya <[email-masked]>
Date: Thu, 17 Feb 2005 22:09:33 +0900

Hi James, Ohba-san and all,

Let me add new point of view for classification of framework.
(It does not mean that I disagree Alper's classification.)

I think that framework can be divided into 2 main branches as follows.
 Type1: bootstrapping procedure is executed between MN and AAA server.
 Type2: bootstrapping procedure is executed between MN and network
        elements such as HA, NAS and DHCP server.
        Those network elements can use back end AAA server.

In type 1, we assumed that MNs and AAA server communicate directly by
using authentication protocol such as EAP and network elements are not
required to understand MIP6 specific information. So, I don't think that
we are required to specify detailed interface between AAA and MN because
AAA in home network can assign configuration parameters in vendor
specific attribute.

 Local domain  |    Home domain
       NE      |      AAA
               |       |
        +--------------+
        |      |
        MN     |

In type2, we are required to specify interface. Because bootstrapping
messages may be treated by network elements in local domain and AAA
server in home network.
I don't understand why problems are caused only in DHCP case.

    Local domain   |   Home domain
       NE-------------------->AAA
  (DHCP, HA, NAS)  |           |
        |          |           NE
        |          |           |
       MN- - - - - - - - - - - +
                   |

Could you give me comments?

Best Redards
--Mayumi

>>>>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.
>>>

-- 

*++++++++++++++++++++++++++++++++++++++++++
NTT Network Service Systems Laboratories
Mayumi Yanagiya
tel: +81 422 59 6783   fax: +81 422 59 5631
E-mail: [email-masked]
+++++++++++++++++++++++++++++++++++++++++++*

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Feb 2005 08:48:03 -0800

> > distributing the addresses of home agents between operators or just
within a
> works pretty well and I happen to think that this is a good bootstrap

Sure, for 3GPP2 networks.

The problem is that these are essentially telephone networks with a high
degree of trust and co-ordination between operators. Not all networks in the
Internet are like that. That's why I don't think this mechanism is such a
good idea for the Internet in general.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Feb 2005 09:30:08 -0800

Yanagiya-san,

In addition to your classification, there is also Type 3 bootstrapping, in
which AAA is not involved, such as is described in draft-chakrabarti-bmip.
Alper's classification mixes backend AAA and bootstrapping AAA and so is
different, this one is only for boostrapping AAA.

Regarding the problem with DHCP, the issue is that not all IP networks will
have the proper inter-domain network management integration and
inter-network operator trust that 3GPP2 networks do (which use a NAS/DHCP
interface). Without these, deployment of such an interface can lead to
problems. For example, in the future, a mobile operator may decide to
conclude a roaming agreement with a small wireless ISP that is not a
traditional mobile telephony service provider for cost or coverage reasons,
in order to provide roaming coverage for its users. Such an ISP may not have
the resources necessary to support such an interface.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Feb 2005 10:01:49 -0800

> Sure, for 3GPP2 networks.

okay. it appeared to me that you were saying the mechanism used
by 3GPP2 is a bad idea.

> good idea for the Internet in general.

sure. it just needs to be evaluated along with other mechanisms.
I have always maintained that it is not possible to come with
one bootstrap mechanism that will work in all deployments and
scenarios.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Feb 2005 10:21:07 -0800

Yoshi,

> IPv6 bootstrapping solution?

Removing the foreign agent from MIP6 makes the protocol architecturally
cleaner. It strengthens the end-to-end relationship between the home agent
and mobile node. This is an advantage from a network management and security
standpoint, because it reduces the possibility of failure in the middle.
Re-introducing the foreign agent as a NAS that does DHCP will decrease the
reliability in general (though for specific cases like telephony-style
networks such as 3GPP2, it may work). It's the standard end-to-end argument,
see Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End Arguments in
System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.

> across administrative domains.

Regarding dynamic/local HA to AAA-H v.s. NAS/DHCP to AAA-H, the security
problems of securing the AAA flows between the AAA-H and the network entity
in the local network (local HA or NAS/DHCP server) are similar. Local HA
should not be enabled unless the roaming network operator and home network
operator trust each other. The difference between security credentials and
addresses is that the verification of the security credentials during an
IKEv2 exchange (provided EAPoIKEv2 is used with the local HA) lies squarely
in the home network. Thus, once again, there is an end-to-end transaction
between the MN and AAA-H in which the local HA merely acts as a routing
intermediary. There is no transfer of sensitive credentials between the home
network and the foreign network. With addresses, the home network is
depending on the foreign network NAS to properly handle the addresses. It's
just another point where compromise or failure is possible, even if, in
general, the two operators trust each other. The fewer network entities
involved, the less possibility for failure.

            jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 17 Feb 2005 17:44:07 -0500

James,

> System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.

I agree that the bootstrapping model defined in 3GPP2 is good for
well-managed networks.  An advantage of the 3GPP2 model is that the
model uses the existing building block protocols (i.e., EAP, EAP
methods, DHCP, PANA, IEEE 802.1X) without modification as much as
possible.  A downside is that it introduces an addtitional middle box
(NAS/DHCP server), which is transparent in other bootstrapping
framework, to carry the bootstrapping parameters.

> operator trust each other. 

I agree with you on this.

> The difference between security credentials and
> network and the foreign network. 

That is true provided EAPoIKEv2 is used with the local HA, as you
mentioned above.  But if IKEv2 is used with the local HA but without
EAP (I mean the case in which there is no 2nd EAP), still there is
transfer of sensitive credentials across administrative domains and I
don't see a major difference as I mentioned in the previous mail.

> With addresses, the home network is

Again, if IKEv2 is used with the local HA but without EAP, the local
HA still involves in the bootstrapping transaction and the number of
involved network entities for maintain the IKE credentials across
domains (three -- MN, local HA and AAA server) are the same as that is
needed for maintain HA address across domains (three - MN, NAS(*) and
AAA server).  So I'd say that even if we use EAP for carrying
bootstrapping parameters, local HA support without 2nd EAP does not
follow the end-to-end model, and thus is recommended only for
well-managed networks.  I hope I am doing the right analysis here.

(*) The number of the entities for the latter case can be four when
NAS and local DHCP server are physically separate devices.

Regerds,

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Feb 2005 16:27:53 -0800

Yoshi,

I would not expect a home operator to transfer the mobility service
credentials for a user to a dynamically assigned home agent in the foreign
operator's network. Standard IP network access roaming doesn't do this and I
would not expect it to be done for mobility service roaming either. For one
thing, if Radius is used, the credentials won't be encrypted end to end
unless the two operators take special precautions, so there is the
possibility of compromise if the Radius traffic is routed through an
intermediary.

If the two operators want to avoid having the mobile host require an EAP
round trip back to the home network during the IKEv2 exchange through the
dynamically assigned home agent, the home operator can provision the host
with a certificate and the dynamically assigned home agent can check the
certificate to see if the host is authorized for mobility service instead of
using EAP (better anyway, but the PKI overhead may not be for everyone).

I know that base 3GPP authentication architecture transfers the
authentication vector from the HLR to the VLR (without any authentication
or encryption on the SS7 transport believe), I don't know if 3GPP2 does
this, but I would expect so since the HLR/VLR architecture is the same. The
security of this is questionable at best, and I think we need to do much
better in the IETF mobility service architecture.

            jak

----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Yoshihiro Ohba" <[email-masked]>; <[email-masked]>
Sent: Thursday, February 17, 2005 2:44 PM
Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt

> > > > The difference is that the delivery is end to end, between the MN
and

---

From: Mayumi Yanagiya <[email-masked]>
Date: Fri, 18 Feb 2005 13:11:58 +0900

Hi James,

Thank you for your reply.

 > different, this one is only for boostrapping AAA.

  I agree that there are solutions that don’t rely on AAA.
  But, can I focus on the solutions which are relied on AAA in order to 
simplify discussion?

 > the resources necessary to support such an interface.

  I agree that problems will be occurred when network providers don’t 
have agreement. But I can’t understand why the problems will be occurred 
only in DHCP case. For example, in IKEv2 based solution,
  - if MN is assigned home agent in home network, HA aren’t required
    inter-domain interface.
  - if MN assign home agent in local network, home agent will be required
    inter-domain interface to get some information such as  IKE
    credential.

  I think that same problems will be occurred if there is no agreement 
between home network and local network. Is my opinion wrong?

--Mayumi

 >>>>Yes, but configuration is a different problem from network
 >
 > access/mobility
 >
 >>>>roaming consists of a yes/no indication about whether someone can enter
 >
 > the
 >
 >>>>about the topology and services in the home administrative domain. 
There
 > is
 >>>>>>to obtain the local HA address, then sends it back in the EAP reply.
 >
 > In
 >
 >>>>that
 >>>>
 >>>>
 >>>>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
 >

---

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Feb 2005 10:03:08 -0800

> don't see a major difference as I mentioned in the previous mail.

I am not in favor of designs that require transfer of credentials shared
exclusively between the mobility service authorizer and the user to a local
HA in the foreign network, and don't believe such designs are a good idea
for standardization for exactly the reason you cite above.

> well-managed networks.  I hope I am doing the right analysis here.

With IKEv2 EAP through the local HA to the AAA-H, the local HA is acting as
a router for an end to end encrypted bag of bits containing the credentials
that are real-time transferred from the MN to the AAA-H. The AAA-H sends
back a yes/no reply to the local HA. This is a well defined AAA-style
transaction, and could even be optimized further with something like
attribute certificates on the MN that the AAA-H provides during the initial
network access authentication so that the MN can establish the IKEv2 SA on
the local HA without needing a second EAP transaction.

It's a completely different situation from NAS/DHCP case. In the NAS/DHCP
case, the following are required:

1) Some way to propagate the home agent addresses into the AAA-H when those
addresses change (as they will, please see parallel thread on preventing DoS
attacks on home agents).
2) AAA flows from the AAA-H to the back end of the NAS, which unencapsulates
them and relays them to the DHCP server.
3) Some way to transfer the addresses to the DHCP server if the NAS and DHCP
server are not co-located.
4) Monitoring of the addresses and provisioning process to be sure that the
addresses are current and there has been no compromise.

This is a lot more than a simple AAA transaction, and requires a lot more
network management and trust between networks than simple AAA, and there are
a lot more ways for things to go wrong. This kind of network architecture
is, in my opinion, not appropriate as a general solution for the Internet,
though it may be useful for telephony-style networks, such as 3GPP2, in
which there is a high degree of trust and co-operation between network
operators.

> NAS and local DHCP server are physically separate devices.

Exactly.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Feb 2005 10:17:14 -0800

Yanagiya-san,

>between home network and local network. Is my opinion wrong?

There are more places for things to go wrong in the DHCP case. As I
mentioned in email to Yoshi, there needs to be some way to get the HA
addresses into the AAA-H when they change, then from the AAA-H to the NAS in
the foreign domain, then from the NAS to the DHCP server, then from the DHCP
server to the MN. That's a lot more places for things to go wrong.

            jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 18 Feb 2005 11:36:05 -0800

James,

> addresses change (as they will, please see parallel thread on
preventing
> DoS

When a configuration parameter changes, appropriate actions need to be
taken regardless of the used scheme (e.g., update DNS servers, or update
DHCP servers, or AAA servers, etc.). I don't see an order of magnitude
difference between different "centralized bootstrapping systems" when it
comes to handling changes.

> 3) Some way to transfer the addresses to the DHCP server if the NAS
and
> server are not co-located.

These two are the same. Info flows from AAA home server to AAA client on
the NAS (collocated with DHCP relay); later from DHCP relay to DHCP
server.

> 4) Monitoring of the addresses and provisioning process to be sure
that
> addresses are current and there has been no compromise.

Sure.

> network management and trust between networks than simple AAA, and
there
> are

I admit there are more end-points involved in the information flow.
Unless there is some characteristic difference (e.g., insertion of
untrusted 3rd parties in the flow), I don't see a major issue.

Sure this may not be an appropriate scheme for all deployments. But if
it is good enough for 3G* and other wireless operator networks, that
should be enough to consider it -- of course, we shall capture its
characteristics too.

Alper

---

From: Mayumi Yanagiya <[email-masked]>
Date: Mon, 21 Feb 2005 20:26:04 +0900

Hello,

I agree that it will be complex to synchronize states.
But, I'm not sure that configuration parameters will be exposed only 
when AAA-H distributes to elements in visited network. As you mentioned, 
IP address of home agent, home address of mobile node and IKE credential 
are exposed to element in visited domain in DHCP case. But, if other 
solution is applied, element in visited domain t, such as access router, 
will be able to get those parameters except IKE credential.
Did you point out that DHCP solution is easier for visited domain to get 
parameters than other solution?

I have one more question.
If we apply DHCP solution to the well managed network, it doesn’t cause 
problem?

Best Regards,
--Mayumi

--

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Feb 2005 11:41:49 -0800

>parameters than other solution?

Routers won't have access to the contents if they are encrypted. For the
DHCP solution, the NAS in the visited domain has to manage the information.

>If we apply DHCP solution to the well managed network, it doesn’t cause

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.

            jak