Subject: [Mip6] comments on AAA-HA-goals-02

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 02 Aug 2006 17:07:27 -0700

Resending this message on the list, since it was sitting for moderator
approval!

Madjid

  _____  

From: Madjid Nakhjiri [mailto:[email-masked]] 
Sent: Tuesday, August 01, 2006 3:51 PM
To: [email-masked]; [email-masked]; 'Rafa
Marin Lopez'
Cc: 'Madjid Nakhjiri'; [email-masked]; [email-masked];
[email-masked]
Subject: comments on AAA-HA-goals-02

Hi, 

I have been trying to subscribe to this list since a few hours ago (not a
member yet), so I am ccing the chairs and authors I know for approval of
this message.

 I am new to the MIP6 bootstrapping terminology, but not new to
bootstrapping or AAA-MIP interactions. I just looked through the HA-AAA
goals drafts. Thank you for a very well written draft that also provides a
good summary of the split and integrated scenarios as well. I do however
find some the terminology confusing. I apologize if my questions have been
discussed extensively on the mailing list. I would appreciate if the authors
or other people can shed some light on some of the terminology or point me
to the proper document to read, I have started going through the
bootstrapping draft a bit as well, and am planning to see how MIP6-AAA
interaction works. 

*        The way the terminology of Mobility service provider and Access
service provider in the context of MIP6, which is layer 3 mobility, would be
defined in my mind is that the MSP only provides MIP6 services, while the
ASP provides access services, such as L2 access, QoS and other services
(guessing IP connectivity/ DHCP and so on). The network MSA to me symbolizes
the MSP-AAA server, while ASA symbolizes ASP-AAA server. 

*        I see a hot spot provider or a 802.16d network without mobility
support as an ASP, while a IP enabled cellular or a WiMAX network as a
combination of ASP and MSP. To me assignment of HA falls into the MSP
service category, not ASP service category (I just confirmed this in
bootstrapping-ps section 7.1), so there are some statements in the draft as
far as an  ASP assigning an HA and I don't think those are appropriate based
on the terminology provided. 

*        Then there is the concept of home versus visited domain. I am
guessing "domain" to administrative domain (AAA domain). Traditionally AAA
community is denoted as home and visited AAA servers, i.e. AAAH and AAAV,
respectively. I just checked the bootstrapping-ps draft and that draft calls
uses the term "serving" instead of "visited", but still provides a
distinction between home versus serving MSP (MSPH and MSPS) and between home
versus serving ASP (ASPH and ASPS). Having said this, I think if the group
is going to great length to separate ASP/ MSP and ASA/MSA, it also needs to
distinguish between the home versus visited domain for each of the
authorizers. So that MSAH refers to AAA server within home MSP (MSP-H) and
MSAV or MSAS (pick one) to AAA server within visited or serving MSP (MSP-V
or MSP-S). The same goes for ASAH and ASAV. This means Serving MSA is not
the same as serving ASA. It is not proper to equate the access service
provider (ASP) with MSP-V the visited domain as it is implied in section
4.2: "Mobile Node requests a home agent to the Access Service Provider
(ASP)". According to my understanding of the terminology of ASP, ASP has
nothing to anything to do with HA assignment. I think this can be easily
remedied by introducing MSAH and MSAS. Visited domain HA allocation can be
formulated as "MN can request MSAH for an HA assignment within MSPS after
authentication to MSAH and authorization of mobility service by the
MSAH/MSAS to MN".

*        The same goes for another sentence in the same section saying "..
Mobile Node can specify if it wants a home agent provided by the visited
domain (ASP) or by the home domain (ASA)", which seems to be mixing
(mobility and access service), (home and visited), (provider and authorizer)
all in the same sentence!!

*        The other comment along the same line is about section 4.1, where
it is stated a pool of HA s can rely on the home EAP server (I am guessing
EAP server belonging to MSA-H, since this is split scenario) for
authentication. Here it is stated "It allows the roaming mobility case in
which the MN obtains the mobility service in a different administrative
domain (MSP !=MSA). Here it seems that it is implied HA is part of MSP
function (appropriately), however, I am not sure if MSP and MSA can imply
two administrative domains, to me administrative domain implies AAA domain,
so one would be MSA-H and another MSA-V, so an HA could be authorized within
MSA-V based on authentication to MSA-H and authorization by MSA-H.

*        I also have an issue with the usage of term NAS in next to last
paragraph of section 3. NAS is really an access service agent (as the name
implies) not a mobility service agent. NAS performs many functions beyond
the AAA client function, which brings up two issues. 1) the sentence ".HA,
that can be seen as Network Access Server for MIP6", is only providing
confusion in this context, you may say that HA can be seen as Network
mobility server if you want but in a draft that has ASP and MSP everywhere.
2) in the goals sections (5.1/ 5.2) , it is not mentioned anywhere that the
HA MUST act as a AAA client, is this a non-requirement, or is it implicitly
understood?  Especially G2.2 seems to imply this.

*        In 5.4 why is it a "MUST" for HA to be an EAP pass-through
authenticator? As long as HA receives its information from the AAA server in
a secure fashion and both HA and AAA can identify the MN and its EAP session
uniquely, there is no reason for allocating HA and EAP pass-through EAP
authenticator in the same box.

*        For section 4.2, Integrated scenario, I see that NAS gets MIP6 conf
parameters from the AAAH, how does the HA receives the information it needs?

Thank you for your attention,

Madjid Nakhjiri

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

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 3 Aug 2006 16:22:09 +0200

Hi madjid,

 let me try to respond to your mail though some terminology issues are more related to the
 draft-ietf-mip6-bootstrapping-ps draft.

 First of all, thanks for reading the document.

On Wed, Aug 02, 2006 at 05:07:27PM -0700, Madjid Nakhjiri wrote:

<snip>
> good summary of the split and integrated scenarios as well. 

 thanks,
 
> I do however
> (guessing IP connectivity/ DHCP and so on). 

 right

> The network MSA to me symbolizes

 no, the MSA is administrative entity with whom the user has a contract
 and thus credentials. The MSP effectively provides the MIP6 service to
 the user. Thus the MSP may have to contact the MSA before providing the
 service. 

> on the terminology provided. 

 it depends if we are in the split or integrated scenario.
 In the split scenario, we don't have ASP/ASA, only MSP/MSA. So the user
 has an HA from the MSP.
 In the integrated scenario, if MSP=ASP, the user obtains an HA from the
 MSP/ASP. 

> authentication to MSAH and authorization of mobility service by the

 maybe my explanation below will answer to this paragraph ?

> all in the same sentence!!

 yes, that can be confusing. 

> MSA-V based on authentication to MSA-H and authorization by MSA-H.

 MSP has its own AAA server. MSA is the AAA server of the MN. 
 Does it respond to your comment ?

> mobility server if you want but in a draft that has ASP and MSP everywhere.

 ok.

> understood?  Especially G2.2 seems to imply this.

 I think it is implicitly understood. Do you think we should add a
 statement on this ?

> authenticator in the same box.

 hmmm, the HA acts as a AAA client and MN uses IKEv2 with EAP to be
 authenticated. So the HA MUST act as an EAP pass-through authenticator.

 Am I missing something ? do you think we should rephrase this ?

> parameters from the AAAH, how does the HA receives the information it needs?

 In the integrated scenario based on DHCPv6, the MN gets HA info through
 DHCP. Then we fall in the split scenario and the MN uses IKEv2 with the
 HA. 

 Julien Bournelle

-- 
julien.bournelle at int-evry.fr

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Aug 2006 08:55:57 -0700 (PDT)

Hi Julien,
  Can you please point to where we can find the details on the use of IKEv2 EAP authentication of the MN where HA is Pass-Through Authenticator?

Thanks,

--behcet

----- Original Message ----
From: Julien Bournelle <[email-masked]>
To: Madjid Nakhjiri <[email-masked]>
Cc: [email-masked]
Sent: Thursday, August 3, 2006 9:22:09 AM
Subject: Re: [Mip6] comments on AAA-HA-goals-02

Hi madjid,

<snip>

 thanks,

 right

 ok.

 Julien Bournelle

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 3 Aug 2006 18:07:00 +0200

Hi Behcet,

>   Can you please point to where we can find the details on the use of IKEv2 EAP authentication of the MN where HA is Pass-Through Authenticator?

 you can take a look at draft-ietf-dime-mip6-split-00.txt.

 regards,

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 03 Aug 2006 16:37:44 -0700

Hi Julien, 

Thanks for the quick reply. 

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Thursday, August 03, 2006 7:22 AM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [Mip6] comments on AAA-HA-goals-02

Hi madjid,

 let me try to respond to your mail though some terminology issues are more
related to the
 draft-ietf-mip6-bootstrapping-ps draft.

Madjid>>I actually find the terminology in the bootstrapping draft more
consistent. 

Madjid>>Well, you are saying MSA has a contract with the user and has her
credentials. To me it translates to a home AAA server or authentication
server for the MSP. I think we need to make the distinction between home MSA
and visited MSA.
Also, MSP is a service provider, but you are implying it does not have a AAA
server? At the bottom of your email you said MSP has a AAA server. I am
confused now.
The ASP is defined in the bootstrapping draft as an _operator_, but it is
not clear whether MSP is an operator or just an entity like an HA. What is
the real life correspondence of the MSP??
I like to think MSP include both a HA and a AAA server (MSA).

Madjid>> Well, you do have ASP/ASA, it just that it is beyond MSP control.

Madjid>>Well one point is ASP is an access provider, not a mobility
provider, so ASP cannot grant an HA request nor can it assign one. So that
sentence needs to be revised. The other issue is the lack of distinction
between home and visited providers, ASP does not mean visited MSP!

Madjid>>Well, if we stick to the terminology in the bootstrapping draft and
use "serving" and "visited" and clarify whether MSP is an operator or just
an HA, things should fall into a place better. If you agree with my
statements, I could help out with that.

Madjid>>the definition of MSA is "an authorizer that authorizes MIP6
service". To me that is the AAA server of the MSP: a AAA server that
authorizes MIP6 service within an MSP. Then you have the concept of home
versus serving MSP or ASP and home versus serving MSA and ASA.
The home-MSA can authorize MIP6 service within home MSP and has MN's
credentials. The "MSA" alone is just like a "AAA server" alone, it does not
say home or visited AAA server.

 ok.

Madjid>>I think this is the first requirement for the HA within an HA-AAA
goals draft. It tells the world what code to expect to have in the compliant
HA. Having it implicit is not a good thing.

Madjid>> I don't think this is hard requirement. You may another AAA client
on the path EAP signaling with EAP server. Aren't you separating ASA and
MSA?? HA is AAA client for MSP authorization but not necessarily the AAA
client for every EAP authentication, may be I am missing something.
The way to rephrase it is

"HA Should be able to act as EAP pass-through authenticator in the EAP
process for IKEv2." Or something like that. I have to look at the split
scenario doc explaining this.

Madjid>> Let me do some more reading:)

Thanks,

Madjid

 Julien Bournelle

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 4 Aug 2006 18:24:31 +0200

Hi madjid,

 I think that this discussion is more about our understanding of the
 bootstrapping-ps terminology. Maybe we should start a new thread about
 this.

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 04 Aug 2006 16:46:04 -0700

Hi Julien,

There is some inconsistency in the AAA-HA-goals draft that could be
clarified if the concepts of home versus serving providers/authorizers
defined in the terminology section of the bootstrapping PS have been used
more persistently. Again, I am happy to provide the editorial changes once
we settle this:)

Looking at the bootstrapping paper a few things are clear:

1) ASPs do not deal with provisioning of mobility service, MSPs do. This
means an HA would be assigned by the MSP not by an ASP.

2) There is a concept of home versus serving provider versus authorizer.
This means a local HA in a serving/ foreign/ visited (pick one) would be
assigned by the "serving MSP" not by an ASP.

There is one error in my opinion in the bootstrapping ps section 5.1.2
(dynamic HA assignment):

"Local home agents

      The mobile node's MSP may want to allow the serving ASP to assign
      a local home agent for the mobile node."

It should say "...to allow serving MSP" not "ASP", since ASP is not in
charge of providing mobility service and that is where probably the
inconsistency starts??

What do you think?

R,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 9:25 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; [email-masked]
Subject: Re: [Mip6] comments on AAA-HA-goals-02

Hi madjid,

 Julien

On Thu, Aug 03, 2006 at 04:37:44PM -0700, Madjid Nakhjiri wrote:
> > authenticator? As long as HA receives its information from the AAA
server
> in

---

From: Julien Bournelle <[email-masked]>
Date: Sat, 5 Aug 2006 13:46:49 +0200

Hi madjid,

> means an HA would be assigned by the MSP not by an ASP.

 I agree with that.

> assigned by the "serving MSP" not by an ASP.

 I also agree with that.

> charge of providing mobility service and that is where probably the

 I agree on this point. 
 
 We'll incorporate this in the next revision (-03). 

 Thanks,

 Julien